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

Alexander Leidinger Alexander at Leidinger.net
Thu Feb 6 20:53:04 UTC 2014


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.

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?)

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

Bye,
Alexander.

-- 
http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137


More information about the svn-src-head mailing list