The Next 50 Years of Computer Security

wbglinks writes "An informative interview with Linux guru Alan Cox, with an emphasis on Linux and security. Alan will be the keynote speaker at EuroOSCON this October." From the article: "It is beginning to improve, but at the moment computer security is rather basic and mostly reactive. Systems fail absolutely rather than degrade. We are still in a world where an attack like the slammer worm combined with a PC BIOS eraser or disk locking tool could wipe out half the PCs exposed to the internet in a few hours. In a sense we are fortunate that most attackers want to control and use systems they attack rather than destroy them."

Comments

Whitehat Extremists

[mrwiggly]

A group of whitehat extremists may become tired of lusers that don't patch their systems, and decide that they don't deserve to use the internet.

They then launch their virus and destroy on all non-patching infidels.

What, it could happen.

HOWTO: Provably Secure Linux

[jd]

Here are some steps to produce a provably secure version of the Linux Operating System. And, yes, I mean provably secure. It is not the only method, it is not necessarily the best method, it is merely a workable* method.

*Workable means you can do this in finite time.

1) For each function, determine the preconditions, postconditions and the formal description of that function.

2) For each of the derived specifications, modify the specifications to be robust (ie: no invalid states are possible).

3) For each subunit of code that is referenced outside of the unit it is within, add mandatory access controls with a default of "deny", except for the mandatory access control system's check access function which should have a default access of "accept", and the bootstrap code which should have no access controls as the MAC system won't be running at the time.

4) MAC systems should be heirarchically defined in terms of linking a set of users to a set of rights those users can have. You then have as many mappings of this kind as you need. But because it is heirarchical, an application run by another application cannot assign rights it doesn't know about, nor can it assign rights to users it doesn't know about. An application accessed by paths with different rights must associate the rights to the path used to connect to it and define those as the superset of rights that path has when calling sub-components.

Oh, and MAC system interaction should follow the paradigm laid out under the Bezantine General's Problem - in other words, MAC systems should distrust each other enough that they can detect any MAC system that turns traitor.

5) MAC should apply to EVERYTHING. The network, memory pools, swap space, shared memory, everything. No resource should have permit access rights by default and no resource should allow unconstrained access granting. The resource should be able to control who can be granted access, so no one central system hands out access.

6) Remote connections (via any kind of connection outside of the defined physical machine) should be secure channels (host authentication, user authentication and data validation) and should have access rights limited to the subset of rights allowed to both remote connections, the remote host and the user who is performing the access. This is in addition to any constraints imposed by the application being connected to or any access rights it inherits (and is therefore limited to).

7) As part of 5, no "superuser" account should exist. Administrator accounts should only be permitted to administer, they should not be permitted to do anything else. There would be no "root" account, for example.

8) Once the specification has been hardened as above, it then needs to be re-implemented as code and then the code must be formally verified against the specification for correctness.

The first consequence of all of this is that paths would be very tightly constrained, making any kind of breaking out of the box about as close to impossible as you can get.

The second consequence is that because all access control is independent (but heirarchical), breaking the security of one module won't affect the security of anything else and won't grant any rights in excess of the subset defined by the intersection of the rights allowed by the path of connection, the broken module, the module then accessed and the broken module's rights within the module then accessed.

The third consequence is that, because the default is "deny", nothing can do anything not explitly authorized by the entire chain of connections.

Could this be done in Linux? Sure. If you add the kernel, X, KDE/QT, Gnome/Gtk, the GNU suite, etc, together, you're probably talking a billion lines of code. One million coders could probably do this entire eight-step lockdown over the whole of that codebase in a year, maybe two. There are more than a million coders o