Date: Sun, 8 Sep 2002 04:41:25 -0700 From: Benjamin Krueger <benjamin@seattleFenix.net> To: Hans Zaunere <zaunere@yahoo.com> Cc: freebsd-security@freebsd.org Subject: Re: jail() House Rock Message-ID: <20020908044125.C98271@mail.seattleFenix.net> In-Reply-To: <20020906185814.71834.qmail@web12803.mail.yahoo.com>; from zaunere@yahoo.com on Fri, Sep 06, 2002 at 11:58:14AM -0700 References: <20020906185814.71834.qmail@web12803.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Hans Zaunere (zaunere@yahoo.com) [020906 11:57]: > > I'm looking to provide jail()'d root access to clients (the virtual > private server bit). I myself have been a client on several of these > setups, and while some are better than others, I often find missing and > broken features - and I've never even looked at it from a security > standpoint. > > Aside from the commonly known man pages/handbooks/etc is there a > definitve source for PROPERLY setting one of these systems up? > Something that outlines what features mean decreased security? > Something that outlines proper layout of these systems? Then I can > judge exactly what and what not to offer. I already have a good handle > on security of regular systems, so something specific to the jail()'d > environment would be best, as I'm sure there are some gotchas and such. > > Thank you, > > Hans Think carefully about exactly what kind of privileges your clients get. A friend asked me recently if his users could escalate privileges if they have a normal user account on the main server, and root inside the jail. After some thinking we outlined a situation in which the user creates a suid binary to escalate any user to root inside the jail, and then runs it as a normal user outside the jail. Instant root. I doubt that there is a definative guide to absolutely securing a jailed environment. It took many years just to iron simple tmp and shell env escalations (such as IFS related issues) from most Unixes. Doubtless there are still undiscovered situations like that which can lead to escalated privileges. To resolve the situation we got above, we had him keep seperate unique UIDs in the main system and all the jails. Normal users were disallowed any access to any parts of the filesystem holding a jail. This is just a simple example, but that is the kind of thing you should start thinking about when designing systems like this. Regards, -- Benjamin Krueger "Everyone has wings, some folks just don't know what they're for" - B. Banzai ---------------------------------------------------------------- Send mail w/ subject 'send public key' or query for (0x251A4B18) Fingerprint = A642 F299 C1C1 C828 F186 A851 CFF0 7711 251A 4B18 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020908044125.C98271>