From owner-freebsd-security@FreeBSD.ORG Fri Aug 19 09:42:52 2005 Return-Path: X-Original-To: freebsd-security@FreeBSD.org Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AD7716A41F for ; Fri, 19 Aug 2005 09:42:52 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1537C43D45 for ; Fri, 19 Aug 2005 09:42:51 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id E8B77C15E; Fri, 19 Aug 2005 11:42:50 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 13B4A405A; Fri, 19 Aug 2005 11:43:20 +0200 (CEST) Date: Fri, 19 Aug 2005 11:43:19 +0200 From: Jeremie Le Hen To: Attila Nagy Message-ID: <20050819094319.GW659@obiwan.tataz.chchile.org> References: <43049FB2.1030203@fsn.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43049FB2.1030203@fsn.hu> User-Agent: Mutt/1.5.9i Cc: freebsd-security@FreeBSD.org Subject: Re: Closing information leaks in jails? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2005 09:42:52 -0000 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 mtu 1500 > options=1a > ether 00:12:79:3d:83:c2 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 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 >