[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: /sbin/reboot and secmodel
At 11:15 AM 3/18/2008 -0400, der Mouse wrote:
> 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.
You are right, I was not trying to solve this issue (indeed, I did
not have a clear understanding that this is one of the problems we're
trying to solve) -- I thought the problem was that there was no way
to distinguish the kill(2) that came from reboot(8) after the
reboot(2) was approved, from a kill(2) that came from any other process.
Perhaps these are two separate processes.
> 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....
I had not considered that, either, but if <context> were a vector of
things representing capabilities (e.g. a vector of file handles), it
would suffice, I would think. In some sense, I was trying to present
a solution-pattern, not a concrete solution. Sometimes it's easier
to discuss a pattern first, then discuss the concrete application
after a pattern has been selected.
It struck me that using file handles to represent capabilities was a
Unix-like approach (probably I'm remembering a suggestion someone else made).
Main Index |
Thread Index |