Writing a system daemon in Cocoa and keeping things secure
Writing a system daemon in Cocoa and keeping things secure
- Subject: Writing a system daemon in Cocoa and keeping things secure
- From: Dan Bernstein <email@hidden>
- Date: Wed, 20 Apr 2005 18:14:40 +0300
Hi,
I'm writing a daemon that will run as a system startup item (at least
under Mac OS X v10.3.9 and earlier; I don't know what's the situation
in 10.4), and I'm using Cocoa. Everything the daemon does requires no
privileges at all (that is, it could run as user "nobody"), except for
the following:
1) Setting defaults for (any user, this host), that is,
CFPreferencesSetValue(key, value, daemonAppID, kCFPreferencesAnyUser,
kCFPreferencesCurrentHost).
2) Reading user defaults for specific users, that is,
CFPreferencesCopyValue(key, value, otherAppID,
kCFPreferencesCurrentUser, kCFPreferencesAnyHost) while the effective
user ID is that of the user whose request the daemon is servicing.
3) Creating and opening files under the permissions of specific users,
that is, fopen() while the effective user ID is that of the user whose
request the daemon is servicing.
My current idea for a solution is the following:
Have two executables, R and D. The startup item runs R, so R's real
user ID will be 0. R will create a socket pair and fork; the child
process will setuid() to nobody, then execve() executable D. The
parent will then listen on its side of the socket pair for requests
from D to do 1), 2) and 3), do some sanity checks on them, and perform
them as follows:
1) by actually calling CFPreferencesSetValue. This means that the
process running with real user ID 0 will have to be linked against
CoreFoundation. How bad is this?
2) and 3) by forking a child that will set(e)uid to the required user
and return the required information or fd (again via a socket pair
created prior to forking, authopen-style).
In addition to the problem in 1) above, I'm trying to decide on the
mechanism through which R can receive the requests from D. The way I
described it, there's a socket connection between them. It's easy to
use NSSocketPort and NSPortMessage to pass serialized objects (only
NSDictionaries, actually), but then R will have to link against
Foundation. How much more risky is that? What are my alternatives? I'm
afraid that if I code my own socket-based request protocol it might
end up being more vulnerable than using Foundation...
I'd appreciate your thoughts!
-- Dan
P.S. Sorry for the lengthy description. I'm hoping to avoid the "what
is it exactly that you're trying to do?" question.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden