site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -- Terry _______________________________________________ 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 30, 2008, at 4:09 PM, Brian Mastenbrook wrote: On Oct 30, 2008, at 2:41 PM, Terry Lambert wrote: For capabilities based security models, all the capabilities that will ever be available to the OS are created when the OS is started. The problem with this approach is that it ignores the ability to enter and leave security associations, or otherwise find some way to escalate privilege beyond what you start with; on top of that, you have the problem of initialization. For a capabilities based OS like EROS, this last one is side stepped by creating the OS image instance with the instances preinitialized. But even so, the model is a non-starter. Any time you join or leave a security association, you must by definition engage in privilege escalation and deescalation, or talk to a gatekeeper with the capability you want to inherit, and which is therefore an attack surface. Even if you solved that, you still have the problem of peer recognition, and, up the chain of trust, that the person telling you to recognize a peer is a person authorized to do so, etc.. I am somewhat confused by what you are saying, as my prior exposure to the capabilities model is within the context of the actors model (for example, as implemented in E) where it definitely is possible to create a capability after the system is started. This is probably a bit of a tangent for darwin-dev; I'd be happy to discuss further over private mail. I really don't understand how you could possibly use that approach to add a new capability which, for example, allows an otherwise normal process to create privileged ports, if that granularity wasn't there in the first place. You'd of necessity need to have rights to define the capability, and you'd have to have rights to assign that capability, and you'd have to have an apriori knowledge of that as a discrete security boundary crossing event within the kernel itself, and an interposition enforcement checkpoint. All I see happening from this is moving the target surface, not eliminating it. If I can't attach a process "bob" which was setuid to enable it to get a privileged port, because what I want is a different privilege than that one, then I'll just attack the process by which privileges are created or the process by which privileges are assigned to process "bob", etc.. It's like yelling "Look! A pony!". The weak link is always going to be (1) the human who is asked to add privileges, or (2) the system's recognition that a given human is in fact the right human to permit to add privileges. I actually expect things would be worse than that; the only model that really works for interposition checkpoints is to allow multiple control agencies, and if anyone says anything other than "Yes" or "I don't care", then the answer is "No". Since the default answer is "No" for privileged ports, there's no way you could change the answer to "Yes" without allowing the policy to change the default. Otherwise I can just get a "Yes man" policy loaded at some point, and all your guards look the other way. The reason I brought up privileged ports is that this is one of the examples given in BetterAuthorizationSample, and despite the complicated attempt to provide only the ability to open up certain ports to the requesting process, the ability to do anything which requires admin privileges is provided to any process which is running as the requesting process's user. Sorry, I don't know from BetterAuthorizationSample. I just manage the credential code by which user space establishes identities to the kernel. I deal with 32 bit integers or interfaces to ask a privileged process in user space to trade things I don't know from Adam for nice 32 bit integers. 8-). Internally to the kernel, we *have* an actor model: all our kauth questions are of the form "Is actor X allowed to perform operation Y on taget Z?". If you want, I suggest you file a bug against BetterAuthorizationSample to get them to pick a different example. This email sent to site_archiver@lists.apple.com