Re: /sbin/reboot and secmodel

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

Matthew Mondor wrote:
> On Monday, 17 Mar 2008 2:26:02
> Elad Efrat <elad%NetBSD.org@localhost> wrote:
>
> > The problem is when you group the two together. If we imply
> > thatpermission to reboot the system implies permission to send
> > SIGTERM andSIGKILL to any process, the latter not necessarily done
> > as a result ofthe former, we may be forcing secmodel authors to
> > grant permissions theyare not interested in to certain users,
> > hence limiting the flexibilityof the secmodel.
>
> I totally agree.  I would personally consider it a security hole to
> allow a user to signal(2) any process just because that user should be
> able to shutdown/reboot.  The setgid bit appears like a better
> solution to that, simply because it enforces/allows permissions on a
> per-executable basis.
>
> There certainly are other such cases where setuid/setgid elimination
> will be problematic...  It would be nice to be able to come up with a
> general mechanism which could solve this situation in all similar
> cases that'll come up.

I agree that there might be other cases where we'll find userland
programs imposing difficulties on secmodel authors; I'm not sure yet
how feasible it will be to be able to solve all these cases with a
single mechanism. Perhaps we should first identify some/most/all such
code and see from there how to handle it...

> Unfortunately I don't have an ideal solution to recommend at the
> moment, though :)  I thought of the introduction of a new syscall for
> a process to temporarily request access to a syscall, which is
> immediately revoked after said syscall but this would require changes
> to syscalls (or stubs) as well as a kind of access list so also
> doesn't seem ideal.

How would that help, though? you would request temporary access to
kill(2), the kernel would grant it, and then you could just kill
the reboot(8) process... no?

> Is setgid in a few cases that bad if those binaries were evaluated as
> "trusted" by the system? > If not perhaps that the build/install
> process  could inherently use veriexec (or a similar system like
> support for execution of signed binaries) for such trusted binaries in
> the future, automatically?  Independent of the current veriexec level
> these could be handled as a special case?  This might make upgrade
> procedures more tedious perhaps.  Just other ideas to think of...

The real problem is that the same program, ran by the user doing the
reboot, is both calling kill(2) and reboot(2). At the moment, nothing
prevents a user from timing a SIGKILL so that reboot(8) gets to kill
a few processes before it itself gets killed, but before making it to
the reboot(2) call.

I'm wondering if there's a way we can "encapsulate" the entire reboot
process, such that a user can initiate it -- but not interfere with it.

In addition to the direction I proposed, others brought up using init,
and having the kernel tell it it needs to perform a reboot. This is a
good direction, but I'm still unsure whether we want to go that route
of making init even more special, and what would the implications of
doing so mean for secmodel authors...

-e.