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.
--
( When in doubt, use brute force. -- Ken Thompson 1998 )
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
