The Next 50 Years of Computer Security 128
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."
The next step in security: benevolent parasites? (Score:2, Interesting)
This reminds me of a conversation I had with my business partner regarding computer security:
Imagine a hacker group that offered to protect your system against other hackers. In exchange for x% of your computer cycles, x% of your HDD space, a predetermined number of pop-up ads, etc., the group would guard your computer against others attempting to compromise it for its own use. The group would connect to your system from the internet, install their rootkits, and regularly scour your system looking for intruders, which they would zealously remove. Because they would be paid in computer resources (disk space, cycles, etc.), it would be in their best interests to keep your system as free from other parasites as possible. In much the same way as the bacteria growing in our mouths prevent them from being colonized by other, much more harmful bacteria, the group would defend its box against intruders.
Just an idea...thought I'd throw it out there and see what the Slashdot crowd thought of it (be gentle ^_^).
I only scanned the article (Score:2, Interesting)
In 50 yrs I'm going to assume that IPv6 (or v7,8,9) has taken over the world. Wouldn't that do a lot for basic internet security? No more scanning and rooting boxen.
As for stuff like BIOS erasers and disk locking tools, e-mail will no longer be a useful attack vector due to filtering. The again, nothing can defeat stupidity.
Disclaimer: IANAL
The virus that 'helps' you (Score:2, Interesting)
Of course, we will have to worry about the attackers that inadvertently destroy systems while trying to control them.
I'm afraid I can't let you do that, Dave...this virus is too important for me to let you jeopardize it.
Whitehat Extremists (Score:5, Interesting)
They then launch their virus and destroy on all non-patching infidels.
What, it could happen.
HOWTO: Provably Secure Linux (Score:4, Interesting)
*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
Not much of a difference for most end users. (Score:2, Interesting)
Right, but I really don't see too much of a difference between a computer under the control of a hacker or hacker group and a destroyed computer, because either one makes a computer unusable for your average end user.
It's an exhaustive effort to get rid of hackers once they're in since they install all kinds of nasty software, so for people who don't know much except their computer is doing something weird and they're having their identity stolen, etc etc, they just throw it out and get a new Dell. I am not saying this applies to every user that doesn't know much about computers but I have seen it over and over again with friends, family, family friends, you name it.
So bottom line is, for a lot of people who have no expertise with computers, destruction of a computer due to hacking OR having the computer infected and controlled by hacker groups means you get rid of it, in which case there's not much difference between the two, since it leads to the same result.