Closing information leaks in jails?

[Jeremie Le Hen]

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 >