Date: Fri, 19 Aug 2005 11:43:19 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: Attila Nagy <bra@fsn.hu> Cc: freebsd-security@FreeBSD.org Subject: Re: Closing information leaks in jails? Message-ID: <20050819094319.GW659@obiwan.tataz.chchile.org> In-Reply-To: <43049FB2.1030203@fsn.hu> References: <43049FB2.1030203@fsn.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Attila, > I'm wondering about closing some information leaks in FreeBSD jails from > the "outside world". > > Not that critical (depends on the application), but a simple user, with > restricted devfs in the jail (devfsrules_jail for example from > /etc/defaults/devfs.rules) can figure out the following: > > - network interfaces related data, via ifconfig, which contains > everything, but the primary IP address of the interfaces. It seems that > alias IPs can be viewed: > bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > options=1a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING> > ether 00:12:79:3d:83:c2 > media: Ethernet autoselect (100baseTX <full-duplex>) > status: active > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 > inet 127.0.0.2 netmask 0xff000000 > > - the arp table via arp, which does contain the above interface > addresses. This can be used for example to detect other machines on the > same subnet, which communicate with the host machine. > - full dmesg output after boot and the kernel buffer when it overflows > (can contain sensitive information) > - information about geom providers (at least geom mirror list works) > - the list of the loaded kernel modules via kldstat > - some interesting information about the network related stuff via netstat > - information about configured swap space via swapinfo > - NFS related statistics via nfsstat > - a lot of interesting stuff via sysctl > > and maybe more, I can't think of currently. > > Are there any ways to close (some of) these? The original paper from phk@ and rwatson@ presenting jails let us sound this is a very neat concept. While I agree this is worth adding restrictions or features where they are really needed, the jail framework tends towards being fairly intrusive in the system. Therefore, I think ``hacking'' the source for all the above situations is not a good idea, although I agree there may be a need for them. What I'm going to say is obvious for most people, but saying it may spur on people imagination :-). BSD solutions are known to be smart, setting a bandage everywhere we seem to need one is not the appropriate way to go. For example, it has been recently dicussed that it would be worth having virtual network stacks, in order to have the ability to multiplex M jails over N virtual network stacks. The developpement of this doesn't even started on newer FreeBSD systems, but it seems the new upcoming routing code is going to be modified to handle multiple routing tables, in the same way as Linux does it. Andre Oppermann is going to publish a paper about its intention towards FreeBSD routing code. If you are interested in this, you may want to have a look at this (long) subthread [1]. The problem is actually there are many ways to access kernel informations, and this is therefore a hard task to get a common security framework which would be simple to use for jail. At the moment, you might want to look at the MAC framework from the TrustedBSD project. I've never used it but I think it may overcome at least some of your concerns. Regards, [1] http://lists.freebsd.org/pipermail/freebsd-net/2005-August/008027.html -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050819094319.GW659>