tech-kern archive

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

Re: /sbin/reboot and secmodel

On Tue, Mar 18, 2008 at 12:30:15PM -0400, der Mouse wrote:
> >> Traditional set-ID bits solve this as a side effect of the "you
> >> can't kill(2) processes that aren't yours" restriction; I'm not sure
> >> what should replace that.
> > So, for example, I don't see how a setgid program would be protected
> > against taking a signal if the same user is running it and sending
> > the signal.
> !!

I was really struggling to see any substantive difference between
"signal/invoke a service running with privs" and "run a tool with
set-ID privs" in the context of a secmodel's view of those privs.  
I see the "too many services" concern, but I was talking about
processes, not necessarily daemons. I also see solutions readily
available (eg launchers in the style of inetd, powerd, dm or sudo).

I really didn't see why you had such a strong preference for setID, at
least now I see what you thought this was giving you.

> (b) The whole discussion is a tempest in a teapot, since the risk we've
> been worrying about has been there all along and the world hasn't caved
> in, so I see nothing wrong with leaving it there at least for now.

Agreed. At least the discussion has reiterated or clarified the model
for how to deal with it if/when someone feels the need.

Essentially, kauth can authorise individual actions directly to users
where it makes sense for them to be called arbitrarily.  If instead
there is a workflow and sequence of privileged actions that need to be
managed as a whole, management of that sequence belongs in a
privileged and protected process (just like it always has, except the
privileges may now be other than root).

That process can be a daemon, if there's ongoing state to keep, or run
on demand via either a set-ID launcher or listening broker.  Some
organisation and consistency over these tools would be highly
desirable if they're to proliferate, especially if there should to be
additional policy and controls around launch rights.

Just like it's always been.


Attachment: pgppByB13TGEK.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index