[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: /sbin/reboot and secmodel
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
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...
Main Index |
Thread Index |