tech-kern archive

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

Re: /sbin/reboot and secmodel

Matthew Mondor wrote:
On Monday, 17 Mar 2008 2:26:02
Elad Efrat <> 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...


Home | Main Index | Thread Index | Old Index