Re: /sbin/reboot and secmodel

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

> If extensibility is needed in the context of secauth, it seems that
> the right thing to do is:

> 1) add a way for a process to express the intent to do a reboot
> 2) the secauth framework checks whether the current user is
> authorized to cause this to happen
> 3) if so, a token (perhaps a special file handle) is handed back to
> the process
> 4) add a way to provide that token as context for subsequent syscalls
> [again, in that process].  Secauth uses that context, combined with
> the particular system call, to make its decisions.

As stated, this doesn't provide a way for something like reboot(8) to
prevent itself from being killed partway through its job.  As I wrote
upthread recently, I'm not sure this is as much of a problem in the
case of reboot as it's being made out to be, but the basic point is
valid: that when a nonprivileged user starts a complex privileged
operation, it should not necessarily be able to nuke it partway
through.  Traditional set-ID bits solve this as a side effect of the
"you can't kill(2) processes that aren't yours" restriction; I'm not
sure what should replace that.

> The "way" in step 4 could be a meta-syscall, sort of
> "(provide-security-context-for-syscall <context> (operation))"

That breaks as soon as a process has been granted two different
capabilities, both of which are needed for a particular operation.
Unless your meta-syscall has a way to take a whole list of
capabilities, that is....

/~\ 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