Re: /sbin/reboot and secmodel

["Matthew Mondor" <mm_lists%pulsar-zone.net@localhost>]

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.

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.

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



-- 
Matthew Mondor