svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail

[Doug Ambrisko]

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 <rwatson at 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.