Re: setuid for priv sockets?
Re: setuid for priv sockets?
- Subject: Re: setuid for priv sockets?
- From: Kevin Van Vechten <email@hidden>
- Date: Mon, 27 Oct 2008 21:39:51 -0700
On Oct 27, 2008, at 8:22 PM, Brian Mastenbrook wrote:
On Oct 27, 2008, at 8:15 PM, Damien Sorresso wrote:
If you use a system-level launchd daemon, however, your execution
environment is implicitly trusted, since /sbin/launchd is
implicitly trusted. A user cannot affect the environment of your
daemon *at all* because the parent process is launchd, not the
client process.
... except by communicating with the daemon. How many local root
exploits have been due to daemons running on the localhost which
accept but do not properly validate input from clients? How many
remote exploits? We are still operating in the mindset of launching
a piece of code with root privileges that receives tainted data from
a user process, and any such program is suspect for the same set of
reasons that make writing setuid helper tools difficult - and
possibly moreso, because now I have to deal with socket interactions
to read and parse the request rather than just reading and
validating some pre-tokenized arguments in argv. Sample code or no,
there's still significant opportunity for error here.
I strongly disagree. A setuid-root executable has a much larger
attack surface than a launchd helper.
All framework/library interfaces by the setuid-root executable can
potentially receive untrusted data via the user environment, mach
bootstrap registrations, inherited file descriptors, etc. A
privileged launchd helper has none of these attack surfaces, only the
communication protocol. It is far more tractable to audit the parsing
of the communication protocol than all framework/library interfaces
used by the executable.
- Kevin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden