People drive cars without understanding the intricacies of internal combustion, electronic ignition, anti-lock brakes, etc... but they do understand capabilities.... it's called car keys.
If you hand someone the keys, they can access your car... it's simple.
Capability based security (cabsec) is just a hand full of keys, instead of one. A key for each resource. It's quite intuitive.
It was implemented a long time ago in a system called Multics, but that got displaced when a couple of guys did a light-weight clone with a lot less need for security... called Unix.... this then got cloned by Linus in Linux.
There was also a system named KeyKos which was used on mainframes to great effect, in the 1980s.
In the mean while, we've had personal computers which didn't need good security since they weren't widely networked, until very recently. So now really good security is just becoming a concern again. Eventually the pendulum will swing back to the point where people realize things need to change.
Capability Based Security will be making it to your machines, it's just a question of time. The sooner the better.
Security via access list is nice, but it is per user and persistent. It is not something automatically revoked when a process terminates, nor is it assigned only to one task. Setting up a new process with access to only 3 files, and 3 registry keys requires explicitly setting up an account for the process, and setting the permissions on everything it might be able to touch, to limit access to only those things.
It is much simpler to have a list of explicitly granted rights, with the default to be no access if it's not in the list. This is the power of capability based security. (Cabsec)
It is unfortunate that it's necessary to try to overload an existing term with a new, slightly different definition, but that's what has happened here.
Capabilities in a capability based system (cabsec for short) are fine grained access rights to things like single files, a directory, etc. They are explicitly granted at run time to a process, they are not persistent.
This is in contrast to the Access Control List permissions of VAX/VMS, inherited by Windows, and the User/Group/World permissons of Unix/Linux, both of which are geared towards restricting the rights of a user, and are generally persistent.
For example, if you give a process write access to a log file, and I/O access to the internet, and 1% of total cpu use....it could watch something on the net, and log the results. It could not access anything other than the log file, no matter what... this means a buffer overflow bug, or any other fault could not cause data to leak from the system.
In a permissions/ACL based system, the administrator decides the rights of users, and the programs they run, without distinction
With cabsec capabilities, the user decides which of their rights they wish to delegate to a process or program. This frees the user from the need to trust a given program with all of their rights. This also frees the system administrator from having to set up extra accounts with limited permission for each new service or daemon that needs to be run.
I see cabsec as a very useful extension to the existing user permissions systems. Combined you get the best of both worlds.
Actually, this is done some of the time under Linux, it's called AppArmor.
Getting capabilities fully integrated into Linux, in a user friendly format, should be feasible, if there were a community that wanted to make it happen, and we could get Linus to go along with it. The whole SE/Linux and security plugin infrastructure gets us part way there.
There's no need to re-write apps, it's just a matter of a few more errors if the app tries to do something forbidden.
Even Windows could support it, with current apps, but then Microsoft wouldn't be able to use it to push Office 2020.
Using a system where the program has to be trusted to do its job correctly is the bigger mistake. When you hand your car keys to a valet, you don't also give him power of attorney to sell your house, liquidate your stocks, savings, etc... but every operating system out there does something like that when you tell it to run a program. The program you run can do anything you are authorized to do. The default assumption is that it should have permission to do anything, no matter how stupid, dangerous, or downright evil.
This practice needs to end, about 10 years ago it should have ended... and we'll probably have to wait 10 more years because it's so freaking hard to get this idea across, nobody seems to be ready for it yet, by the way things seem to be going.
A user should be able to decide exactly which and how much of the resources they are authorized to use will be allowed to be accessed by a program they choose to run. If you want to run a program with read/write access to/sandbox, and the ability to read from the internet using a filtered http driver (one that doesn't allow puts, for example), you should be able to do so, without having to do any fancy footwork.
If put in to place, this type of system, which explicitly states what access things get, make it almost trivial to never get a virus or worm ever again. It's time to stop trusting programs, and only have to trust the hardware and OS to enforce our wishes.
I impatiently await the arrival of capability based security.
Actually, with Richardson-Lucy deconvolution it's possible to recover the information, as long as you have the positions of the pixels, and the diffusion function to enough precision.
Because a big sensor with a microlens array could be calibrated, you could use Richardson-Lucy deconvolution to recover almost all of the raw resolution of the original sensor if the computing resources are available, in a given plane of focus.
I've been doing this for a few years, with one camera taking many views, since I first found out about the research they were doing at Stanford. Here are some scenes around Chicago which are composites of many photos to generate a synthetic focus. The idea is to capture the scene from many slightly different points of view, and to capture all of the parallax information, which then yields depth.
I haven't be able to make it happen, but it should be possible to combine N pictures to get a bit less than N times the normal resolution. If you had 100 photos that were 8 megapixels each, you should be able to composite them into a 100 megapixel image with the right alignment and extrapolation algorithms.
With bitcoins, there is no way to lend money you don't have. This makes it impossible to do fractional reserve banking without coming up with some for of promissory note that can be substituted. (If people had an option, they would never take a paper dollar promise instead of a real silver dollar, would they?)
On the other hand it is easy to charge interest. It would be darn foolish to risk your hard earned bitcoins by lending them out without expecting at least some return on your investment to cover the risk and opportunity costs. Earning interest on money isn't evil... being able to earn interest on money you don't have IS evil.
The prohibition of fractional reserve banking is a VERY good attribute of bitcoin, as it discourages reckless speculation of bitcoins. (Not to say that the whole bitcoin market itself isn't in a bubble, though)...
The IP6 folks hate NAT, but it's the only thing that's saving personal computing at the moment. Because random inbound connections don't has through NAT devices, any home PC behind one is MUCH safer than one directly on the internet. It sucks in terms of the end to end utility of the internet, but it's the tradeoff most users are willing to make for reasonable safety.
In the Woody Allen movie, "The Sleeper", the "fearless leader" is recreated from cells cloned from his nose.... it's beginning to look like he was right.
Next thing we know, we'll find out that nuts are bad for us.
I've already suggest to my local representative that she introduce similar legislation in Indiana..... here's what I wrote:
I ask that you consider introducing legislation similar to that of the recently pulled HB 1937 of the State of Texas.
It would criminalize the types of searches the TSA has been doing, which are in violation of the 4th Amendment of the US Constitution.
In introducing this, you would show that you stand for the rights of your fellow Hoosiers. We don't have as much air traffic to worry about, so their is less fallout. You would also show some distance between yourself and the DC beltway crowd, which will probably come in handy soon, as they keep debasing the dollar, leaving the States out to dry.
I'm one of the token Windows system admins here... and even I know that this stuff is just bloatware.
dynfw is just a script to do a few things with iptables, its not new functionality.
OpenSCAP is just some tools to manage code signing, which is an attempt to enumerate goodness, and doesn't actually fix things by improving security.
I thought they were talking about something new and useful... not just some hype... oh well... looks like they care catching up with uSoft in that department.
"MartinLuther: Some thoughts about cleaning up the Church a bit - http://saint.ly/CCCXVII #Reformation #IndulgencesSuck #Protestant" -- Martin Luther, 1517
Instead of trying to get one identity to rule them all, why not go with the approach that has worked for thousands of years? It's capability based security, but you're likely not heard that term used in the context before.
In the past, if you owed someone $19.95, you would hand a $20 bill, and wait for change. In this type of transaction, the most you can lose is the amount you pay. In this case, an $20 bill is a capability token.
Sometimes you want to stop or reverse a transaction. To do this, you need to revoke a capability. With cash, you can simply get your money back. Once this is done, there are no trust issues after the fact. It's nice and simple.
The credit card model on the other hand has you handing your entire credit capability to the merchant. If you want to revoke it, you're out of luck in terms of a single transaction, you have to TRUST the merchant, and all of their employees, from that point forward to do the right thing. You also have to trust all of the other merchants and their staff as well, accumulating a large pool of people and computers, until the token expires or is revoked. Revoking the capability usually entails a few days of outage as well.
With computers and the internet, a username/password system really doesn't prove identity, but it is a bit more secure in that you can have many different capabilities instead of a single concentrated pool of mis-trust. (Assuming of course you don't use the same username - password pair in more than one place) Revoking an capability in this case involves different procedures for each and every one, there isn't much uniformity to the process.
OpenID was a good idea in that it let you get away from handing over everything, and got us started on the road to capabilities, but it doesn't go far enough in that direction.
Most other approaches to federated identity involve a similar ever growing pool of people and machines you have to trust, with the subsequent amount of grief when the identity capability has to be revoked. When viewed from the capabilities perspective, this isn't desirable.
Isn't it better to issue individually revocable capability tokens? There's no reason not to have the phone talk to the actual service that does the work. The private keys, etc... should never be carried around on one's person, nor stored in a system used for other things on the internet.
In summary: We need to stop thinking in terms of identity when considering permissions, and start shifting to one of capabilities instead.
We may be a bit different here in Indiana, but we don't let the defendants know our names here. The judge was pretty careful about instructing us during the selection process. How could a jury possibly return a guilty verdict in a murder trial if the defendant knew their names and could then extract revenge?
Yeah... almost... except that SE Linux is a kernel patch, its not embedded all the way down into everything. It is definitely a step in the right direction.
It's also the way that our applications are written that needs to change as well. They need to stop relying on the ability to perform arbitrary actions.
Slashdot Mirror
People drive cars without understanding the intricacies of internal combustion, electronic ignition, anti-lock brakes, etc... but they do understand capabilities.... it's called car keys.
If you hand someone the keys, they can access your car... it's simple.
Capability based security (cabsec) is just a hand full of keys, instead of one. A key for each resource. It's quite intuitive.
It was implemented a long time ago in a system called Multics, but that got displaced when a couple of guys did a light-weight clone with a lot less need for security... called Unix.... this then got cloned by Linus in Linux.
There was also a system named KeyKos which was used on mainframes to great effect, in the 1980s.
In the mean while, we've had personal computers which didn't need good security since they weren't widely networked, until very recently. So now really good security is just becoming a concern again. Eventually the pendulum will swing back to the point where people realize things need to change.
Capability Based Security will be making it to your machines, it's just a question of time. The sooner the better.
Security via access list is nice, but it is per user and persistent. It is not something automatically revoked when a process terminates, nor is it assigned only to one task. Setting up a new process with access to only 3 files, and 3 registry keys requires explicitly setting up an account for the process, and setting the permissions on everything it might be able to touch, to limit access to only those things.
It is much simpler to have a list of explicitly granted rights, with the default to be no access if it's not in the list. This is the power of capability based security. (Cabsec)
It is unfortunate that it's necessary to try to overload an existing term with a new, slightly different definition, but that's what has happened here.
Capabilities in a capability based system (cabsec for short) are fine grained access rights to things like single files, a directory, etc. They are explicitly granted at run time to a process, they are not persistent.
This is in contrast to the Access Control List permissions of VAX/VMS, inherited by Windows, and the User/Group/World permissons of Unix/Linux, both of which are geared towards restricting the rights of a user, and are generally persistent.
For example, if you give a process write access to a log file, and I/O access to the internet, and 1% of total cpu use....it could watch something on the net, and log the results. It could not access anything other than the log file, no matter what... this means a buffer overflow bug, or any other fault could not cause data to leak from the system.
In a permissions/ACL based system, the administrator decides the rights of users, and the programs they run, without distinction
With cabsec capabilities, the user decides which of their rights they wish to delegate to a process or program. This frees the user from the need to trust a given program with all of their rights. This also frees the system administrator from having to set up extra accounts with limited permission for each new service or daemon that needs to be run.
I see cabsec as a very useful extension to the existing user permissions systems. Combined you get the best of both worlds.
Cool... thanks for the pointer, I've added to my delicious bookmarks about capabilities
Actually, this is done some of the time under Linux, it's called AppArmor.
Getting capabilities fully integrated into Linux, in a user friendly format, should be feasible, if there were a community that wanted to make it happen, and we could get Linus to go along with it. The whole SE/Linux and security plugin infrastructure gets us part way there.
There's no need to re-write apps, it's just a matter of a few more errors if the app tries to do something forbidden.
Even Windows could support it, with current apps, but then Microsoft wouldn't be able to use it to push Office 2020.
Using a system where the program has to be trusted to do its job correctly is the bigger mistake. When you hand your car keys to a valet, you don't also give him power of attorney to sell your house, liquidate your stocks, savings, etc... but every operating system out there does something like that when you tell it to run a program. The program you run can do anything you are authorized to do. The default assumption is that it should have permission to do anything, no matter how stupid, dangerous, or downright evil.
This practice needs to end, about 10 years ago it should have ended... and we'll probably have to wait 10 more years because it's so freaking hard to get this idea across, nobody seems to be ready for it yet, by the way things seem to be going.
A user should be able to decide exactly which and how much of the resources they are authorized to use will be allowed to be accessed by a program they choose to run. If you want to run a program with read/write access to /sandbox, and the ability to read from the internet using a filtered http driver (one that doesn't allow puts, for example), you should be able to do so, without having to do any fancy footwork.
If put in to place, this type of system, which explicitly states what access things get, make it almost trivial to never get a virus or worm ever again. It's time to stop trusting programs, and only have to trust the hardware and OS to enforce our wishes.
I impatiently await the arrival of capability based security.
Actually, with Richardson-Lucy deconvolution it's possible to recover the information, as long as you have the positions of the pixels, and the diffusion function to enough precision.
Because a big sensor with a microlens array could be calibrated, you could use Richardson-Lucy deconvolution to recover almost all of the raw resolution of the original sensor if the computing resources are available, in a given plane of focus.
I've been doing this for a few years, with one camera taking many views, since I first found out about the research they were doing at Stanford. Here are some scenes around Chicago which are composites of many photos to generate a synthetic focus. The idea is to capture the scene from many slightly different points of view, and to capture all of the parallax information, which then yields depth.
I haven't be able to make it happen, but it should be possible to combine N pictures to get a bit less than N times the normal resolution. If you had 100 photos that were 8 megapixels each, you should be able to composite them into a 100 megapixel image with the right alignment and extrapolation algorithms.
What years were your dollars coined in? ;-)
Don't you just love that silvery ring when you hold them in the center, and tap the outer rim?
Wow... my $1.59 equivalent of bitcoin just became $1.00 equivalent.... if I can ever spend it for something.
On the other hand my US Dollar (The real kind, coined in 1901) is worth $28.00 in Federal Reserve "Notes"
I'll keep stacking both kinds, as they each have their appeal to me.
NO, you can't... the IRS does not accept cash!
With bitcoins, there is no way to lend money you don't have. This makes it impossible to do fractional reserve banking without coming up with some for of promissory note that can be substituted. (If people had an option, they would never take a paper dollar promise instead of a real silver dollar, would they?)
On the other hand it is easy to charge interest. It would be darn foolish to risk your hard earned bitcoins by lending them out without expecting at least some return on your investment to cover the risk and opportunity costs. Earning interest on money isn't evil... being able to earn interest on money you don't have IS evil.
The prohibition of fractional reserve banking is a VERY good attribute of bitcoin, as it discourages reckless speculation of bitcoins. (Not to say that the whole bitcoin market itself isn't in a bubble, though)...
I know that NAT doesn't help security against an advanced persistent threat, but it does scrape off the top 99% of all attacks, which is a big plus.
A stateful firewall can scape off another 99%
Locking down each service with AppArmor can scrape off another 99%
Which means you'll still have no effective security against an advanced persistent threat... you'll only be stopping 99.9999%, not all of it.
Capability based security might give you another 99%, which is good, but not enough.
The IP6 folks hate NAT, but it's the only thing that's saving personal computing at the moment. Because random inbound connections don't has through NAT devices, any home PC behind one is MUCH safer than one directly on the internet. It sucks in terms of the end to end utility of the internet, but it's the tradeoff most users are willing to make for reasonable safety.
In the Woody Allen movie, "The Sleeper", the "fearless leader" is recreated from cells cloned from his nose.... it's beginning to look like he was right.
Next thing we know, we'll find out that nuts are bad for us.
I've already suggest to my local representative that she introduce similar legislation in Indiana..... here's what I wrote:
I ask that you consider introducing legislation similar to that of the recently pulled HB 1937 of the State of Texas.
Here's the link to their web site about the bill: http://www.legis.state.tx.us/BillLookup/Text.aspx?LegSess=82R&Bill=HB1937
It would criminalize the types of searches the TSA has been doing, which are in violation of the 4th Amendment of the US Constitution.
In introducing this, you would show that you stand for the rights of your fellow Hoosiers. We don't have as much air traffic to worry about, so their is less fallout. You would also show some distance between yourself and the DC beltway crowd, which will probably come in handy soon, as they keep debasing the dollar, leaving the States out to dry.
Thanks for your time and attention.
I'm one of the token Windows system admins here... and even I know that this stuff is just bloatware.
I thought they were talking about something new and useful... not just some hype... oh well... looks like they care catching up with uSoft in that department.
It's not a real link.... saint.ly was a cute reference to bit.ly
CCCXVII is the year of the 95 theses
"MartinLuther: Some thoughts about cleaning up the Church a bit - http://saint.ly/CCCXVII #Reformation #IndulgencesSuck #Protestant" -- Martin Luther, 1517
Instead of trying to get one identity to rule them all, why not go with the approach that has worked for thousands of years? It's capability based security, but you're likely not heard that term used in the context before.
In the past, if you owed someone $19.95, you would hand a $20 bill, and wait for change. In this type of transaction, the most you can lose is the amount you pay. In this case, an $20 bill is a capability token.
Sometimes you want to stop or reverse a transaction. To do this, you need to revoke a capability. With cash, you can simply get your money back. Once this is done, there are no trust issues after the fact. It's nice and simple.
The credit card model on the other hand has you handing your entire credit capability to the merchant. If you want to revoke it, you're out of luck in terms of a single transaction, you have to TRUST the merchant, and all of their employees, from that point forward to do the right thing. You also have to trust all of the other merchants and their staff as well, accumulating a large pool of people and computers, until the token expires or is revoked. Revoking the capability usually entails a few days of outage as well.
With computers and the internet, a username/password system really doesn't prove identity, but it is a bit more secure in that you can have many different capabilities instead of a single concentrated pool of mis-trust. (Assuming of course you don't use the same username - password pair in more than one place) Revoking an capability in this case involves different procedures for each and every one, there isn't much uniformity to the process.
OpenID was a good idea in that it let you get away from handing over everything, and got us started on the road to capabilities, but it doesn't go far enough in that direction.
Most other approaches to federated identity involve a similar ever growing pool of people and machines you have to trust, with the subsequent amount of grief when the identity capability has to be revoked. When viewed from the capabilities perspective, this isn't desirable.
Isn't it better to issue individually revocable capability tokens? There's no reason not to have the phone talk to the actual service that does the work. The private keys, etc... should never be carried around on one's person, nor stored in a system used for other things on the internet.
In summary:
We need to stop thinking in terms of identity when considering permissions, and start shifting to one of capabilities instead.
"Everyone in the room knows the name of potential jurors once they have been placed into the box for questioning - at least in NY and NC."
Wow... there's no way to render a fair verdict in that type of environment.
We may be a bit different here in Indiana, but we don't let the defendants know our names here. The judge was pretty careful about instructing us during the selection process. How could a jury possibly return a guilty verdict in a murder trial if the defendant knew their names and could then extract revenge?
This is just nuts!
Yeah... almost... except that SE Linux is a kernel patch, its not embedded all the way down into everything. It is definitely a step in the right direction.
It's also the way that our applications are written that needs to change as well. They need to stop relying on the ability to perform arbitrary actions.