Comments on: Apple Sandboxes Part 1 http://www.usefulsecurity.com/2007/11/apple-sandboxes-part-1/ Solving real security problems that matter to real users Fri, 25 Jul 2008 01:57:43 +0000 http://wordpress.org/?v=2.5 By: Mental Rootkit - OS X Malware http://www.usefulsecurity.com/2007/11/apple-sandboxes-part-1/#comment-33 Mental Rootkit - OS X Malware Thu, 26 Jun 2008 20:54:29 +0000 http://www.usefulsecurity.com/?p=21#comment-33 [...] sandbox policies he is referring to are the new security mechanisms in 10.5 based on the TrustedBSD project, a sister project to SELinux. Dino makes several other good [...] […] sandbox policies he is referring to are the new security mechanisms in 10.5 based on the TrustedBSD project, a sister project to SELinux. Dino makes several other good […]

]]> By: c-had http://www.usefulsecurity.com/2007/11/apple-sandboxes-part-1/#comment-29 c-had Fri, 07 Dec 2007 22:09:24 +0000 http://www.usefulsecurity.com/?p=21#comment-29 I don't think I quite understand your comment. Most user applications (including at least iTunes, QuickTime, and iLife) run as non-root users. If they're using Mach system calls, then they have the appropriate mach port rights to do so (note that Mach does not utilize the UNIX UID concept, but rather utilizes the Mach port capability system. More info here - http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Concepts/chapter_3_section_9.html). More importantly, the new sandbox mechanism is an orthogonal mechanism to the current UNIX DAC model and the Mach port model, so sandbox policies can be applied (in a flexible way) regardless of whether the process is running as root. If you look at my examples in the second part of this post, those can be run as a regular user or as root and receive the same confinement. With sandboxes, root doesn't actually matter. I don’t think I quite understand your comment. Most user applications (including at least iTunes, QuickTime, and iLife) run as non-root users. If they’re using Mach system calls, then they have the appropriate mach port rights to do so (note that Mach does not utilize the UNIX UID concept, but rather utilizes the Mach port capability system. More info here - http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Concepts/chapter_3_section_9.html).

More importantly, the new sandbox mechanism is an orthogonal mechanism to the current UNIX DAC model and the Mach port model, so sandbox policies can be applied (in a flexible way) regardless of whether the process is running as root. If you look at my examples in the second part of this post, those can be run as a regular user or as root and receive the same confinement. With sandboxes, root doesn’t actually matter.

]]> By: Joseph http://www.usefulsecurity.com/2007/11/apple-sandboxes-part-1/#comment-28 Joseph Fri, 07 Dec 2007 19:43:43 +0000 http://www.usefulsecurity.com/?p=21#comment-28 The reason apple has selected for an opt-in style of sandboxing is because much of the MACH related system calls expect to have root level access and since much of the OS and supported apps (include iTunes, QuickTime, iLife, ARD, etc) use the mac system and these "private api"s (which also expect root access) it would be impossible for Apple to roll this interface out as a required interface for at least 1 or 2 more OS releases from now. The reason apple has selected for an opt-in style of sandboxing is because much of the MACH related system calls expect to have root level access and since much of the OS and supported apps (include iTunes, QuickTime, iLife, ARD, etc) use the mac system and these “private api”s (which also expect root access) it would be impossible for Apple to roll this interface out as a required interface for at least 1 or 2 more OS releases from now.

]]>