Hello, 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? Thanks, -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758
Benjamin Lutz wrote:>>- full dmesg output after boot and the kernel buffer when it overflows >>(can contain sensitive information) > If it's sensitive in so far as it endangers the privacy of local > non-jailed users, I think that's a bug that'd need fixing.There are many points from this issue can be observed. Let's take a shell server, or a CGI server. Take the latter for an example.> I'm not sure why hiding the mentioned information is bad. It onlyNot bad at all. The bad thing is that they are available and the administrator can't (AFAIK, without any hacking) hide them. :)> contains machine-specific data, and at best the private information a > jailed user will be able to figure out is the machine's usage patterns > (yes, crypto folks don't like that, but c'mon...). Hiding that data > isn't real security.Hmm. Why ifconfig doesn't tell me the main IP address of an interface? BTW, this is not usage pattern, and ARP data (MAC addresses, you can do interesting stuff with them, for example guess what kind of operating system and hardware run the given IP, etc) is not either. And not showing the MAC and IP addresses for all of your users can be real security.> Besides, the user can only gain the data if he can execute the binaries > that provide it. Why not remove, say, the geom programs (and at the same > time make it impossible to execute new programs? Eg only make the > home/tmp dirs writeable, but put those on a noexec partition). That > should make it hard enough to access geom data.As I said there are many different cases. In the case of a CGI server, you must make those executables executable. And the worst part is that your users can modify them without too much control. In another example, when you would like to provide "virtual machines", where the user can manage his jail, this "solution" is also not good. I think it is pointless to ask why would hiding the ARP table, or the system's IP addresses is sane or not, when currently you can't do a netstat -an from inside a jail and also can't do many other things. Oh, and you can do iostat! :) -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Adopt a directory on our free software phone @work: +361 371 3536 server! http://www.fsn.hu/?f=brick cell.: +3630 306 6758
Attila Nagy wrote:> Hello, > > 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 0xff000000For 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 netstatnetstat 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 swapinfoNot sure I see how this could be used against you.> - NFS related statistics via nfsstatAgain only statistics. Not sure how this is a problem.> - a lot of interesting stuff via sysctlYes, 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 good results. Cheers, Nate
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 >
Attila Nagy wrote:> Hello, > > 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:[...]> - full dmesg output after boot and the kernel buffer when it overflows > (can contain sensitive information)If it's sensitive in so far as it endangers the privacy of local non-jailed users, I think that's a bug that'd need fixing.> - 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 sysctlI'm not sure why hiding the mentioned information is bad. It only contains machine-specific data, and at best the private information a jailed user will be able to figure out is the machine's usage patterns (yes, crypto folks don't like that, but c'mon...). Hiding that data isn't real security. Besides, the user can only gain the data if he can execute the binaries that provide it. Why not remove, say, the geom programs (and at the same time make it impossible to execute new programs? Eg only make the home/tmp dirs writeable, but put those on a noexec partition). That should make it hard enough to access geom data. Cheers Benjamin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 186 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20050818/98e7bf87/signature.bin