[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