Configuration differences for jails

[Devon H. O'Dell]

On Thu, Apr 21, 2005 at 08:23:46AM -0400, c0ldbyte wrote:
> On Thu, 21 Apr 2005, Joerg Sonnenberger wrote:
> 
> >On Thu, Apr 21, 2005 at 07:39:08AM -0400, c0ldbyte wrote:
> >>Now if that last question is correct and thats the proccess you are using
> >>to create a jail then depending on the situation wouldnt that inturn
> >>defeat some of the main purposes of the jail, like the following. If you
> >>mounted your "/bin" on "/mnt/jail/bin" then if a person that was looking
> >>to break in and effect the system that is currently locked in the "jail"
> >>all he would have to do is just write something to the "jail/bin" which is
> >>actualy your root "/bin" and then the next time a binary is used from your
> >>root directories it could still infect the rest of the system ultimately
> >>defeating the purpose of what you just set up. To my understanding and use
> >>a jail is somewhat totaly independent of the OS that it resides in and
> >>wont be if you are using nullfs to mount root binary directories on it.
> >
> >ro mount as written by grant parent protects against this.
> >
> >Joerg
> 
> Right, I saw the (ro) option as you specified, but still there have
> been flaws in the sytem and forseen more flaws to come as allmost
> any programmer these days come accross and to just rely on it being
> (ro) just seems kind of not something that you should look to totaly
> to protect the system that the jail resides on. Even though in the
> unpredicted future a jail could be broken out of to such a instance
> I consider it to be a safer practice to just make installworld
> $DESTDIR && make distribution DESTDIR=$DESTJAIL -DNO_MAKEDEV_RUN
> and just delete stuff out of $DESTJAIL that you dont need for things
> to run properly and then there is never a instance or less of a
> chance that things will go wrong for you. As I said before depending
> on the use of the jail as well would also be a determination on
> how the jail is setup to but should never interact with the main
> system that holds the jail.
> 
> Thats only my opinion though and just releaves thought about other
> security issues that deal with the main part of the system.

Well he's per his statement using it in a virtual server
environment where he would simply like to ease administrative
work by reducing the number of jails that need to be upgraded
every time. The likelyhood of there being an issue with read only
mounts is quite low. I'd consider the ability to break out of a
jail as more of a threat than that. Additionally, I'm pretty sure
it wouldn't be very difficult to prove that there are no issues
with this. Read only mounts are so useful, and frequent, that I'm
quite sure we'd know if there were security issues with them.

As with any jail, you are in part trusting the security of the
main machine, since it has access to all the jailed environments.
I'd be worried about this being compromised before I point out
possible (non-existant) issues with read-only mounts.

--Devon

> -- 
> ( When in doubt, use brute force. -- Ken Thompson 1998 )
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 
> !DSPAM:42679acd458596534657138!
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20050421/e961ce00/attachment.bin