On Fri, Oct 03, 2014 at 05:01:20AM +0200, Peter Stuge wrote: > Steven J. Long wrote: > > On Tue, Sep 30, 2014 at 07:52:02AM -0700, Zac Medico wrote: > > > The IPC implementation that I've suggested does not involve an SUID > > > helper, so it is much more secure. Security would rely on the permission > > > bits of the named pipes that are used to implement IPC. > .. > > I don't see how that's "more secure" > > It's a lot more secure to have a single well-defined privileged trust > anchor (the privileged process) with a well-defined protocol, than to > have built-in privilege escalation which allows arbitrary actions.
You appear to have missed the point of what it does. All you'd be doing is providing the exact same ability, in a much more convoluted manner. Since after all the whole point is to run arbitrary commands that affect the root system. As stated, now you have to implement the listener, which has to load the env, and a protocol for communication, which no doubt is going to change over time. On top of the usual work, ie what a suid helper would have to do in any case. And you've just provided a nice juicy vector for someone who can crack portage or python at any future point, or just get portage uid via ANY other vector, to use your "well-defined protocol" (you hope) to execute arbitrary actions, since that is *precisely* the point of it. The security you mention is nothing but a pipe-dream; reliant on user permission over the fifo and containing dir which is _exactly_ the same kernel mechanism you can apply to an suid helper, *without* all the moving parts and the hopeful intentions (because it "sounds good") leave alone yaf daemon running to subvert the usual security mechanism. Any method you can think of to provide verification of what's happening, is just more complexity that can and will be gamed; and crackers only have to get lucky once, in millions of automated attempts. Why give them a target in the first place; you're just encouraging noise and waste of bandwidth + cycles. And as stated, it doesn't get you the env from the command in any case, so I don't see the point at all. All it does is add maintenance headache and a false sense of security. It's more secure to have a smaller, tighter "trust anchor" that does as little as possible and can be audited, as opposed to _hoping_ that our latest python download, is so large there's nothing obviously wrong. Sure the suid helper is a target too: get portage uid and run that. What's the difference when you have a daemon? None. Both rely on the kernel to enforce access permission. (which is why agent accounts can never login, and are not in any of the groups we add ourselves to.) So if it's the same access permission.. It's just much easier thereafter to attack a daemon, where the people whose code you're attacking have many more things to worry about, which tends to change over time, than a small focussed program, which can then have more checks built-in (assuming you go for a custom impl as opposed to existing mechanisms that are proven.) The same ones you'd end up adding to the daemon, only without having to worry about maintaining a protocol, the daemon and the client as well. As a result you can cut to the chase, and focus on what matters. Though personally I'd rather rely on the admin as well as the developer, to keep an eye on their own system. sudo just happens to have it all taken care of for us, and be a much better focus for many distros to ensure security, and tie into PAM, rather than everyone go off and try it in the script-language dejour. As well as integrate cleanly with everything else. It's even easy for the admin to switch it off in case of concern, in the same place they deal with other security problems, and indeed restrict times and so much more; things we'd end up getting bugs about adding, and so the cycle of featuritis and reimplementation of the wheel goes. There's much more control, and we get it for zero effort. It's also transparent to the admin, as opposed to a bespoke implementation they know nothing about. (which is why people collaborate cross-platform.) But like I said, I don't particularly care how it's implemented so long as it's not a method which sounds nice but has nothing else to recommend it, and opens gaping holes on closer analysis. Using a suid helper means you can delegate the work to someone who's focussed on it, and it can remain *small*. sudo has a lot going for it, that means we have much less to worry about. By all means show me where I'm wrong; but answer the substantive points, please. In summary you'd be providing the same ability, and the exact same access control, with a much crappier method, convoluted and much more fragile, apparently because it sounds nice. gack. Regards steveL Next it'll be javascript with a fast-moving engine.. lul. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
