From owner-svn-src-all@FreeBSD.ORG Thu Feb 6 22:39:14 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1A9D3B0; Thu, 6 Feb 2014 22:39:13 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B36911CAD; Thu, 6 Feb 2014 22:39:13 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A41C8B948; Thu, 6 Feb 2014 17:39:12 -0500 (EST) From: John Baldwin To: Alexander Leidinger Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail Date: Thu, 6 Feb 2014 16:56:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <2362081.WrjYmKeYu9@ralph.baldwin.cx> <20140206215300.000014a3@unknown> In-Reply-To: <20140206215300.000014a3@unknown> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402061656.32364.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 06 Feb 2014 17:39:12 -0500 (EST) Cc: src-committers@freebsd.org, Doug Ambrisko , svn-src-all@freebsd.org, Gleb Smirnoff , Robert Watson , James Gritton , svn-src-head@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 22:39:14 -0000 On Thursday, February 06, 2014 3:53:00 pm Alexander Leidinger wrote: > On Wed, 05 Feb 2014 14:05:29 -0500 > John Baldwin 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