Computing in the 21st Century requires participating in an arms race. The virus scanners, automatic updates, spyware scanners, etc. are defensive weapons.
The opposing side has an array of toolkits for writing worms and trojans, a growing network of financial and logistical support from all manner of sources, not to mention the ill directed energy of millions of adolescent males out to prove themselves.
We've become reliant on the patchwork of fixes that has evolved over time.. While encoraging some diversity is a wise and practical step to take to help bolster our defenses, I believe their is an underlying issue needs to be addressed.
Our goal should be secure computing. A secure computer is one which allows the user to trust that the computer operates as intended, and is free from any undesired outside influence. -- Note that this is contrary to definition used by certain OS and Media providers, their secure computer is one which is free from any undesired USER influence.
Windows, Mac OS, and Linux are all built on the same model. A trusted kernel supports a set of applications, using a series of access control lists (ACLs). There is a basic problem of granularity when using ACLs, it all comes down to granting permission per user account. If an application is run with a given account, it as full run to do anything that the specified user is allowed to do. There is no method of limiting a program to a specific set of actions, for example. This problem hasn't been solved in 30 years, nor is a fix for ACL based systems likely in the forseable future.
The alternative, well researched, but not on store shelves, is Capabilities based operating systems. In such a system, tokens are granted to a program to perform certain tasks, or capabilities. An application is thus limited to their available capablities, but no others. This means that services can be given tokens to access certain files, and perform certain actions on them, but no others. Even if an aversary subverts the code running a service, the capabilities limit the scope of action that can be taken by the adversary. The capablities model, if properly implemented (and the devil is always in the details) can be mathematically proven to be secure. (Which can't be done with ACLs)
If we can find and bring to market an open source, capabilities based OS, we gain a very large defensive weapon, though tere will still be other attack vectors. I had thought that capablities were coming soon via GNU Hurd, but a closer inspection of the online documentation seems to indicate they are going with user IDs ... oh well.
Well... the solution is out there... now we just have to find it, time is running out.
Or perhaps I'm just paranoid?
--Mike--
Subscribe to:
Post Comments (Atom)
1 comment:
Hi Mike -
I haven't read your 'Capabilities' post yet. But I was surprised to see you say that one cannot limit a program to a specific set of capabilities, because that program runs with the user's privilege set.
Actually not true. We quite often create services, then create a specific user just for the running of that service. We then severely limit the number of files and other services this service user has access to. Now say we take this just a little further at development time and provide a list of all the files/processes/devices our new program will need access to. And we bundle a script for creating this exact user and privilege set during installation of our program.
Isn't this pretty much an implementation of the 'Capabilities' model (at least as it is explained in this article)? And we did it in the current user-and-ACL model. NO OS re-architecting needed - just an addition to install routines!
I promise I'll be back to read more and comment .. but sleep beckons!
Post a Comment