Thanks for the pointer to AppArmor, it appears to be a very good step in the direction of least privilege execution of program. The "learn" mode makes it easier to configure things, which helps out the novice.
Doing this on the Windows side of the world is, of course, impossible, because you can't patch the kernel there, and there's no equivalent of Linux Security Modules.
I guess the closest we could get would be to run apps in Wine with an AppArmor profile for each one. 8)
I'm not trying to game the system... I hit the karma cap a few years ago, and really don't care about it. I do care very much about making a what is a subtle distinction a bit more clear.
I'm sorry if my writing wasn't up to snuf.
A lot of people will tell you that an Object Capability System can't do anything more than one based on Access Control Lists. This argument is much like the ones posed against Structured programming when it came out... the opponents to change all said "well.. it doesn't really do anything new"... and if you picked enough nits, you could technically say they were right, in terms of the expressiveness of the program.
However, in practice it's not just about the types of computation your code you can express, but rather the programmers productivity. Structured programming made it easier to get things done. It saved programmers time.
In theory, in an ACL based system, you can run a program inside of a sandbox. You first create a new account for a program to run inside of, and then lock down the permissions of the rest of the system to make it safe. This is a non-trival task, which must be done perfectly if your program you wish to run turns out to be malicious.
A capabilities based system is designed from the start to enforce a policy of least privilege. That means that a program should given only the capabilities it requires to execute the task at hand, and nothing more. To run a program in a "sandbox" requires no more action that only giving it a sandbox to play in, the system enforces the rest. Not only that, it makes it possible for an end user to decide what rights to give a program without having to check all of the rest of the system.
The lack of awareness of the Capability Object Model severely constrains the possible futures that can be imagined by most of us, and we're making bad choices because of that ignorance.
I'm just trying to shine some light into the darkness.
It's like structured code vs assembler.... you can do the same thing in either, in theory.
The difference is that the USER should get to pick which side effects they want to let a given random piece of code get away with, regardless if it was written in Redmond or somewhere else.
There's currently no way for a user to specify what a program can/can't do other than to create an account, set the permissions on EVERYTHING it might touch, and then hope it doesn't somehow do something bad anyway due to a bug somewhere in any of the code currently running on the system.
This is true in pretty much any popular OS.
I realized the difference is subtle, but it's very important.
Wouldn't it be simpler (but by no means easier) to allow the user to specify what side effects they are willing to allow a program to create before they run it?
System updates would be allowed pretty much any side effect (but not the user folders).
Web browsers could only connect to the net, and their local folder, but nothing else.
How about giving the user more choices? You might want to let them run it in a sandbox, or run it without internet access, or chroot it.
If they had a way to express their intent, and actually control how much they give away when they click... it would go a VERY long way towards fixing things, probably 99%.
That doesn't help the situation. If windows goes away, the problem with just migrate to Linux.
Until we get to the point where you can assign permissions to every single program for every single role you expect that program to fulfill, it's not going to get much better.
--Mike--
That doesn't fix the confused deputy problem. Even if the user never makes a mistake, their system can still be compromised. You should NEVER have to trust an application to contain itself to a set of capabilities. That's what Operating Systems are supposed to do for you.
Amen!
Imagine having two broken hands. You would have no way to directly take the money from your wallet and manage it yourself, you'd be forced somehow give your entire wallet to someone each time you wanted to pay. It would be almost impossible to prevent them from slipping an extra $20 unless you happened to see it. You're forced to trust someone completely.
For the foreseeable future, we're all dealing with two broken hands. There's no way to pick which parts of our set of capabilities we want to hand to a program. We have no way of stopping it from taking our personal data and sending it away, holding it hostage, or subtly sabotaging it.
I want my metaphorical fingers back.
--Mike--
The F117 was retired early because all of the stealth tech in the world can't protect you from obsolete LOW frequency radar. If you use wavelengths that are significantly longer than the thickness of the paint, it's really not going to do anything to stop the underlying airframe from sending back a nice strong signal.
If you want to avoid getting your transmitter killed, just use a local FM or TV station and make it a passive radar system.
So... the folks at DHMO should file a patent for Dihydrogen Monoxide, after all they invented it!
You don't invent drugs, you discover them. The trick is figuring out the right drugs to use, and the manufacturing process to get them produced at an acceptable cost.
Patents are a balance struck to encourage capitalists to invest in things which ultimately help us all when they enter the public domain.
You're right... but at least the user would have a chance to know what it was really trying to do... which levels the playing field by introducing some transparency for the user.
While it may be true that it's easier to run malware in Windows, that not the only reason for botnets, malware, etc. There's no capability object model in the current crop of desktop Operating Systems, so there's no control over what a rogue/faulty/misconfigured program can do.
Once capabilities get baked in to the OS kernels, you don't have to trust anything except the kernel, ever again.
Blaming the users doesn't fix the problem, the missing object capability model which would make it possible to try out a program in a sandbox, without having to trust the program.
Short of running every single new program in a clone of the machine inside an isolated VMware box, you can't do this with Windows, Linux or Mac.
Slashdot Mirror
Doing this on the Windows side of the world is, of course, impossible, because you can't patch the kernel there, and there's no equivalent of Linux Security Modules.
I guess the closest we could get would be to run apps in Wine with an AppArmor profile for each one. 8)
Secure hardware is an essential foundation for a secure operating system, but secure hardware doesn't do anything useful if the OS is junk.
I'm sorry if my writing wasn't up to snuf.
A lot of people will tell you that an Object Capability System can't do anything more than one based on Access Control Lists. This argument is much like the ones posed against Structured programming when it came out... the opponents to change all said "well.. it doesn't really do anything new"... and if you picked enough nits, you could technically say they were right, in terms of the expressiveness of the program.
However, in practice it's not just about the types of computation your code you can express, but rather the programmers productivity. Structured programming made it easier to get things done. It saved programmers time.
In theory, in an ACL based system, you can run a program inside of a sandbox. You first create a new account for a program to run inside of, and then lock down the permissions of the rest of the system to make it safe. This is a non-trival task, which must be done perfectly if your program you wish to run turns out to be malicious.
A capabilities based system is designed from the start to enforce a policy of least privilege. That means that a program should given only the capabilities it requires to execute the task at hand, and nothing more. To run a program in a "sandbox" requires no more action that only giving it a sandbox to play in, the system enforces the rest. Not only that, it makes it possible for an end user to decide what rights to give a program without having to check all of the rest of the system.
The lack of awareness of the Capability Object Model severely constrains the possible futures that can be imagined by most of us, and we're making bad choices because of that ignorance.
I'm just trying to shine some light into the darkness.
--Mike--
Too late, it's already in the BIOS. ;-)
Sounds like a prudent strategy to me, not perfect, but apparently good enough.
That's true, but then again safety belts save lives in many cases regardless of the ones who refuse to use them.
It's like structured code vs assembler.... you can do the same thing in either, in theory.
The difference is that the USER should get to pick which side effects they want to let a given random piece of code get away with, regardless if it was written in Redmond or somewhere else.
There's currently no way for a user to specify what a program can/can't do other than to create an account, set the permissions on EVERYTHING it might touch, and then hope it doesn't somehow do something bad anyway due to a bug somewhere in any of the code currently running on the system.
This is true in pretty much any popular OS.
I realized the difference is subtle, but it's very important.
It might make us feel better, but it's not a solution.
--Mike--
System updates would be allowed pretty much any side effect (but not the user folders).
Web browsers could only connect to the net, and their local folder, but nothing else.
etc, etc.
How about giving the user more choices? You might want to let them run it in a sandbox, or run it without internet access, or chroot it.
If they had a way to express their intent, and actually control how much they give away when they click... it would go a VERY long way towards fixing things, probably 99%.
--Mike--
Sorry, take your magic bullet home, and try again. Heuristics only catch the obvious, and not the subtle nor patient.
Any idea where I can get something like that? I haven't seen a copy of KeyKos, CapROS, or Eros sitting on the shelves at Best Buy lately.
--Mike--
That doesn't help the situation. If windows goes away, the problem with just migrate to Linux.
Until we get to the point where you can assign permissions to every single program for every single role you expect that program to fulfill, it's not going to get much better.
--Mike--
--Mike--
Amen!
Imagine having two broken hands. You would have no way to directly take the money from your wallet and manage it yourself, you'd be forced somehow give your entire wallet to someone each time you wanted to pay. It would be almost impossible to prevent them from slipping an extra $20 unless you happened to see it. You're forced to trust someone completely.
For the foreseeable future, we're all dealing with two broken hands. There's no way to pick which parts of our set of capabilities we want to hand to a program. We have no way of stopping it from taking our personal data and sending it away, holding it hostage, or subtly sabotaging it.
I want my metaphorical fingers back.
--Mike--
If you want to avoid getting your transmitter killed, just use a local FM or TV station and make it a passive radar system.
--Mike--
You don't invent drugs, you discover them. The trick is figuring out the right drugs to use, and the manufacturing process to get them produced at an acceptable cost.
Patents are a balance struck to encourage capitalists to invest in things which ultimately help us all when they enter the public domain.
You're right... but at least the user would have a chance to know what it was really trying to do... which levels the playing field by introducing some transparency for the user.
Capabilities based security is the way to go, and sandboxing is a good start towards getting there.
Linux doesn't have it either, but at least we could add it if we really wanted to.
Once capabilities get baked in to the OS kernels, you don't have to trust anything except the kernel, ever again.
Short of running every single new program in a clone of the machine inside an isolated VMware box, you can't do this with Windows, Linux or Mac.
Some popular implementations include WiFi and BlueTooth.