Date: Mon, 17 Jun 2013 22:02:01 +0100 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Kirk McKusick <mckusick@mckusick.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Current <freebsd-current@FreeBSD.org>, Alexander Leidinger <netchild@FreeBSD.org>, Jamie Gritton <jamie@FreeBSD.org> Subject: Re: A PRIV_* flag for /dev/mem? Message-ID: <4EE0B82F-9676-4C4C-AC27-9680CE518FE4@FreeBSD.org> In-Reply-To: <201306162248.r5GMmvk5021473@chez.mckusick.com> References: <201306162248.r5GMmvk5021473@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EE0B82F-9676-4C4C-AC27-9680CE518FE4>