Thoughts on jail privilege (FAQ submission)

[Chris Rees]

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)
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"

[Snuggles-2]

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 <[hidden email]> 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)
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "[hidden email]"
>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"

[Jon Passki-2]

On Thu, Jan 15, 2009 at 11:09 AM, Chris Rees <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"

[Giorgos Keramidas]

On Thu, 15 Jan 2009 17:09:05 +0000, "Chris Rees" <[hidden email]> 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 :)

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"

[Jan Demter]

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

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"

[Chris Rees]

---------- Forwarded message ----------
From: Chris Rees <[hidden email]>
Date: 2009/1/17
Subject: Re: Thoughts on jail privilege (FAQ submission)
To: Jan Demter <[hidden email]>


2009/1/17 Jan Demter <[hidden email]>:

> 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
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "[hidden email]"
>

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)
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"