Re: /sbin/reboot and secmodel

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

Brian Buhrow wrote:
>         Hello.  I haven't looked, but I assume that reboot(8) and shutdown(8)
> currently fetch a list of processes to signal, then signal each process in
> turn? 

Nope, a reboot ends up in reboot(8), which calls kill(-1, ...) to send a
a signal to all processes. It *assumes* it's "all processes" because the
semantics say that, according to kill(2):

        If pid is -1:
        If the user has super-user privileges, the signal is sent to all
        processes excluding system processes and the process sending the
        signal.

Technically what happens is that the kernel will try signaling all
processes:

        http://nxr.netbsd.org/source/xref/sys/kern/kern_sig.c#killpg1

Here the secmodel comes into the picture, preventing (for bsd44) from
non-root users from signaling a process they're not supposed to. So if
you granted access to reboot(2) to user-id 1000, he would be cable to
directly call reboot(2), but executing reboot(8) would fail as he does
not have enough privileges to signal all processes.

> If so, then it would make sense to me to have the sec model either
> permit or deny each signal to be sent from one process to another, based on
> the sending process's credentials.  Since signal(2) is another system call,
> wouldn't it make sense to just have it be another system call that the sec
> model guards  It seems like this approach has the advantage that you don't
> need to change the already working prorgrams, and there's a general
> solution for the question, how can I permit an arbitrary process that's not
> root or the current user, to send a signal to another process on the
> system?

First, the secmodel is not guarding system calls. The secmodel is
supposed to permit or deny operations; these may boil down to access to
a certain syscall or not, but we're definitely not limited to that.

That said, the problem we're trying to solve is how to allow a certain
user to reboot the system, preferably a graceful reboot via reboot(8),
which includes sending signals to all processes to give them a chance to
exit cleanly.

The problem is when you group the two together. If we imply that
permission to reboot the system implies permission to send SIGTERM and
SIGKILL to any process, the latter not necessarily done as a result of
the former, we may be forcing secmodel authors to grant permissions they
are not interested in to certain users, hence limiting the flexibility
of the secmodel.

-e.