Date: Sat, 4 May 2002 21:30:08 +0400 From: Dmitry <dima@haali.cs.msu.ru> To: arch@FreeBSD.ORG Subject: Re: df(1) Broken in jail(8) Message-ID: <20020504173008.GA92411@haali.cs.msu.ru> In-Reply-To: <20020503203340.A74245@blossom.cjclark.org> References: <20020503203340.A74245@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 03, 2002 at 08:33:40PM -0700, Crist J. Clark wrote: > The df(1) utility is broken in jail(8) environments. I could > understand if it was totally broken, there are things you can't and > shouldn't be able to do in a jail(8). However, df(1) behavior is > inconsistent. > > The getmntinfo(3) function (via the getfsstat(2) call) works in a > jail(8). When the output is generated from its output, df(1) works > (but the info isn't offset to the jail(8)'s root). However, when one > specifies individual filesystems or uses the '-t' option, the > information on the mount point is gathered using a statfs(2) > call. Since this takes a path, which will be offset to the jail(8) > root when processed, as an argument, the results are basically > broken. > > There are several ways to fix this, and I've come here for > opinions. > > 1) One can not use statfs(2) for '-t,' but stick with > getmntinfo(3)'s info only. But it makes some sense to stick with > statfs(2) for file aguments provided to df(1). This is fairly > easy to implement. > > 2) One can remove the ability to use df(1) at all in a jail(8). It > could be argued that there is no real reason to be able to use > things like getfsstat(2) or statfs(2) in a jail(8) (but what else > might this break?). This is easy to do. Actually I think the only good idea is to prevent jailed users from getting any info about host with his jail. Jail was created to improve security. So, if jailed user CAN'T guess what host jail is running, he can't use jail to attack the main box. So, I think that hiding main box' info from jailed users is even more usefull than adding multiIP jail or like. I think there must be 3 main ideas: 1) Jailed user must not have ability to change main box info (Thanx to FreeBSD team it's done with jail :) 2) Jailed user must not have ability to get any info about main host. This incluses, but not limitid to: - df (Why user without access to filesystem should know it's size, usage or existance at all?) - network information (ARP table, IP routing table, netmask, interface statistics, etc) - dmesg (Jailed user actually gets ALL host configuration. Look at ifconfig within jail: it shows only 1 network card while dmesg shows all hardware and it's configuration within jail; it shows messages about system problems, so hacker within jail can see how to DOS main box or even see panic messages when he tries to exploit main box from somewhere) - sysctl (90% of it's info is not needed in jail and must be hidden) 3) Jailed user must not have a way to find out he is in jail. Hmm, seems it is too hard for now :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020504173008.GA92411>