set user id for service ?
david at fubar.dk
Wed Sep 20 02:39:53 BST 2006
On Wed, 2006-09-20 at 01:46 +0100, Scott James Remnant wrote:
> On Tue, 2006-09-19 at 15:43 -0400, David Zeuthen wrote:
> > On Sat, 2006-09-16 at 01:48 +0100, Scott James Remnant wrote:
> > > GNOME Power Manager is an example of something that does one thing,
> > > dealing with power management, and does it well.
> > One question: how can you trust the events that g-p-m would send to
> > upstart are genuine? Ie. how do you ensure that they don't come from a
> > malicous attacker? Seems like you can't do this securely...
> If an malicious attacker has root, you already have bigger problems.
> One of the reasons upstart has its own IPC is so that it can obtain the
> pid and, more importantly, uid of the process sending the message.
> It never runs anything the requester doesn't have permission,
> themselves, to run.
So, if I'm running a normal desktop session and AC is unplugged, then
g-p-m, running as uid 500, will poke the upstart daemon. Fine. The admin
have written an upstart rule to do stuff and that gets invoked. Will
that be invoked as uid 500? That wouldn't be very useful for the admin.
If the program spawned by upstart is running as uid 0 (or whatever the
upstart rule specified), how do you prevent a malicious attacker from
just poking the upstart daemon the same way g-p-m did? In the extreme
(because you can't know what the admin wants to run), this leads to
privilege escalation. An attacker with uid 500 is now able to get code
running as uid 0.
In other words, I'm saying you can't trust g-p-m to give you the right
events (in particular because it uses GTK+ and one feature (not flaw) is
that GTK+ supports loadable modules). And that's fine. We shouldn't have
to design g-p-m to give such guarantees. That's just a trade off.
Not sure it's a huge concern, perhaps all you need to do is provide docs
saying that if a user session is compromised such events cannot be
trusted. Hence, the admin needs to be careful about this, at the very
least be aware of it.
(And you probably want some rate limiting too.)
Depends. I think for upstart to be useful you need to handle events
originating from a desktop session and potentially allow these events to
results in running code as uid 0 if that is the wish of the admin (as
I've tried to outline above).
After all, interesting events (new email, new instant message etc. etc.)
can only originate from the desktop session.
So, I'm saying it really depends on your trust model. Personally I think
the system is screwed if an user account is compromised but YMMV. If you
don't want to handle events originating from the desktop session you can
always get the events from HAL - that's where g-p-m gets them from
> > http://bugzilla.gnome.org/show_bug.cgi?id=333031
> > for g-p-m to run user scripts when significant events happen.
> I would say that this is an excellent example of where upstart slots in.
> Why do we need yet _another_ *.d directory, with yet more semantics
> about how it works?
> Why does yet another daemon need to gain the ability to iterate scripts,
> with yet more naming semantics (ie. ignoring *.dpkg-old) and having the
> same bugs that others do, such as leaking file descriptors, not killing
> or reaping the process correctly, and so on.
> g-p-m should arrange for upstart to be notified of the event, probably
> just through the dbus messages that announce these changes, and let the
> dedicated service/task manager process take care of running the scripts.
It, of course, make sense to just make upstart handle this.
Alternatively, it would be useful with either 1) a library; or 2)
service in the session; that things like g-p-m could use to do this.
g_spawn() isn't too terrible but I hate to see each policy daemon
rolling their own including addressing all the concerns you list above.
For integrating g-p-m with upstart.. instead of patching g-p-m... you
can listen to events on the session message bus... meaning you need
something running in the desktop session to poke upstart.
More information about the Upstart-devel