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

[John Baldwin]

On Thursday, February 06, 2014 3:53:00 pm Alexander Leidinger wrote:
> On Wed, 05 Feb 2014 14:05:29 -0500
> John Baldwin <jhb at freebsd.org> wrote:
> 
> > 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.
> 
> I think we need to differentiate between security and safety here. The
> allow_kmem flag disables security (protections against a malicious
> program which was written specially to make use of kmem/io to do
> something nasty and requires much more knowledge to write) but does not
> allow all the other things for which we have flags (raw sockets,
> chflags, mount). The safety aspect comes into play when you have badly
> behaving programs (in the sense of bugs, stupid programmers or unwanted
> behavior in some parts of a program). In such a case you may want to
> allow kmem access, but not raw socket / ... access.

If a programmer writing a program can't be trusted to use a raw socket, you 
really think they can be trusted with kmem access?  If they are careful
enough to be trusted with kmem access, they are careful enough to be trusted
to only open a raw socket if they need it.  The problem with kmem is that
it subverts everything you could put into place including capsicum, etc.  Put 
another way: if you think you can't trust the program to not open a raw 
socket, then you definitely shouldn't trust it with kmem access.  Also, in 
terms of bugs, kmem access is actually far worse!  Now if you get a simple 
buffer overflow you might end up trashing kmem.  I'd much rather a buggy 
program open a raw socket than be able to open /dev/kmem.

> Having it as a flag does not imply to me that is is only partly
> violating security, I think it is just a matter of wording. Either in
> the description of the flag, or additionally in the naming of the
> flag (maybe more in the sense of allow.open_backdoor?)

All the other flags poke small holes in the existing jail barrier.  The kmem 
flag shreds the barrier, so it is not of the same class.  Any new flag that 
removes all security needs to be very explicitly labelled as such so that it 
is clear to users what is actually occurring.

> > 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".
> 
> Personally I wouldn't object if we replace the kmem flag with a "no
> security at all" solution, I would keep the patch locally until the
> long term solution may or may not surface.
> 
> Note: over the years I had several people which were interested in my
> patch. Not an overwhelming amount, but still, there are people
> interested in it.

Interest in a patch doesn't mean it is correct.

-- 
John Baldwin