Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Dec 1998 05:37:01 +1300
From:      Joe Abley <jabley@clear.co.nz>
To:        Matthew Dillon <dillon@apollo.backplane.com>, Mark Murray <mark@grondar.za>
Cc:        Kevin Day <toasty@home.dragondata.com>, freebsd-current@FreeBSD.ORG, jabley@clear.co.nz
Subject:   Re: modification to exec in the kernel?
Message-ID:  <19981216053701.B27078@clear.co.nz>
In-Reply-To: <199812150917.BAA52694@apollo.backplane.com>; from Matthew Dillon on Tue, Dec 15, 1998 at 01:17:45AM -0800
References:  <19981215120357.B11837@clear.co.nz> <199812142331.RAA17203@home.dragondata.com> <19981215124818.A22526@clear.co.nz> <199812150644.IAA67338@greenpeace.grondar.za> <199812150917.BAA52694@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 15, 1998 at 01:17:45AM -0800, Matthew Dillon wrote:
> 
> :Joe Abley wrote:
> :> I looked at that; however, remember the users will have chrooted access
> :> to their directories, and within the chrooted tree will be /usr and
> :> descendants containing controlled binaries (owned by someone else, e.g.
> :> "root") like perl, awk, sh, etc.
> :
> :Your security model is flawed. A user can do anything she wants
> :(justabout) with shellscript and perl. Picking on compiled binaries
> :is not going to make you that much safer.
> :
> :M
> 
>     I think a chroot'd environment can be even *more* dangerous then a 
>     non-chroot'd environment because critical system configuration files
>     will be missing and potentially creatable by the user - if the
>     chroot'd environment is based in a user-owned directory and you've
>     installed any suid or sgid system binaries, you have an extremely
>     serious security hole on your hands.

It wasn't our intention to have _any_ setuid/setgid binaries available in
the chrooted environment - and the /, /usr, /var, /etc directories would not
be user-owned, but rather hardlinks to private copies of the appropriate
directories owned by some non-user uid.

So how is this more dangerous than a non-chrooted environment? Surely it
is _as_ safe - but with the added control that the user sees an appropriate
subset of the entire filesystem that is controlled, regardless of what the
system as a whole needs to have installed in order to function?


Joe


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981216053701.B27078>