tech-kern archive

[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).


Home | Main Index | Thread Index | Old Index