Date: Thu, 21 Apr 2005 14:28:37 +0200 From: "Devon H. O'Dell " <dodell@offmyserver.com> To: freebsd-hackers@freebsd.org Subject: Re: Configuration differences for jails Message-ID: <20050421122837.GK41520@smp500.sitetronics.com> In-Reply-To: <20050421081253.S51738@eleanor.us1.wmi.uvac.net> References: <BAY2-F389017D4F55242220F49FFF22B0@phx.gbl> <20050420151104.GA11753@grummit.biaix.org> <20050421073009.G51738@eleanor.us1.wmi.uvac.net> <20050421114359.GA10842@britannica.bec.de> <20050421081253.S51738@eleanor.us1.wmi.uvac.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--tAmVnWIZ6lqEAvSf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 21, 2005 at 08:23:46AM -0400, c0ldbyte wrote: > On Thu, 21 Apr 2005, Joerg Sonnenberger wrote: >=20 > >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 usi= ng > >>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 y= our > >>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 >=20 > 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=3D$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. >=20 > 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 > --=20 > ( 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 "freebsd-hackers-unsubscribe@freebsd.org" >=20 > !DSPAM:42679acd458596534657138! >=20 --tAmVnWIZ6lqEAvSf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCZ5x1Skf3jVXOdl0RAqANAJ45cSAtX391eM9sCz4vLC4m+WnCnQCgmisx 3s62tN8SN+S0r8Px/HKQRQI= =C29+ -----END PGP SIGNATURE----- --tAmVnWIZ6lqEAvSf--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050421122837.GK41520>