Since HP is no longer making computers, who cares which software division this moves in to? They won't have anything to bundle it with, and thus no way to trick new users into existence.
We've now had proof positive that no centralized trust system is workable against a sustained attack. Can we start to get some distributed trust systems in place, instead? The idea of a single proof of identity has failed. It's time to move on to a system that allows multiple checks and balances.
Monocultures are great for creating massive failures, which is why nature wipes them out over time.
Google was IS a really cool technology, with some very bad design decisions layered on top of it.
It could have been the web as TBL envisioned it, writable by all, and Xanadu as Ted Nelson envisioned it, hyperlinked with automatic transclusion.
Mistake 1 was insisting on having each portion of a document appear as part of a thread, instead of seamlessly merged like a real document.
Mistake 2 was making ownership of each portion of the document a primary thing, instead of something best discovered later, as wikis do it.
Mistake 3 was making it look exactly like threaded email, and then letting it get sucked into that pigeonhole, and not trying to pull it back away.
Mistake 4 was in not supporting experimentation into different uses of the underlying protocol at launch time.
Mistake 5 was giving up too soon after it didn't catch on as the threaded mail everyone initially thought it was, and turned out to be a very poor version of.
Wave as a technology is awesome... but it hasn't been tried yet in a usable form. Think sub-etha-edit meets wikis with rich formatting.
I'd be happy with just introducing a random delay of 1-10 seconds into every transaction.
You didn't go far enough, I think that transactions should be batch processed, with a maximum rate of one batch every 20 seconds. This would help restore the fair market ethos we all value in western society.
There should be phases
Submit orders to the market system
Receive confirmation of intent from the trading system when enough volume is present to build a transaction
5 second delay for any cancels
if the volume is still there... execution according to a publicly known market making algorithm
else go back to submit phase
finally - notification to everyone of ALL results, who bought what from whom, with a copy to log file, SEC, and a new public domain Stock Market archive
HFT isn't high frequency trading, it's High Financial Theft, in my humble opinion.
Trades should be at best as fast as the humans on the floor... any faster and we're all subject to flash crashes, and subversion of the Fair Market.
Virtualization is a stopgap measure, it helps work around the inadequacies of current operating systems by introducing a new layer of granularity and security.
The purpose of an operating system is to share hardware in a secure and efficient manner. Unfortunately the security of systems is lacking, so you can never be sure of the side effects of installing or running an given application. Using a VM to allow damage to be rolled back is a hack to make the risks acceptable.
If the operating systems did their jobs properly, security wouldn't be a big issue for most use. The model of default-permit is the root problem. Users have no way to restrict the side effects of a program, thus they are forced to trust code. You should never be forced to trust code, it's bad enough to have to trust the OS kernel, let alone millions of lines of code written by third parties trying to get things working long enough to meet unrealistic ship dates.
Instead of secure by default, you have run by default in all 3 major environments... Linux, Windows, OSx
Time is running out for this insane approach to doing things... the various band-aids are now in play are rapidly losing their efficacy, and none address the basic issue: code can no longer be trusted.
Fortunately. a few brave souls have ventured into this area with projects oriented at fixing the situation properly.
In the Linux area, seccomp-nurse is a sandboxing framework based on SECCOMP. It is designed to run applications in a kind of jail (enforced by the kernel). It does not use ptrace() at all.
In the Windows area, Polaris (Principal Of Least Authority for Real Internet Security) is a package for Windows XP that demonstrates that we can do better at dealing with viruses than has been done so far. Polaris allows users to configure most applications so that they launch with only the rights they need to do the job the user wants done. This simple step, enforcing the Principle of Least Authority (POLA), gives so much protection from viruses that there is no need to pop up security dialog boxes or ask users to accept digital certificates. Further, there is little danger in launching email attachments, using macros in documents, or allowing scripting while browsing the web. Polaris demonstrates that we can build systems that are more secure, more functional, and easier to use.
Manage code solves the wrong problem... here's a story that I hope explains why.
Imagine this bizarre scenario:
You get to the check out counter, with the bottle of coke you wish to purchase.
You put yourself into suspension so that the clerk can...
Find your wallet, get money out, put all but $2.15 of it back in
Prepare your reciept
Wake you back up
Hand you the receipt
Imagine that you grew up in a world where this was normal behavior. Sure there were some dishonest clerks, but those were few and far between. Enough people eventually complained that they started a list of bad clerks, so you could check to see if the clerk was on the list before you decided to make a purchase.
Problem solved, right? WRONG...
What if someone tricks the clerk while you're in suspension? What if they make a mistake? What if they have an accident? What if they just decided to turn evil?
This bizzarro world is almost precisely how we do things with computers. Instead of ourselves, it's our computer account, and instead of the clerk, it's a program we're about to run.
Now... look at how we do things in the real world...
When you buy a coke at the 7-11, you hand over some amount of payment, and get change. It's a limited amount to risk.
The worst you can do is to not get the right change back. The side effects are limited BEFORE you decide to make the payment.
It's immediately obvious if you have completed the transaction.
There is no possibility of bizarre side effects, like having your living room painted a Slurpee Blue because of 7/11 decided to offer a new feature.
Why not have the operating system do it's job and enforce a scenario like this...
You have a program you'd like to run
You make a list of the files and other resources it should have, and the types of access
You hand that list to the program, which uses the operating system to access them, strictly limited to the items on the list.
This prevents unwanted side effects, and removes the bizarre (to me) need to trust programs at all.
I hope that story helps convince you that you should never have to trust applications, only the operating system kernel.
New hardware has bought us the ability to use managed code for most (not all) software. Isn't this much better than expecting every programmer to perfectly manage his memory every time?
So all that.net stuff is about garbage collection? Why not just have a standard way of letting the operating system take care of it in the background?
All this "managed code" seems to have resulted in is machines with a stack of complete ".net framework" versions numbered 1.0, 1.1, 2, 3, 3.5, and 4.
It would be nice to get rid of this multi-gigabye pile of bytecode, if it's all just to save a few K of ram here and there.
Imagine if you could only decide if you trusted a soldier or not, a binary decision, for each and every soldier in the military, at their time of enlistment.
If you trusted him, he had full access to every weapon and resource at our countries command, until he decided to leave.
If not, he wouldn't have access to anything.
Would it be possible to have a classification system in such a regime, when one spy could give away everything to the highest bidder? Would it be possible to have an effective command and control system, when rank means nothing because there are no privileges that go with it? Would it be possible to even have a country, if one loose cannon could launch Armageddon?
No, of course not... security decisions have to be much more fine grained than that... you don't trust any soldier absolutely, it would be insane to do so.
Even the tightest background checks in the world wouldn't help, because it only takes one mistake to lose everything.
Yet we have no problem with giving that soldier (or any user, for that matter) a computer and that same choice... either trust the program he's about to run, or don't accomplish anything.
Until we remove this false choice, we can never have secure computing.
Here we have what could be self fulfilling prophecy...If all programmers think it impossible to implement secure systems, thus nobody tries.
Fortunately. a few brave souls have ventured into this area..
In the Linux area, seccomp-nurse is a sandboxing framework based on SECCOMP. It is designed to run applications in a kind of jail (enforced by the kernel). It does not use ptrace() at all.
In the Windows area, Polaris (Principal Of Least Authority for Real Internet Security) is a package for Windows XP that demonstrates that we can do better at dealing with viruses than has been done so far. Polaris allows users to configure most applications so that they launch with only the rights they need to do the job the user wants done. This simple step, enforcing the Principle of Least Authority (POLA), gives so much protection from viruses that there is no need to pop up security dialog boxes or ask users to accept digital certificates. Further, there is little danger in launching email attachments, using macros in documents, or allowing scripting while browsing the web. Polaris demonstrates that we can build systems that are more secure, more functional, and easier to use.
These systems are still in the early stages, but show the starting points for bringing Capability Based Security to the masses.
I'm not a good enough programmer to do these projects justice, but I think bringing them even a tiny bit of attention might help.
Cells get infected when rogue genetic material gets past their defenses. A single infected cell can eventually lead to massive side effects.
The same thing is true when rogue programs get past firewalls, antivirus, etc.. A single computer can result in network wide side effects. Thus far the analogy holds, and is a helpful tool.
Unlike the situation with our cells, we can redesign the way our operating systems work, so that they don't trust programs. This shift would then allow the user (or administrator) to decide what resources would be made available to any given instance of a program. This makes it practical to limit the side effects of a rogue program, or even one which just has a bug.
Computer security can be FIXED, and we should start working on it now, so that the lack of a solution isn't used as an excuse for more intrusion, and destruction of liberty.
I disagree. I trust the users to make intelligent use of the computers they have accounts on. On the other hand, I don't trust programs, nobody should.
When a program is run, the only limits on its actions are set by the security settings of the system with respect to the account that launched it. These permissions are usually assigned by an administrator, and out of the users control. Default permissive environments are the root cause of our current lack of security. A program gone rogue can do as much damage as a malicious user on their worst day, in the blink of the eye, without even showing any symptoms of trouble.
The user, and the scanning tools are scapegoats here. Sure, some users make mistakes, and do stupid things, but it is impossible to determine if a non-trivial program can be trusted. Blaming users for failing at an impossible task is foolish, at best. Tools are just tools, to try to help increase transparency in terms of known vulnerabilities.
The solution is a default deny environment for programs, in which the user gets to decide which, if any, of their resources are given to a particular instance of a program. If it's not in the list, the program doesn't get it, and doesn't even know about it. This lets the user decide what they want to work with, and strongly limits the side effects of a program gone rogue.
It's not a very hard thing to conceptualize, nor to plan out. The hard thing is the massive amount of investment in our current code base, and mind-set, which need a subtle tweak, and some clever hacks.
There are positive signs, but I fear it will be another 10-20 years or more before a system which is default deny becomes the more popular choice. That's a lot of time and effort thrown away, that could be better utilized.
Copyright is a social contract, in which the Government grants a monopoly for a limited amount of time over the publishing of a work for profit, in exchange for a social good, the eventual transfer of that work into the public domain.
Disney, et al. have perverted this social contract into a pseudo-property right, and have the full force of the threat of PMITA prison to try to keep people from sharing things, against evidence that people who share actually buy MORE copyrighted materials from publishers.
This whole thing is a mess, but I think it's important to know the original reasons things were set up so we can do it right when we set it up all over again after the collapse of the US in the next few years.
Copyright infringement requires that you profit from it. While it appears that Aaron knew he was taking a risk, I strongly doubt that profit was his motive.
I found myself in this same position a number of years ago, I've settled on using ubuntu linux, iproute2, and iptables, it's not easy to get working right, especially when you have DSL instead of a nice normal IP based connection (I will forever hate PPPoE)
The mental gymnastics of tracking ip connections across two separate routing tables in the same box will give you a few headaches, especially when a packet which comes in through the DSL heads back out the WiFi interface for no apparent reason... it's definitely not easy to get working. PPPoE imposed by our new DSL vendor added a new level of hell once we moved.
If you can find a piece of hardware which works well for less than a weeks worth of your time and effort, that has good reviews, and supports PPPoE, buy it, and don't look back.
Information asymmetry makes even the fastest analysis on the planet irrelevant as the data input is garbage. It is this lack of transparency which resulted in the housing bubble, etc.
The "too big to fail" banks regularly hide data from customers, regulators, and other branches of their own organization.
This is interesting because of the speedup of FPGAs, but don't be fooled by a second that it addresses an actual business need, other than PR.
If the market were fair and open, this kind of thing wouldn't even be possible, because everyone would already know what code runs in the servers. It's the opacity that allows information asymmetry which gets us into trouble every time by enabling market manipulation.
All trades should be batch processed, every 5 minutes, and all this high-frequency scamming should be pulled out by the root. An open, honest, well regulated market is in the best interest of all investors.
No, not on Windows. Windows has a per-process token and the privileges of that token does not have to match any account at all. The token consists of a list of SIDs which can represent groups (which in turn appear in ACLs) *or* the SIDs represent privileges, e.g. setting time zone, restarting the system, log on as batch service etc. You do *not* need to set up an account with the desired privileges. You just need to prune the token itself.
On Linux there are also "Linux Capabilities" which are a few number of bits which represent capabilities that are not linked to any specific resource. These can even be considered "mini tokens" as they appear in the process descriptor as well. They are poorly implemented, though, and woefully underused.
What you cannot do with Windows process token is represent more advanced (parameterized) privileges such as CPU quota.
These generic privileges are defined system wide, whereas capabilities are specific to a single file, device, etc. If you have access to files a,b, and c, it's not possible to give another process access to only a and c with privileges, but it's trivial with capabilities.
It's enough, in theory, to do this. However, in practice it is not.
If you have a web server you want to run, to serve up files from/usr/mike/www and to log files to/usr/mike/logs/www, you'd have to build a new account for the daemon, and set permissions on all of the files system wide to make sure the web server task couldn't access them.
Once that's done... the web server is secure... however, you've had to modify a lot of security settings for this one-off job, and those persist unless you clean them up.
Those settings may not be possible from a user account, which means a lot of administrator involvement, and reduced functionality for the users.
With capabilities, you give the web server program a read capability to/usr/mike/www, and a write token to/usr/mike/logs/www, and a token to listen and communicate on port 80, and you're done. If you decide to stop serving web pages, there's no cleanup.
If the user has permissions to do all of those things, the can delegate them to a task... and revoke them at will, without having to bother the administrator.
Interesting. So one would not be able to implement capsec through a process token? Because it still sounds a lot like Windows Privileges/Linux Capabilities except that those privileges/capabilities are binary (has the privilege or has not) and you gave examples of privileges which would need to be parameterized (cpu load, target IP addresses, target urls).
If you wanted to hand off access to a new process, which had ALL of the permissions of another process, this would work. However, if there were ANY differences at all, you'd have to create a new account, then set up permissions on all of the system resources to match your new desired access for the new account, and then pass along information via inter-process pipes, shared files, etc. Otherwise you run right back into the need to trust programs, and bad security.
Because capability based systems only let you get at resources in the list for given process, it's very transparent (to the user, programmer, administrator) what's going on.
Here's an example to make the point: If you want to write a program that takes a file access capability as input and gives a corresponding read-only capability to the same file, it's easy to do, and as long as the code isn't flawed, the protection is iron clad. If that filter program has a flaw, the very worst possible case is that the original capabilities leak through.
Another way to think about it is that capabilities are like a parameter list, and the only possible side effects to a given process are limited (by the OS) to those parameters.
Capability Based Security will be making it to your machines, it's just a question of time.
Enjoy your delusions.
But do tell, how does a relational database system work with capabilities? You'd need a capability to access the database, and each table, and each row? How does that work?
You'll need better than a toy system, son.
Perhaps I am deluded... I hope not. You've killed some of the misconceptions I had about it, and for that I thank you. I believe the idea still has great merit, though... because we really shouldn't be forced to trust software beyond the OS itself. All of the examples I've given in my other replies point out the need to remove the default permit design decision that's baked into everything. We must fix this, it's a question of becoming aware of the problem, then becoming aware of possible solutions, then actually solving the problems, for good.
Most of the capabilities concepts I'm familiar with our file oriented, but it should be possible to do the same thing with records, fields, etc... in a database. There's nothing stopping someone from adding them as a layer on top of a database, just like the layer of permissions that some databases support.
Another approach is to hand a database capability to a filter program, and give the filtered capability to the untrusted program, to prevent misbehavior from successfully breaking security.
Slashdot Mirror
So what happens when the algorithms start demanding a billion dollar bonus before they'll turn up to work?
At that point, QE15 will be underway, and $1000,000,000 US will pay for a few minutes worth of power for the computer. Gold will be $10^12/ounce.
Since HP is no longer making computers, who cares which software division this moves in to?
They won't have anything to bundle it with, and thus no way to trick new users into existence.
We've now had proof positive that no centralized trust system is workable against a sustained attack. Can we start to get some distributed trust systems in place, instead? The idea of a single proof of identity has failed. It's time to move on to a system that allows multiple checks and balances.
Monocultures are great for creating massive failures, which is why nature wipes them out over time.
Google was IS a really cool technology, with some very bad design decisions layered on top of it.
It could have been the web as TBL envisioned it, writable by all, and Xanadu as Ted Nelson envisioned it, hyperlinked with automatic transclusion.
Mistake 1 was insisting on having each portion of a document appear as part of a thread, instead of seamlessly merged like a real document.
Mistake 2 was making ownership of each portion of the document a primary thing, instead of something best discovered later, as wikis do it.
Mistake 3 was making it look exactly like threaded email, and then letting it get sucked into that pigeonhole, and not trying to pull it back away.
Mistake 4 was in not supporting experimentation into different uses of the underlying protocol at launch time.
Mistake 5 was giving up too soon after it didn't catch on as the threaded mail everyone initially thought it was, and turned out to be a very poor version of.
Wave as a technology is awesome... but it hasn't been tried yet in a usable form. Think sub-etha-edit meets wikis with rich formatting.
I'd be happy with just introducing a random delay of 1-10 seconds into every transaction.
You didn't go far enough, I think that transactions should be batch processed, with a maximum rate of one batch every 20 seconds. This would help restore the fair market ethos we all value in western society.
There should be phases
HFT isn't high frequency trading, it's High Financial Theft, in my humble opinion.
Trades should be at best as fast as the humans on the floor... any faster and we're all subject to flash crashes, and subversion of the Fair Market.
Virtualization is a stopgap measure, it helps work around the inadequacies of current operating systems by introducing a new layer of granularity and security.
The purpose of an operating system is to share hardware in a secure and efficient manner. Unfortunately the security of systems is lacking, so you can never be sure of the side effects of installing or running an given application. Using a VM to allow damage to be rolled back is a hack to make the risks acceptable.
If the operating systems did their jobs properly, security wouldn't be a big issue for most use. The model of default-permit is the root problem. Users have no way to restrict the side effects of a program, thus they are forced to trust code. You should never be forced to trust code, it's bad enough to have to trust the OS kernel, let alone millions of lines of code written by third parties trying to get things working long enough to meet unrealistic ship dates.
Instead of secure by default, you have run by default in all 3 major environments... Linux, Windows, OSx
Time is running out for this insane approach to doing things... the various band-aids are now in play are rapidly losing their efficacy, and none address the basic issue: code can no longer be trusted.
Fortunately. a few brave souls have ventured into this area with projects oriented at fixing the situation properly.
In the Linux area, seccomp-nurse is a sandboxing framework based on SECCOMP. It is designed to run applications in a kind of jail (enforced by the kernel). It does not use ptrace() at all.
In the Windows area, Polaris (Principal Of Least Authority for Real Internet Security) is a package for Windows XP that demonstrates that we can do better at dealing with viruses than has been done so far. Polaris allows users to configure most applications so that they launch with only the rights they need to do the job the user wants done. This simple step, enforcing the Principle of Least Authority (POLA), gives so much protection from viruses that there is no need to pop up security dialog boxes or ask users to accept digital certificates. Further, there is little danger in launching email attachments, using macros in documents, or allowing scripting while browsing the web. Polaris demonstrates that we can build systems that are more secure, more functional, and easier to use.
Manage code solves the wrong problem... here's a story that I hope explains why.
Imagine this bizarre scenario:
You get to the check out counter, with the bottle of coke you wish to purchase.
You put yourself into suspension so that the clerk can...
Find your wallet, get money out, put all but $2.15 of it back in
Prepare your reciept
Wake you back up
Hand you the receipt
Imagine that you grew up in a world where this was normal behavior. Sure there were some dishonest clerks, but those were few and far between. Enough people eventually complained that they started a list of bad clerks, so you could check to see if the clerk was on the list before you decided to make a purchase.
Problem solved, right? WRONG...
What if someone tricks the clerk while you're in suspension?
What if they make a mistake?
What if they have an accident?
What if they just decided to turn evil?
This bizzarro world is almost precisely how we do things with computers. Instead of ourselves, it's our computer account, and instead of the clerk, it's a program we're about to run.
Now... look at how we do things in the real world...
When you buy a coke at the 7-11, you hand over some amount of payment, and get change. It's a limited amount to risk.
The worst you can do is to not get the right change back. The side effects are limited BEFORE you decide to make the payment.
It's immediately obvious if you have completed the transaction.
There is no possibility of bizarre side effects, like having your living room painted a Slurpee Blue because of 7/11 decided to offer a new feature.
Why not have the operating system do it's job and enforce a scenario like this...
You have a program you'd like to run
You make a list of the files and other resources it should have, and the types of access
You hand that list to the program, which uses the operating system to access them, strictly limited to the items on the list.
This prevents unwanted side effects, and removes the bizarre (to me) need to trust programs at all.
I hope that story helps convince you that you should never have to trust applications, only the operating system kernel.
Ok,
So it's half-assed garbage collection, 5 or so different metric tons of libraries (all incompatible), and an IDE?
What does the IDE have to do with the language?
New hardware has bought us the ability to use managed code for most (not all) software. Isn't this much better than expecting every programmer to perfectly manage his memory every time?
So all that .net stuff is about garbage collection? Why not just have a standard way of letting the operating system take care of it in the background?
All this "managed code" seems to have resulted in is machines with a stack of complete ".net framework" versions numbered 1.0, 1.1, 2, 3, 3.5, and 4.
It would be nice to get rid of this multi-gigabye pile of bytecode, if it's all just to save a few K of ram here and there.
Imagine if you could only decide if you trusted a soldier or not, a binary decision, for each and every soldier in the military, at their time of enlistment.
If you trusted him, he had full access to every weapon and resource at our countries command, until he decided to leave.
If not, he wouldn't have access to anything.
Would it be possible to have a classification system in such a regime, when one spy could give away everything to the highest bidder?
Would it be possible to have an effective command and control system, when rank means nothing because there are no privileges that go with it?
Would it be possible to even have a country, if one loose cannon could launch Armageddon?
No, of course not... security decisions have to be much more fine grained than that... you don't trust any soldier absolutely, it would be insane to do so.
Even the tightest background checks in the world wouldn't help, because it only takes one mistake to lose everything.
Yet we have no problem with giving that soldier (or any user, for that matter) a computer and that same choice... either trust the program he's about to run, or don't accomplish anything.
Until we remove this false choice, we can never have secure computing.
As long as the user has no way to quickly and safely run something in a sandbox, this will continue happening.
IMHO, Once you give them the ability to run programs in a default deny environment, users can manage things fairly well.
See also: http://www.ranum.com/security/computer_security/editorials/dumb/
Here we have what could be self fulfilling prophecy...If all programmers think it impossible to implement secure systems, thus nobody tries.
Fortunately. a few brave souls have ventured into this area..
In the Linux area, seccomp-nurse is a sandboxing framework based on SECCOMP. It is designed to run applications in a kind of jail (enforced by the kernel). It does not use ptrace() at all.
In the Windows area, Polaris (Principal Of Least Authority for Real Internet Security) is a package for Windows XP that demonstrates that we can do better at dealing with viruses than has been done so far. Polaris allows users to configure most applications so that they launch with only the rights they need to do the job the user wants done. This simple step, enforcing the Principle of Least Authority (POLA), gives so much protection from viruses that there is no need to pop up security dialog boxes or ask users to accept digital certificates. Further, there is little danger in launching email attachments, using macros in documents, or allowing scripting while browsing the web. Polaris demonstrates that we can build systems that are more secure, more functional, and easier to use.
These systems are still in the early stages, but show the starting points for bringing Capability Based Security to the masses.
I'm not a good enough programmer to do these projects justice, but I think bringing them even a tiny bit of attention might help.
Instead of going through all this wasted effort, how about we just fix computer security and be done with it?
Default permissive environments are the problem.
Capability based security is the answer.
No incursion on our few remaining liberties, no more virus scanners, worms, etc... no more DRM... what's not to like?
Cells get infected when rogue genetic material gets past their defenses. A single infected cell can eventually lead to massive side effects.
The same thing is true when rogue programs get past firewalls, antivirus, etc.. A single computer can result in network wide side effects. Thus far the analogy holds, and is a helpful tool.
Unlike the situation with our cells, we can redesign the way our operating systems work, so that they don't trust programs. This shift would then allow the user (or administrator) to decide what resources would be made available to any given instance of a program. This makes it practical to limit the side effects of a rogue program, or even one which just has a bug.
Computer security can be FIXED, and we should start working on it now, so that the lack of a solution isn't used as an excuse for more intrusion, and destruction of liberty.
I disagree. I trust the users to make intelligent use of the computers they have accounts on. On the other hand, I don't trust programs, nobody should.
When a program is run, the only limits on its actions are set by the security settings of the system with respect to the account that launched it. These permissions are usually assigned by an administrator, and out of the users control. Default permissive environments are the root cause of our current lack of security. A program gone rogue can do as much damage as a malicious user on their worst day, in the blink of the eye, without even showing any symptoms of trouble.
The user, and the scanning tools are scapegoats here. Sure, some users make mistakes, and do stupid things, but it is impossible to determine if a non-trivial program can be trusted. Blaming users for failing at an impossible task is foolish, at best. Tools are just tools, to try to help increase transparency in terms of known vulnerabilities.
The solution is a default deny environment for programs, in which the user gets to decide which, if any, of their resources are given to a particular instance of a program. If it's not in the list, the program doesn't get it, and doesn't even know about it. This lets the user decide what they want to work with, and strongly limits the side effects of a program gone rogue.
It's not a very hard thing to conceptualize, nor to plan out. The hard thing is the massive amount of investment in our current code base, and mind-set, which need a subtle tweak, and some clever hacks.
There are positive signs, but I fear it will be another 10-20 years or more before a system which is default deny becomes the more popular choice. That's a lot of time and effort thrown away, that could be better utilized.
Wrong
Copyright is a social contract, in which the Government grants a monopoly for a limited amount of time over the publishing of a work for profit, in exchange for a social good, the eventual transfer of that work into the public domain.
Disney, et al. have perverted this social contract into a pseudo-property right, and have the full force of the threat of PMITA prison to try to keep people from sharing things, against evidence that people who share actually buy MORE copyrighted materials from publishers.
This whole thing is a mess, but I think it's important to know the original reasons things were set up so we can do it right when we set it up all over again after the collapse of the US in the next few years.
Copyright infringement requires that you profit from it. While it appears that Aaron knew he was taking a risk, I strongly doubt that profit was his motive.
I found myself in this same position a number of years ago, I've settled on using ubuntu linux, iproute2, and iptables, it's not easy to get working right, especially when you have DSL instead of a nice normal IP based connection (I will forever hate PPPoE)
The mental gymnastics of tracking ip connections across two separate routing tables in the same box will give you a few headaches, especially when a packet which comes in through the DSL heads back out the WiFi interface for no apparent reason... it's definitely not easy to get working. PPPoE imposed by our new DSL vendor added a new level of hell once we moved.
If you can find a piece of hardware which works well for less than a weeks worth of your time and effort, that has good reviews, and supports PPPoE, buy it, and don't look back.
Information asymmetry makes even the fastest analysis on the planet irrelevant as the data input is garbage. It is this lack of transparency which resulted in the housing bubble, etc.
The "too big to fail" banks regularly hide data from customers, regulators, and other branches of their own organization.
This is interesting because of the speedup of FPGAs, but don't be fooled by a second that it addresses an actual business need, other than PR.
If the market were fair and open, this kind of thing wouldn't even be possible, because everyone would already know what code runs in the servers. It's the opacity that allows information asymmetry which gets us into trouble every time by enabling market manipulation.
All trades should be batch processed, every 5 minutes, and all this high-frequency scamming should be pulled out by the root. An open, honest, well regulated market is in the best interest of all investors.
No, not on Windows. Windows has a per-process token and the privileges of that token does not have to match any account at all. The token consists of a list of SIDs which can represent groups (which in turn appear in ACLs) *or* the SIDs represent privileges, e.g. setting time zone, restarting the system, log on as batch service etc. You do *not* need to set up an account with the desired privileges. You just need to prune the token itself.
On Linux there are also "Linux Capabilities" which are a few number of bits which represent capabilities that are not linked to any specific resource. These can even be considered "mini tokens" as they appear in the process descriptor as well. They are poorly implemented, though, and woefully underused.
What you cannot do with Windows process token is represent more advanced (parameterized) privileges such as CPU quota.
These generic privileges are defined system wide, whereas capabilities are specific to a single file, device, etc. If you have access to files a,b, and c, it's not possible to give another process access to only a and c with privileges, but it's trivial with capabilities.
I hope that adequately explains the difference.
It's enough, in theory, to do this. However, in practice it is not.
If you have a web server you want to run, to serve up files from /usr/mike/www and to log files to /usr/mike/logs/www, you'd have to build a new account for the daemon, and set permissions on all of the files system wide to make sure the web server task couldn't access them.
Once that's done... the web server is secure... however, you've had to modify a lot of security settings for this one-off job, and those persist unless you clean them up.
Those settings may not be possible from a user account, which means a lot of administrator involvement, and reduced functionality for the users.
With capabilities, you give the web server program a read capability to /usr/mike/www, and a write token to /usr/mike/logs/www, and a token to listen and communicate on port 80, and you're done. If you decide to stop serving web pages, there's no cleanup.
If the user has permissions to do all of those things, the can delegate them to a task... and revoke them at will, without having to bother the administrator.
Interesting. So one would not be able to implement capsec through a process token? Because it still sounds a lot like Windows Privileges/Linux Capabilities except that those privileges/capabilities are binary (has the privilege or has not) and you gave examples of privileges which would need to be parameterized (cpu load, target IP addresses, target urls).
If you wanted to hand off access to a new process, which had ALL of the permissions of another process, this would work. However, if there were ANY differences at all, you'd have to create a new account, then set up permissions on all of the system resources to match your new desired access for the new account, and then pass along information via inter-process pipes, shared files, etc. Otherwise you run right back into the need to trust programs, and bad security.
Because capability based systems only let you get at resources in the list for given process, it's very transparent (to the user, programmer, administrator) what's going on.
Here's an example to make the point:
If you want to write a program that takes a file access capability as input and gives a corresponding read-only capability to the same file, it's easy to do, and as long as the code isn't flawed, the protection is iron clad. If that filter program has a flaw, the very worst possible case is that the original capabilities leak through.
Another way to think about it is that capabilities are like a parameter list, and the only possible side effects to a given process are limited (by the OS) to those parameters.
I hope that clarifies the differences.
Multics was not a capability system.
You're right... Multics didn't have capabilities, my mistake, I thought it did... a myth shattered.
There was also a system named KeyKos which was used on mainframes to great effect, in the 1980s.
[citation needed]
KeyKos didn't get off the ground util 1987, according to http://www.redbug.org/dba/sharerpt/share70/o609.html
Capability Based Security will be making it to your machines, it's just a question of time.
Enjoy your delusions.
But do tell, how does a relational database system work with capabilities? You'd need a capability to access the database, and each table, and each row? How does that work?
You'll need better than a toy system, son.
Perhaps I am deluded... I hope not. You've killed some of the misconceptions I had about it, and for that I thank you. I believe the idea still has great merit, though... because we really shouldn't be forced to trust software beyond the OS itself. All of the examples I've given in my other replies point out the need to remove the default permit design decision that's baked into everything. We must fix this, it's a question of becoming aware of the problem, then becoming aware of possible solutions, then actually solving the problems, for good.
Most of the capabilities concepts I'm familiar with our file oriented, but it should be possible to do the same thing with records, fields, etc... in a database. There's nothing stopping someone from adding them as a layer on top of a database, just like the layer of permissions that some databases support.
Another approach is to hand a database capability to a filter program, and give the filtered capability to the untrusted program, to prevent misbehavior from successfully breaking security.