site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Oct 27, 2008, at 1:19 PM, Damien Sorresso wrote: On Oct 27, 2008, at 5:49 PM, Duane Murphy wrote: --- At Mon, 27 Oct 2008 17:49:35 -0400, Stephen Hoffman wrote: -- Brian Mastenbrook brian@mastenbrook.net http://brian.mastenbrook.net/ _______________________________________________ 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... We're strongly (and I do mean strongly) trying to move people off of setuid binaries. If it's a command line application, you can just require that the user run it as root or with sudo if performing actions that require access to this privileged port. In the past BSDLLCTest <http://developer.apple.com/samplecode/BSDLLCTest/ index.html> and MoreAuthSample have been the reference for how to o similar functions. The solution described can use setuid root tools (set afterward). Might be worth a look. I'm sorry, but using AuthServices to replace setuid binaries is simply broken from a security perspective. A setuid binary, *if correctly implemented*, does a very specific set of things while it has permissions and then permanently drops those rights. Using AuthServices, any old application can come along and request privileges. Sure, I have to approve that request by entering my name and password, but there's absolutely nothing preventing malware that has access to my user account from smuggling along and gaining root permissions at the same time, and there's nothing to tell me that this is happening. If SuperFancyEthernetCaptureProgram is requesting my user name and password, who am I to argue with it? Nevermind that TotallyEvilMaware.dylib has injected itself into the process and will be rooting my system at the same time. By contrast, the execution environment of setuid binaries is locked down so that other user programs can't influence it. Even sudo itself is setuid and is this isolated from the effects of PATH, DYLD_INSERT_LIBRARIES, and other magic. I do agree that implementing setuid binaries is tricky, and the ordinary (or even extraordinary) developer can't be trusted to do it correctly. The alternative is not to do something worse simply because it's easier. I wish Apple would throw some of its copious billions at actually improving the situation. What's needed is a very fine grained set of capabilities, along with the ability to selectively grant those capabilities to an application at either installation or execution time (with corresponding limitations on the ability to influence the execution environment ala the existing restrictions for setuid binaries). Instead we are marching headlong down a path of desensitizing the users to constant authentication dialogs. This way lies Windows. I've already filed this with Apple and they've decided it's not a security issue. For those with Radar access, see rdar://6074066 . This email sent to site_archiver@lists.apple.com