Re: /sbin/reboot and secmodel

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

I think Brian's note on this subject is very good; it clearly lays out
a bunch of things I'd been thinking but not quite clearly enough to put
into an email.

Elad replies to Brian,

>> [I]t's not clear the sec model, as currently implemented, provides
>> enough richness in the authentication and authorization tokens to
>> allow a sec policy to be written [to properly allow the cluster of
>> operations that constitute a reboot].
> Assuming you could do that, how would you make sure that a user
> granted the ability to reboot the system does not take advantage of
> this ability to let the reboot program kill some processes, and then
> SIGKILL it?

Exactly.  That's the weakness I see (Brian too, apparently).

>> Set[GU]id gets around the problem of building this complex concept
>> into the kernel, by authorizing programs, not users, to do special
>> tasks, even though the kernel only knows how to deal with user level
>> permissions.
> How does it "authorize" programs?

By putting set-ID bits on them.  Turning on the set-ID bit on a program
amounts to saying to the kernel "the cluster of operations performed by
this executable should run with this alternative set of privileges
rather than those of the calling user".  It's a very clever way of
encapsulating a more or less arbitrarily complex operation and giving
privilege to perform just that encapsulated operation.

When I tossed out my poorly-thought-out response "sudo?" upthread, I
think this is what I was actually getting at but didn't realize it:
that the kind of "encapsulate this" that set-ID bits provide is exactly
what we want here.  We just need to change them a bit; vide infra.

> what sugid does is say "when you run this program, always run it with
> this effective u/gid".

Yes...but you're describing the implementation rather than the thing
being implemented.  In a capability-based system, I would expect set-ID
bits to be replaced with a way to grant capabilities you hold to a
program, such that when the program runs, it runs with those
capabilities (whether in addition to or instead of the user's
capabilities is a debatable point; I can see arguments each way).

Oddly enough, that's exactly what VMS (which has much finer-grained
privileges than Unix) does - or at least did last I looked, which was
white a while ago.  They say such a program is "intalled with
privileges" rather than "set-ID", but this is what's going on: an
executable, which presumably encapsulates some operation, is marked as
running with extra privilege in order to perform that operation.  (Yes,
executables are installed for other reasons as well; I'm here talking
about only the case where it's installed in order for it to run with
additional privilege bits.)

> So you make sure only owner/group can execute the program.  Now you
> need to choose what user/group to setuid/setgid it to.  What do you
> choose?  root? :)

Traditionally, yes, because that was the only privilege available.  If
you have finer-grained privileges, then set-ID bits are no longer
enough, precisely because they work at too crude a level.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse%rodents.montreal.qc.ca@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B