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 27, 2008, at 4:11 PM, Brian Mastenbrook wrote: 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). 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.. As far as installation time grants, historically computer scientists have called those "installed images". VMS had this ability, for example. I'm not, in principle, against those, as long as there is some other user controllable way to get the same rights for my software that are being granted by my OS and OS vendor to some other software vendor installing code on my machine. If I paid for the atoms, I own them, and they will freaking well do what I tell them to do. Ironically, your straw man of privileged ports that you are putting forward in this thread in order to argue this point was an attempt at increasing the granularity of the UNIX security model. The idea was that you escalated privilege as a result of install time rights settings, obtained your privileged port, then dropped privilege. The premise behind this is that machines were so expensive that only trusted parties could afford to buy them, and therefore it was OK to let root on one machine vouchsafe an identity to root on another machine. I would argue that at this point, I could impersonate any machine at the wire traffic level using cheap hardware, and illicit network connectivity is so easy to obtain, that the use of privileged ports is largely useless, outside the computer equivalent of gated communities. This email sent to site_archiver@lists.apple.com