Re: /sbin/reboot and secmodel

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

> Our case discusses giving specific permissions to users, not
> programs.

We've discussed that, but we've discussed it as a solution for a
particular problem, that being certain aspects of rebooting the system.
I'm not convinced granting privileges to users is a good way to address
that problem.

>>> So you make sure only owner/group can execute the program.  Now you
>>> need to choose what user/group to setuid/setgid it to.  What do you
>>> choose?  root? :)
>> Traditionally, yes, because that was the only privilege available.
>> If you have finer-grained privileges, then set-ID bits are no longer
>> enough, precisely because they work at too crude a level.
> But you're not solving the real problem, which is the ability of a
> user to create a program that ignores SIGTERM, waits for a reboot to
> undergo, and SIGKILL the reboot process, leveraging the privilege to
> reboot the system to that of killing arbitrary processes.

(a) I'm not sure this is a real problem.  Rebooting the system *does*
involve killing all processes, so I'm not sure "leveraging" is a fair
term to use here.

(b) This is a problem only if privileged processes (ie, those running
programs marked with whatever set-ID bits turn into under this new
paradigm) are still subject to things like arbitrary signals fromk the
users who start them.  I'm inclined to say this is a bad idea, for
exactly this reason - basically, the same reason you traditionally
can't kill(2) a set-ID process you started.  Figuring out what this
restriction should turn into strikes me as hard.

What secmodels are really doing here is pushing us to throw out the
traditional Unix "there's root and there's user" privilege model.  This
is probably a good thing; it's needed an overhaul for a long time.  But
it has implications for a whole lot of other stuff that aren't obvious
at first blush - set-ID bits, signals, etc - and we're having to
redesign them correspondingly.  Worse, the resulting designs need to be
part of the secmodel, since they go hand-in-hand with the rest of the
secmodel's restrictions and permissions.  This means secmodels need a
way to express them.  Perhaps worse yet, since this affects things like
set-ID bits, secmodels imply changes to on-disk filesystems.

I'm beginning to think that secmodels, in their full generality, are
Just Too Hard for the moment, that we'll have to say "there are some
reasonable secmodels we can't support now" - for example, anything
calling for set-ID bits to be revamped.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse%rodents.montreal.qc.ca@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B