On Wed, Feb 05, 2014 at 02:05:29PM -0500, John Baldwin wrote: | On Monday, February 03, 2014 03:53:36 PM Doug Ambrisko wrote: | > On Fri, Jan 31, 2014 at 06:28:27PM -0700, James Gritton wrote: | > | On 1/31/2014 2:30 PM, Alexander Leidinger wrote: | > | > On Fri, 31 Jan 2014 12:34:48 +0000 (GMT) | > | > | > | > Robert Watson <rwat...@freebsd.org> wrote: | > | >> On Wed, 29 Jan 2014, Alexander Leidinger wrote: | > | >>>> It does. I included a warning in jail.8 that this will pretty | > | >>>> much undo jail security. There are still reasons some may want to | > | >>>> do this, but it's definitely not for everyone or even most people. | > | >>> | > | >>> It only "unjails" (= basically the same security level as the | > | >>> jail-host with the added benefit of the flexibility of a jail like | > | >>> easy moving from one system to another) the jail which has this | > | >>> flag set. All other jails without the flag can not "escape" to the | > | >>> host. | > | >>> | > | >>> I also have to add that just setting this flag does not give access | > | >>> to the host, you also have to configure a non-default devfs rule | > | >>> for this jail (to have the devices appear in the jail). | > | >> | > | >> This is not correct: devices do not need to be delegated in devfs for | > | >> PRIV_IO to allow bypass of the Jail security model, due to sysarch() | > | >> and the Linux-emulated equivalent, which turn out direct I/O access | > | >> from a user process without use of a device node. | > | > | > | > Ok, then it is just the non-default flag, not the additional devfs part. | > | > | > | > I agree with your other post that we are better of to document better | > | > what it means if an admin allows kmem access for a specific jail. | > | | > | I second the documentation route. Yes, it's true that this option | > | makes a totally insecure jail - at least one lacking the expected jail | > | security additions. But I think that while security is one of the | > | primary purposes of jails, it's not the only purpose. It should be | > | possible to have a trusted "master jail" that still takes advantage of | > | the encapsulation while allowing otherwise unsupported features such | > | as a desktop. | > | | > | The distinction of whether certain devices are required to break out | > | of a jail with allow.kmem is something of a red herring - the fact is | > | that anyone who wants this level of access is going to have the | > | devices in place anyway. | > | | > | I suppose "obviate" wasn't the best word for the situation. Maybe | > | something that starts with "WARNING: ..." is in order. | > | > It's unfortunate that vimage requires jail. I want to use vimage but | > not have the security restrictions of a jail. To do this I patched | > jail to basically let everything through. It would be nice to be | > able to run jail in an insecure mode which I understand is a contradition. | > I do use the jail infrastructure to set the uname*/getosreldate so | > that a specific jail thinks it is FreeBSD version blah. Then I can ssh | > into that jail and pkg_add things, make ports etc. I use this on | > my laptop running current on the base. My other jails run various | > versions of FreeBSD. I don't care about security in this case. | | There are certainly use cases for a "job" (imagine in a compute cluster). | Jails have some nice properties in that you can wait6/waitid for a jail, you | can forcefully kill an entire jail, and you can apply resource limits to a | jail collectively. | | I think having a "kmem" flag for jails is a hack and not the right approach. | It does make a jail useless security-wise, but by masquerading as a flag, it | implies that it is only partially violating security which gives a false sense | of security. | | A short term solution that would permit non-security jails without having to | do the longer term work that Robert would like might be to add a new per-jail | flag that in effect means "no security at all". You would then modify one | place (prison_priv_check() in kern_jail.c) to treat a jail with this flag set | as if it wasn't jailed at all. This would clearly communicate to a user what | they were doing by enabling this flag (jail --root-me-please), and it would | also avoid future proliferation of new flags to add more optional and obscure | holes in jails.
That is what my local patch/hack does, first line of prison_priv_check is just to return 0. So no security which is fine for what I use it for. As mentioned the jail infrastructure does have some nice features even with security turned off. Thanks, Doug A. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
