Re: /sbin/reboot and secmodel

[Elad Efrat <elad%NetBSD.org@localhost>]

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 
> interesting
> things.
>         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.

-e.