[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: /sbin/reboot and secmodel
der Mouse wrote:
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
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
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).
Our case discusses giving specific permissions to users, not programs.
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.
But you're not solving the real problem, which is the ability of a user
to create a program that ignores SIGTERM, waits for a reboot to undergo,
and SIGKILL the reboot process, leveraging the privilege to reboot the
system to that of killing arbitrary processes.
Main Index |
Thread Index |