Hey all, I think that there should be a warning (on the jail man page or handbook page perhaps), on setuid in jails. Ex: John <-- user on the (host) server I give John root access to a jail (just for him to play with), and he then sets vi (for example) to setuid root. He then sshs into the host, and uses $ /usr/jail/johnsandbox/usr/bin/vi /usr/local/etc/sudoers He now has root! Am I completely thick not to have noticed this, or should there be a warning about people being allowed to have root in a jail where they have unprivileged access to the host? Or have I missed the point of a jail? Regards Chris -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf)
The best practice that I've been following is to not offer any services on the host install and do not allow users to login to the host. The only accounts on the host are root, and my admin user. On Thu, Jan 15, 2009 at 9:09 AM, Chris Rees <utisoft@googlemail.com> wrote:> Hey all, > > I think that there should be a warning (on the jail man page or > handbook page perhaps), on setuid in jails. Ex: > > John <-- user on the (host) server > > I give John root access to a jail (just for him to play with), and he > then sets vi (for example) to setuid root. He then sshs into the host, > and uses > > $ /usr/jail/johnsandbox/usr/bin/vi /usr/local/etc/sudoers > > He now has root! > > Am I completely thick not to have noticed this, or should there be a > warning about people being allowed to have root in a jail where they > have unprivileged access to the host? Or have I missed the point of a > jail? > > Regards > > Chris > -- > R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" >
On Thu, Jan 15, 2009 at 11:09 AM, Chris Rees <utisoft@googlemail.com> wrote:> Hey all, > > I think that there should be a warning (on the jail man page or > handbook page perhaps), on setuid in jails. Ex: > > John <-- user on the (host) server > > I give John root access to a jail (just for him to play with), and he > then sets vi (for example) to setuid root. He then sshs into the host, > and uses > > $ /usr/jail/johnsandbox/usr/bin/vi /usr/local/etc/sudoers > > He now has root! > > Am I completely thick not to have noticed this, or should there be a > warning about people being allowed to have root in a jail where they > have unprivileged access to the host? Or have I missed the point of a > jail? >Nice catch! My SOP is to chmod 700 on the directory hosting the jails. Your example is a file system issue that is shared between multiple levels of trust for one user. FreeBSD jails do not offer protection on the file system space outside of the jail. This should be documented as a gotcha, though. Another thing to think about is user IDs. You could have a user ID in your host of 1001. Your jail could have a completely different user account, but collide on the user ID of 1001. Your host user ID 1001 will have access to those jail user ID 1001 files, unless you restrict a parent directory. That was the use case I came across and avoided. Jon
On Thu, 15 Jan 2009 17:09:05 +0000, "Chris Rees" <utisoft@googlemail.com> wrote:> Hey all, > > I think that there should be a warning (on the jail man page or > handbook page perhaps), on setuid in jails. Ex: > > John <-- user on the (host) server > > I give John root access to a jail (just for him to play with), and he > then sets vi (for example) to setuid root. He then sshs into the host, > and uses > > $ /usr/jail/johnsandbox/usr/bin/vi /usr/local/etc/sudoers > > He now has root!If the host system and the jail share the `john' user *and* you are sharing `/usr/local' as read-write between the host and the jail, then ``you are doing it wrong!''. But that's a good warning to add somewhere in the jail documentation :)
Am 15.01.2009 um 19:31 schrieb Jon Passki:> Another thing to think about is user IDs. You could have a user ID > in your host of 1001. Your jail could have a completely different > user > account, but collide on the user ID of 1001. Your host user ID 1001 > will > have access to those jail user ID 1001 files, unless you restrict a > parent > directory. That was the use case I came across and avoided.I do not think restricting directories will help you a lot against these attacks. User 1001 on the host has access to all running processes of user 1001 in the jail and should be able to simply inject code to read the files via debugging interfaces. As Snuggles said, best practice is to not allow access to the host to anyone. If you have to, you should avoid collisions of user IDs. Greetings Jan
---------- Forwarded message ---------- From: Chris Rees <utisoft@googlemail.com> Date: 2009/1/17 Subject: Re: Thoughts on jail privilege (FAQ submission) To: Jan Demter <jan-mailinglists@demter.de> 2009/1/17 Jan Demter <jan-mailinglists@demter.de>:> Am 15.01.2009 um 19:31 schrieb Jon Passki: > >> Another thing to think about is user IDs. You could have a user ID >> in your host of 1001. Your jail could have a completely different user >> account, but collide on the user ID of 1001. Your host user ID 1001 will >> have access to those jail user ID 1001 files, unless you restrict a parent >> directory. That was the use case I came across and avoided. > > I do not think restricting directories will help you a lot against these > attacks. > User 1001 on the host has access to all running processes of user 1001 in > the jail and should be able to simply inject code to read the files via > debugging interfaces. > As Snuggles said, best practice is to not allow access to the host to > anyone. If you have to, you should avoid collisions of user IDs. > > Greetings > Jan > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" >I find it quite strange that user 1001 can send signals to a jailed process of UID 1001. Is that intentional, or would it be a *lot* of working round to check the UID _and_ JID when signals are sent etc? I appreciate that UID collisions should be avoided, but I also think the documentation should cover these gotchas. The Handbook is beautiful, and taught me FreeBSD from start to finish, so I don't consider it an advanced-users only reference. I appreciate that jails are quite advanced, but I do think the security concerns should be listed. We all forget things :) I might post to the doc list later to suggest this. I'll provide a patch if necessary. Chris -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf)