site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Oct 27, 2008, at 8:22 PM, Brian Mastenbrook wrote: - Kevin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. This email sent to site_archiver@lists.apple.com