tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: /sbin/reboot and secmodel

Brian Buhrow wrote:
        Hello.  What does the secmodel have to work with in terms of
authorization tokens?  What I'm thinking here is that I understand that it
is a two stage process to reboot a system, first send signals to all
processes, then actually reboot the system.  While it might not be
desirable to always allow a given user who ordinarily can't send signals to
arbitrary processes to do so under the circumstance when he's rebooting the
system, it'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 tthat can evaluate that the calling process is the
shut down program, that the calling user is permitted to run the shutdown
program, and that tasks associated with this procedure, i.e. those routines
the shutdown program calls, should be permitted.

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?

        As I think about it, this is precisely why the Set[GU]id bits came
into being in the first place.  Specifically, the reason is that system
calls are supposed to live independently of each other, but programs can be
written in user space to use those system calls as building blocks to do 
        In this case, you want to shut the machine down, and that process is a
multi-step process.  You only want the steps to be performed as an atomic
operation, i.e. you don't want the user to be able to perform step 1,
signal processes, without also performing step 2, rebooting.
        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? what sugid does is say "when you run
this program, always run it with this effective u/gid". 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? :)

Also, what do you mean by "the kernel only knows how to deal with user
level permissions"? (I think you're making some assumption here that may
not be correct)

        As Smb mentioned, one way around this problem, without putting too
much goo into the kernel, is to do some sort of reboot_authorize(2) which
checks to see if the caller is allowed to make the reboot call.  Part of
that new call could be to register the program's desire to make a reboot(2)
call, and thus to allow it to signal all processes.  I'm thinking the
reboot_authorize(2) call could return some sort of opaque token which could
then be passed to the signal(2) call to let  it know that this call is part
of a pending operation.  But, as I think about it, this technique doesn't
really work that well either, since there's no guarantee that the calling
program might not abuse the system by getting permission to call reboot,
calling signal(2) and then never calling reboot.

Exactly. I'm also not sure how welcome an addition of an argument to
signal(2) will be. ;)

        No, as I think about it, I think the sec model is interesting, but I
don't think it solves this particular problem, because there will always be
a need for programs to perform tasks that users cannot.

See above.


Home | Main Index | Thread Index | Old Index