[launchd-dev] Securing Launch Agents
Damien Sorresso
dsorresso at apple.com
Fri May 1 13:05:51 PDT 2009
Correction, SecurityAgent runs as a role account and cannot be killed
by the user. But please do not use it as a model as we would like to
change it.
--
Damien Sorresso
Sent from my iPhone.
On May 1, 2009, at 11:27 AM, Damien Sorresso <dsorresso at apple.com>
wrote:
> On May 1, 2009, at 4:53 AM, Dave Keck wrote:
>> Hey list,
>>
>> I've been writing some security software, part of which is a
>> system-wide agent (stored in /Library/LaunchAgents). I've almost got
>> it working to the point that I'm satisfied for a 1.0 release. That
>> was, until I realized two show-stopping facts. With a short trip to
>> the terminal, any user is able to:
>>
>> 1. Kill the agent
>> 2. Unload the agent using launchctl
>
> Agents run on a per-user basis, so they run as the user. This
> shouldn't surprise anyone.
>
>> Well, duh, you might say. When I started out, I assumed that since
>> the
>> write privileges of /Library/LaunchAgents are root:whell, the agents
>> loaded from that directory could only be affected by a user with
>> administrator credentials. Unfortunately for me, that simply ain't
>> so.
>> (Granted, a non-privileged user can only temporarily disable the
>> agent, as it will be reloaded when they logout and back in. But for
>> my
>> purposes, this is still unacceptable.)
>
> This will change in SnowLeopard. Users will be able to permanently
> disable agents residing in /System/Library/LaunchAgents and /Library/
> LaunchAgents.
>
>> (Also I should mention that I can't write a daemon because the
>> software must display a UI, and the UI itself is part of what
>> shouldn't be killed without admin credentials.)
>>
>> To me, what I'm trying to do seems reasonable. It'd be nice if the
>> UserName key was respected for agents installed in the system-wide
>> LaunchAgents directory, so the agent would run in the GUI context
>> of a
>> certain user, but would be out-of-reach (to unprivileged users) as
>> far
>> as unloading or killing the process. On the other hand, I suppose
>> respecting the UserName key conflicts with the whole notion of
>> LaunchAgents running on behalf of the current user. Is my request
>> reasonable or am I missing something?
>
> What you're trying to do is reasonable. The way you think it ought
> to be accomplished is not. The per-user launchd runs as the user, so
> having it setuid(2) its children won't work. And we're not going to
> have it run as root.
>
> You're attempting to enforce restrictions on your particular part of
> an otherwise completely open environment. You need to enforce
> restrictions from a secure environment, not from the environment
> you're trying to restrict. You should store sensitive and privileged
> data in your daemon and vend it to the agent after it has had the
> user jump through the necessary hoops.
>
>> I'll also say that I've found a way to do what I need, but it
>> directly
>> violates the 10 Commandments of Launchd Agents. I would be eternally
>> grateful if someone could suggest semi-rule-abiding way to secure a
>> LaunchAgent from being controlled without authorization.
>
> It would help if we knew why the GUI portion of your architecture is
> sacrosanct and must be secured, rather than being just a security
> interface. I'm reminded of many action movies where the hero must
> break through a door, so he smashes the numeric keypad controlling
> access to it, and somehow that opens the door. That's the kind of
> security architecture I'm seeing here.
>
> As an example, on Mac OS X, SecurityAgent runs as the user, and the
> user can kill it if he wishes. We have no problems with this. It
> just means that the user won't get the rights that he is requesting
> from the daemon. The daemon (which runs as root) is secured and
> can't be manipulated by the user.
> --
> Damien Sorresso
> BSD Engineering
> Apple Inc.
>
> _______________________________________________
> launchd-dev mailing list
> launchd-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
More information about the launchd-dev
mailing list