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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
