Re: /sbin/reboot and secmodel

[christos%astron.com@localhost (Christos Zoulas)]

In article <47DED750.5080409%NetBSD.org@localhost>, Elad Efrat  
<elad%NetBSD.org@localhost> wrote:
>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...

Kill is already special-cased on pid == 1... Perhaps we can add the
kauth glue for reboot (permission check) there too?

christos