Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: Closing information leaks in jails?
From: Nate Nielsen (nielsen-listmemberwebs.com)
Date: Thu Aug 18 2005 - 17:44:42 CDT
Attila Nagy wrote:
> 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
> 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
For me this only shows the alias assigned to the jail.
> - full dmesg output after boot and the kernel buffer when it overflows
> (can contain sensitive information)
Yes, this is important. Use:
sysctl -w security.bsd.unprivileged_read_msgbuf=0
> - 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
netstat works, but it limits itself to the jail pretty well. In
particular 'netstat -r' and friends don't work. The normal 'netstat -a'
only shows connections to the current jail. It does show the output from
'netstat -m' and those sort of things, but those say nothing over the
network load of the current machine.
> - information about configured swap space via swapinfo
Not sure I see how this could be used against you.
> - NFS related statistics via nfsstat
Again only statistics. Not sure how this is a problem.
> - a lot of interesting stuff via sysctl
Yes, there's a lot there, but a lot *is* filtered out in a jail.
> Are there any ways to close (some of) these?
My suggestion would be to file bugs one by one for each piece of
information that causes you concern along with the reasoning of why that
information is dangerous or sensitive.
The FreeBSD developers have been atentive to these things, and have
added functionality in almost each release to minimize information
available in a jail. So pointing specific issues out will probably get
freebsd-securityfreebsd.org mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribefreebsd.org"