From owner-freebsd-current@FreeBSD.ORG Mon Jun 17 21:02:05 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 803972B3; Mon, 17 Jun 2013 21:02:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 3C3001F76; Mon, 17 Jun 2013 21:02:05 +0000 (UTC) Received: from [10.0.1.12] (host109-158-222-45.range109-158.btcentralplus.com [109.158.222.45]) by cyrus.watson.org (Postfix) with ESMTPSA id 8648F46B5B; Mon, 17 Jun 2013 17:02:03 -0400 (EDT) Subject: Re: A PRIV_* flag for /dev/mem? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <201306162248.r5GMmvk5021473@chez.mckusick.com> Date: Mon, 17 Jun 2013 22:02:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4EE0B82F-9676-4C4C-AC27-9680CE518FE4@FreeBSD.org> References: <201306162248.r5GMmvk5021473@chez.mckusick.com> To: Kirk McKusick X-Mailer: Apple Mail (2.1283) Cc: Konstantin Belousov , FreeBSD Current , Alexander Leidinger , Jamie Gritton X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 21:02:05 -0000 On 16 Jun 2013, at 23:48, Kirk McKusick wrote: >> I suppose it's safe to say further comment isn't forthcoming. So with >> one vote for and one against (or at least questioning), I'll humbly >> leave it up to myself to be the tie-breaker :-). >>=20 >> Here's a proposed patch. I separate kmem access into read and write, = as >> I saw other similar splits in the priv list. Perhaps that's overkill, >> and I can use a single PRIV_KMEM instead of PRIV_KMEM_READ and >> PRIV_KMEM_WRITE. >>=20 >> Perhaps this is an overreach, because PRIV_KMEM_READ is used where = the >> default isn't root privilege: the file permission and expected usage = are >> group kmem gets to read /dev/[k]mem. I'm not about to go hard-coding = a >> gid into the kernel, so it seems the proper thing to do (not included = in >> the patch) would be to allow PRIV_KMEM_READ by default. I thought = there >> might already be such cases where the default is to allow, but no: = this >> would be the first default-allow permission. So perhaps the best = answer >> is not worry about that one, and only add PRIV_KMEM_WRITE (leaving = reads >> controlled by file permission alone as they are now). >=20 > With the change from the error noted by Kostik, I concur with your=20 > proposed change. On the whole, the kernel privilege system is fairly straight-forward; = the one real exception its its interaction with device-driver specific = interfaces that seem privilege-like. On the whole, I take the view that = we should define privileges in device drivers where either (a) there's a = securelevel interaction or (b) it's likely we'll want to delegate access = to the device node (perhaps in jail, or via chmod/chown) but there are = special operations we still want to require privilege. For example, you = could imagine wanting read/write access to a disk to be delegated, but = not control operations to reset the bus it's on -- e.g., not wanting = that to occur in jail. /dev/kmem is particularly funky, since it = inherently bypasses most aspects of the TCB -- even read access is quite = dangerous, although not quite as overtly dangerous as write access. I'm = not sure I see a strong argument for introducing further privileges = here, as it's hard to imagine a situation where you'd delegate kmem = access and not mean to give out vast amounts of privilege. The main = argument for doing so would be that we wanted to pull securelevel checks = inside of priv(9), sucking awareness of securelevels out of most = consumer subsystems. More generally, there are many implied sources of privilege in the = system that don't go through priv(9) -- for example, uid 0 is not just = privileged because it is granted rights by priv(9), but also because it = owns lots of key files in the file system and can read/write them (e.g., = the password file). You can similarly argue that although aspects of the = TCB are protected by priv(9), others are protected by DAC (or optionally = MAC). This is simply an "unclean" bit of the UNIX design, and something = we end up accepting because the notion of TCB protection generally does = involve some lack of cleanliness, since it has to do with protecting = low-level parts of the system that aren't easily abstracted away (e.g., = device drivers). Robert=