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. -- Dan.
Attachment:
pgppByB13TGEK.pgp
Description: PGP signature