Re: A PRIV_* flag for /dev/mem?

On 06/17/13 15:02, Robert N. M. Watson wrote:
>
> 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 :-).
>>>
>>> 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.
>>>
>>> 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).
>>
>> With the change from the error noted by Kostik, I concur with your
>> 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

Am I correct in reading this as an argument against? Interestingly, you
mention securelevel interaction, and the writing case for kmem has that.
But my proposed patch left that part alone, just adding a priv check
alongside it. I had considered rolling the securelevel into priv, but I
didn't see anything else there that checked securelevel, so I left it alone.

- Jamie