I'm surprised that no one mentioned Richardo Semler and his company Semco. All employees share in the profits and can contribute to decision making. I found his book, Maverick, very interesting.
This is the first I've heard of Systrace privilege elevation. However, it seems to address what has historically been one of the greatest causes of security problems in Unix.
If you look at the major vulnerabilities we've seen in Unix operating systems and software, they usually fall into one of three categories:
1) Bugs in the kernel.
2) Bugs in servers running with elevated privileges (often root).
3) Bugs in suid binaries (often suid root).
Privilege elevation could significantly reduce the problems caused by 2 and 3. It's by no means a silver bullet that's going to eliminate vulnerabilities, but it could produce a huge improvement.
Consider how difficult it is to write a secure suid root binary. Not only do you have to be extremely careful about your own code, you have to worry about possible bugs in any of the libraries you link with. Some people (e.g. D. J. Bernstein) seem to have the knack of producing secure code first time, but even a good programmer who is always thinking about security can make the occasional mistake.
With privilege elevation, such mistakes are no longer security disasters that grant complete root access to an attacker. The most an attacker can do is make the few privileged syscalls that are permitted by the systrace policy.
An excelent article. However, I don't believe your example of a social engineering attack on digital signatures is quite right.
The recipient's email client should check the authority signature of the sender's certificate against the known trusted Verisign certificate. In this case they wouldn't match. You can't make them match unless you know Verisign's private key.
The user will be warned that the identity of the sender could not be verified.
Cyrus is "sort of" free. The only restriction I can see is that you can't sell a product based on it without permission from CMU.
That might mean the license doesn't meet the OSI requirements, but I don't think it places any practical limits on use, modification and redistribution of the source.
Slashdot Mirror
I'm surprised that no one mentioned Richardo Semler and his company Semco. All employees share in the profits and can contribute to decision making. I found his book, Maverick, very interesting.
http://en.wikipedia.org/wiki/Ricardo_semler
This is the first I've heard of Systrace privilege elevation. However, it seems to address what has historically been one of the greatest causes of security problems in Unix.
If you look at the major vulnerabilities we've seen in Unix operating systems and software, they usually fall into one of three categories:
1) Bugs in the kernel.
2) Bugs in servers running with elevated privileges (often root).
3) Bugs in suid binaries (often suid root).
Privilege elevation could significantly reduce the problems caused by 2 and 3. It's by no means a silver bullet that's going to eliminate vulnerabilities, but it could produce a huge improvement.
Consider how difficult it is to write a secure suid root binary. Not only do you have to be extremely careful about your own code, you have to worry about possible bugs in any of the libraries you link with. Some people (e.g. D. J. Bernstein) seem to have the knack of producing secure code first time, but even a good programmer who is always thinking about security can make the occasional mistake.
With privilege elevation, such mistakes are no longer security disasters that grant complete root access to an attacker. The most an attacker can do is make the few privileged syscalls that are permitted by the systrace policy.
An excelent article. However, I don't believe your example of a social engineering attack on digital signatures is quite right.
The recipient's email client should check the authority signature of the sender's certificate against the known trusted Verisign certificate. In this case they wouldn't match. You can't make them match unless you know Verisign's private key.
The user will be warned that the identity of the sender could not be verified.
Cyrus is "sort of" free. The only restriction I can see is that you can't sell a product based on it without permission from CMU.
That might mean the license doesn't meet the OSI requirements, but I don't think it places any practical limits on use, modification and redistribution of the source.