Lately I've had to frequently correct my 5 year old daughter on this point. I tell her that if you don't use your words in the same way everyone else does, they will decide that you don't know what you're talking about, and stop listening to you.
For any given -ism, there is a compulsory submission to the philosophy, otherwise it's not universal, and it falls apart. This is true even for technologism.
There is no inherently good or bad philosophy in most of those, it's the implementation details that make or break it.
The main difference between the Soviet Union and the US is that we were better at debasing our currency without anyone noticing, and living on credit. Our standard of living has been in a steady decline since the late 1960s
The main difference between the US and China today is that China has forward thinking oligarchs, whereas ours sold us out to them starting in the 1970s. That's why they manufacture things (albeit in a very environmentally unfriendly way), and we don't. We can't make all the parts for our own weapons systems any more.
The Soviet Union eventually collapsed.... whereas we haven't, yet
You're correct... and nobody things that hosts can be secure, because our current conception of security is that it makes something unusable. It doesn't have to be that way, and I've pointed that out many times, but preaching about capability based security to this choir just doesn't work.
The big problem with files is that they get disconnected from context far too easily, especially when you share them with others. This realization is why I want to build the inter-tubes protocol. It syncs up collections of files, deals with permissions, and makes a set of services available to get thumbnails of photos, etc
My use case goes like this:
I have 330,000 photos I've taken in the last 14 years. I'd like to share them. The current choices are
email a few at a time
post them on Flickr, FaceBook, or some other site
give someone a copy of ALL of them on an external drive.
What I'd like to do instead is to give them a small file which contains permissions to access my tube containing my photos. It would be a very small file, with just a few cryptographic signatures, probably less than 20k. However, this would then allow the user to list all of my photos, and use the thumbnail service associated with it to pull across thumbnails of things (instead of the full size images).
If they then find a file they like, the can get the full size version. If they then add tags or comments to the file, those would get synced back to me via the tubes.
When I saw the camera array focus through the bushes behind their subject... I was hooked. However I didn't have the budget, so I started experimenting with 1 camera and many shots from a small area... if you have stationary subjects, you can do the refocusing with a single camera and a lot of time....
I love this thread... it is insane to try to keep a system like this designed for a few clients in the 1950s and 1960s alive when it has scaled to a significant fraction of the planet's population. Cryptography would be a great leap forward, but even a few simple things could make it much better like having a website for each of the major CC/Debt card vendors where you can have them generate a new random large number for handing off (via cut/paste, or whatever) to a vendor, which gives them a claim for x dollars from your account... once, or whatever schedule/limits you set.... and would only work for their account, nobody elses.
Even if their computers were stolen, the number wouldn't work for anyone else..... and if they tried to screw you, you'd just revoke the capability from your control panel, and they'd never get another cent.
This could be done with 1970's class mainframe hardware... and would require only a few nano-cents worth of storage these days.... yet we get screwed by the IT systems designed in the 1950s.
Argh... we're building weapons systems based on windows or mac or linux? What are these people, nuts?
If there was ever a place where capability based security should be used, this is it. An application that has the ability to literally kill people should not be run in an environment which defaults to permissive... this means that ANY application on that system could potentially kill someone.
With the exception of a few wise souls here and there, nobody else seems to get the idea that this kind of thing can be stopped, dead, in its tracks. (Pun intended)
Capability based security offers a path forward to computers that trust nothing by default... the exact opposite of what we have now. They don't have to be unusable, nor layered with ineffective anti-spyware, anti-malware, etc...
Just stop trusting applications, and specify what they can do, as a maximum extent, before you execute them. This limits the damage a rogue (or just confused) application can incur before it's even run.
Now... I've obviously made some typos and a few things could be made clearer in the above... unfortunately/. doesn't allow editing or clarification of a post after it's written... nor does it offer any voting other than a popularity contest... so let the inefficient commenting begin.
I'd redo the moderating system to be tag oriented... so that a comment could be "funny" and "insightful" and "accurate" and "wise", etc... with each of the tags being given a weight by someone who casts a vote.. The tags would be just any old text, with the most common ones showing up in a list.
If we can then filter based on the tag weights, we could then filter out funny posts, or innacurate ones, or flamebait depending on our mood.
It can be MUCH better... but requires a shift in thinking away from the popularity contest.
Furthermore, when your mom makes toast... she doesn't have to worry about the toaster somehow accessing every previous piece of toast it ever had access to and suddenly sending those atoms to a temperature of 10000 degrees.... it's obvious when you have a toaster running what the inputs and outputs are.
When my mom installs Firefox, she doesn't how to choose a folder for cookies, or where the cache can reside, or where she can download files to, or where the plugins are (or what a plugin is...). Quite frankly, she doesn't care to learn these things, we programmers should "just make it work" for her. She doesn't have to know how a car works does she?
Does your toaster automatically attach itself to bread as an option? - Computers are different beasts, and analogies don't always apply.... be careful.
When your mom buys a toaster, she doesn't have to wire it directly in to the house. She doesn't have to worry that plugging it in will cause the entire town to go into blackout. She doesn't have to worry that the toaster will somehow send all the money in her purse to a hacker group in Anchorage... why is that?
The outlets are generic and standardized, and protected by an operating environment which prevents the devices attached from consuming excess current.
The capability to draw up to 15 amps is a separate and distinct capability from the physical possession of a purse.
Even though she has all of those things, she knows better than to try to put her purse into the toaster.
Furthermore, she chooses exactly what food items to put into the toaster.... she's never mistakenly put the goldfish into the toaster... nor would she.
Note that none of this requires detailed knowledge of how toaster internals work... in the same way that users shouldn't have to know about application internals.
Choosing what goes into what appliance isn't rocket science... and to imply that a user can't make such decisions just because they happen to be managed inside a computer is insulting to the users, and incorrectly focuses the attention of those seeking to make things better.
The responsibility for preventing security problems with PCs should strictly fall into 2 places, the User, and the OS.... however... not the way 99.99% of you are thinking about it.
The user should decide what resources a program NEEDS in order to do a task, such as which folder it can access, what network connections, etc. This allows the user to decide ahead of time what they are willing to risk. Once that determination is made, the user then would give that list, along with a pointer to the program, to the operating system.
The OS should then enforce the users choices.... if it's not in the list, the application shouldn't even be able to find it, let alone access it. If the OS fails to enforce the users will, then the OS is at fault.... if the User gave away the store, well... they gave away the store.
This requires a simple change to the base design of operating systems, instead of permitting everything, and limiting actions of a running program to that of the user's account... the OS should limit the actions of the program to a short list of resources supplied by the user... and nothing else. Of course, the refactoring of everything to add this additional layer of logic is a massive undertaking.
There would still be the traditional user rights, access control lists, etc.... but there would also be a level of control where the user decides which of the resources they have should be given to the application. This is called "capability based security", or cabsec for short.
It's going to take somewhere between 10 and 15 years before people are fed up enough to make the switch.... but it will happen eventually.
Security isn't an application issue... it never was, and never will be.
The only thing that MUST be verified is the OS kernel, the rest can be dealt with as untrusted code. L4 is at this stage.
If your disk driver isn't formally verified, it can overwrite the boot sector.
If your file system driver isn't formally verified, it can modify the operating system files.
The OS doesn't have to trust the boot sector, it can verify the information using cryptographic signatures. If you treat the block devices as untrusted, you will do things like using checksums, CRCs, ECC, etc... don't forget that hard drives typically get 1 out of 10^15 blocks wrong in the normal course of doing business.
You can also encrypt/sign the drivers so the OS can check for modifications, should a rootkit be present.
Since an untrusted file system driver would have to use the OS to read / write the block devices, you could present it with a read-only capability to the block device which contains the OS, stopping all modification. In the case of a need for an update, the OS could then use a read/write capability to do the update, and switch back when done. I'm sure someone with a good background in CS could figure out a more secure way of doing it.
If your video driver isn't formally verified, it can overwrite any location in memory.
Not if the memory management is working correctly... Windows NT 3.5 and earlier had video running outside the kernel... which is the right way to do things in terms of security.
If your (insert just about anything here) driver that supports DMA isn't formally verified, it can also overwrite any location in memory.
Drivers don't have to run in kernel mode to be efficient, and the DMA doesn't have to be set up directly by the drivers. The MMU and the control over input parameters to the DMA/Interrupt subsystems should suffice here as well.
If your BIOS flashing driver isn't formally verified, the next time you boot you have a rootkit.
True, but to have a rootkit, it has to be installed at some point, which a secure OS would prevent.
On the other hand, if your threat model includes nation states, you can't stop rootkits installed using physical access to the hardware, if they have enough time... even a checksum bios could be subverted with the right hardware between the motherboard and storage.
Either way, attempting to detect faults and fouls should be a normal part of the boot process.
If your window manager/login prompt/other common OS programs aren't formally verified, they will allow privilege escalation.
Yes, they MIGHT allow privilege escalation, especially if they aren't well constructed and fairly transparent in their operation to the user. The key is to provide an easy to use facility for specification of exactly what permissions are to be given to a program. This needs some work, the first few widely used iterations will be a bit rough around the edges, but after some use and tweaking, it should be pretty easy to do. This results in a secure, efficient Operating System, with no need to trust any program.
The primary reason we even worry about root kits is that Operating Systems haven't been designed to work in a world of untrusted code. Changing that one aspect of things, doing a hell of a lot of coding to build a capability based OS, provides an environment in which it is very unlikely that any rootkit would get the opportunity to be installed.
Kernels can be replaced in real time, it's been done in Linux.
Something in hardware (which is implied in this new technology) has to be updateable in order to resist threats over time. It too will have the same critical points as any system which doesn't trust the code running on it.
A capabilities based operating system would have about the same attack surface because it wouldn't trust anything by default, the opposite of the way things are now.
Instead of deploying a new hardware stack, isn't it better to just fix the software stack we already have?
The whole operating system doesn't need formal verification, just the kernel. If it does its job, then there is no point at which a rootkit will be given access to the underlying hardware, and thus it won't be installed.
As I pointed out less than 24 hours ago in response to a similar story... (mods in brackets)
I keep watch on "security" threads like this one, hoping to find sanity in at least one answer prior to mine.... and keep getting disappointed.
You're all wrong, so far. [Well, all but about 5 of you... progress is being made]
Why? It's simple, it's not a [Trusted Platform / Virus scanning] issue, it's an Operating System design issue.
The default permit environment present in everything except IBM's VM is the root cause of 99% of our problems. [Yes, including this one, trusting something not to install a rootkit once it gets past the virus scanner]
Instead of giving each PROCESS a list of resources and permissions, Linux, OS-X, Windows, and pretty much everything else, does it at the USER level. (Yes, I know about app-armor, but that's a special case[, and isn't dynamic enough to do a proper job of capabilities])
This means that all of the defenses are pointed in the wrong direction. (Imagine building a fort with 10 foot thick perimeter wall as its sole defense in the age of paratroopers and helicopters to get an idea of the scale of the problem). [In this case, they claim to have better walls]
It doesn't matter how careful or professionally trained the application programmers are, nor how safe the programming language used to write the application is, when the OS isn't even designed to limit what they can do. All programs have bugs, you shouldn't have to trust them not to have them.
Now, those skills and language enhancements are useful for building the operating system, especially when constructing the micro-kernel to run everything, so it's not wasted effort. [However... virus scanners are a waste, as we shouldn't need them at all]
I predict we'll see stories like this for at least 10 more years [well... that's #2 in the first 24 hours], regardless of the effort or money put in, because we haven't [corrected] our approach yet. It's going to take a few more years until the cognitive dissonance gets loud enough in peoples heads to prompt them to find a better OS, and a few more years to actually have something reasonably solid available. Until then, buckle up... it's going to be a VERY bumpy ride.
Cross-site data leakage IS a problem, of course...
One of the good design ideas that comes up when describing or building capability based security is the idea of moving file dialogs OUTSIDE of the control of the application. If done properly, the user might not even notice the difference, which is a very good thing.
If we move the selection of web sites outside the control of the browser in the same fashion, you could then add facilities to filter, log, proxy, etc... without the need to do anything different in the rendering part of the browser. Most of the code for a port to a capability system would survive intact, it's only the source dialog boxes and linking behavior that would have to be tweaked.
If you have a browser that works in a capability system, you would drop a connection to the web site into it, that connection could be restricted in any arbitrary number of ways by the OS, and by other helper filters it pipes through.
Thanks for giving me a different viewpoint to consider... you've covered a lot of ground in that write-up.
I like the idea of giving access to write to an email address as a privilege supplied to a program, instead of letting it just spam the world.
I'd to the same thing when it came to reading from a website, perhaps filtering to the domain *.slashdot.org, for example. If the user wanted to follow a link outside the domain, they would have to drag/drop the link into something outside the browser's control to get authorization, and continue. Letting the user set up a double-click shortcut way of doing links would make it close enough to browsing as it's done now to be acceptable.
I'll be reading this a few times to really let it sink in... thanks so much!
Well, the damage is limited to that specific machine, unless there are connections between the VMs. The principle of least privilege is a very powerful firewall if used correctly.
All operating systems should serve as a supervisor for the tasks running, that's why there are more than 2 rings of privilege in most CPUs. I'll go so far as to predict that eventually Linus will end up moving Linux to a micro-kernel system, but that's about 20 years from now.
The reason VMware and other virtualization is so popular right now is because it effectively does what the OS lacks... protecting things from damage. Instead of having multiple applications on a server, you just spool up a new server for each new application. It's darned close to the IBM VM model, all over again.
The reason things like CapROS haven't caught on is inertia... it's a huge pain in the ass to move things to a different desktop, let alone a completely different operating system, where you have to rewrite things, and adjust to a whole new set of annoyances.
The IBM VM model of things is a pure capability model, you give RAM, DISK, and I/O to a virtual machine, and it can't exceed it's authority. Of course the granularity is a bit rough when you have to do it in terms of disk systems instead of specific files, folders, etc. The need to have a system admin set things up, which isn't very user friendly either, so it's clearly not the exact way things will end up when capabilities go mainstream.
I see the easiest way as looking just like Windows, Linux, etc... except the shortcut to an application also includes a list of files, resources, quotas, etc... this would allow things like Accounting Applications which can't access the internet (unless you change their settings), etc.
Eventually, people will figure it out, but it's going to be a LONG wait. In the meanwhile, the insecurity of everything will get used to sell a lot of software, firewalls, etc... and the worst part is it offers the perfect excuse for filtering and censoring the internet.
I'm glad to see you here... now there are at least 2 of us.;-)
I keep watch on "security" threads like this one, hoping to find sanity in at least one answer prior to mine.... and keep getting disappointed.
You're all wrong, so far.
Why? It's simple, it's not an application programming issue, it's an Operating System design issue.
The default permit environment present in everything except IBM's VM is the root cause of 99% of our problems.
Instead of giving each PROCESS a list of resources and permissions, Linux, OS-X, Windows, and pretty much everything else, does it at the USER level. (Yes, I know about app-armor, but that's a special case)
This means that all of the defenses are pointed in the wrong direction. (Imagine building a fort with 10 foot thick perimeter wall as its sole defense in the age of paratroopers and helicopters to get an idea of the scale of the problem).
It doesn't matter how careful or professionally trained the application programmers are, nor how safe the programming language used to write the application is, when the OS isn't even designed to limit what they can do. All programs have bugs, you shouldn't have to trust them not to have them.
Now, those skills and language enhancements are useful for building the operating system, especially when constructing the micro-kernel to run everything, so it's not wasted effort.
I predict we'll see stories like this for at least 10 more years, regardless of the effort or money put in, because we haven't changed our approach yet. It's going to take a few more years until the cognitive dissonance gets loud enough in peoples heads to prompt them to find a better OS, and a few more years to actually have something reasonably solid available. Until then, buckle up... it's going to be a VERY bumpy ride.
Slashdot Mirror
Here are my definitions of the words:
Lately I've had to frequently correct my 5 year old daughter on this point. I tell her that if you don't use your words in the same way everyone else does, they will decide that you don't know what you're talking about, and stop listening to you.
For any given -ism, there is a compulsory submission to the philosophy, otherwise it's not universal, and it falls apart. This is true even for technologism.
There is no inherently good or bad philosophy in most of those, it's the implementation details that make or break it.
The main difference between the Soviet Union and the US is that we were better at debasing our currency without anyone noticing, and living on credit. Our standard of living has been in a steady decline since the late 1960s
The main difference between the US and China today is that China has forward thinking oligarchs, whereas ours sold us out to them starting in the 1970s. That's why they manufacture things (albeit in a very environmentally unfriendly way), and we don't. We can't make all the parts for our own weapons systems any more.
The Soviet Union eventually collapsed.... whereas we haven't, yet
You're correct... and nobody things that hosts can be secure, because our current conception of security is that it makes something unusable. It doesn't have to be that way, and I've pointed that out many times, but preaching about capability based security to this choir just doesn't work.
The real question would be then, does the City of London want it, or not?
The big problem with files is that they get disconnected from context far too easily, especially when you share them with others. This realization is why I want to build the inter-tubes protocol. It syncs up collections of files, deals with permissions, and makes a set of services available to get thumbnails of photos, etc
My use case goes like this:
I have 330,000 photos I've taken in the last 14 years. I'd like to share them. The current choices are
What I'd like to do instead is to give them a small file which contains permissions to access my tube containing my photos. It would be a very small file, with just a few cryptographic signatures, probably less than 20k. However, this would then allow the user to list all of my photos, and use the thumbnail service associated with it to pull across thumbnails of things (instead of the full size images).
If they then find a file they like, the can get the full size version. If they then add tags or comments to the file, those would get synced back to me via the tubes.
What do you all think of this idea?
It occurs to me that Perl is just the web replacing the gap left by Teco.
It's interesting that a law about IP never mentions blocking IP, only blocking DNS. It also assumes that the registration process doesn't change much.
If one were to use an alternative DNS, this whole thing becomes irrelevant.
When I saw the camera array focus through the bushes behind their subject... I was hooked. However I didn't have the budget, so I started experimenting with 1 camera and many shots from a small area... if you have stationary subjects, you can do the refocusing with a single camera and a lot of time....
Here are some photos of Chicago in synthetic focus as an example.
I would love to be able to build a portable 64 camera array.
I love this thread... it is insane to try to keep a system like this designed for a few clients in the 1950s and 1960s alive when it has scaled to a significant fraction of the planet's population. Cryptography would be a great leap forward, but even a few simple things could make it much better like having a website for each of the major CC/Debt card vendors where you can have them generate a new random large number for handing off (via cut/paste, or whatever) to a vendor, which gives them a claim for x dollars from your account... once, or whatever schedule/limits you set.... and would only work for their account, nobody elses.
Even if their computers were stolen, the number wouldn't work for anyone else..... and if they tried to screw you, you'd just revoke the capability from your control panel, and they'd never get another cent.
This could be done with 1970's class mainframe hardware... and would require only a few nano-cents worth of storage these days.... yet we get screwed by the IT systems designed in the 1950s.
Argh... we're building weapons systems based on windows or mac or linux? What are these people, nuts?
If there was ever a place where capability based security should be used, this is it. An application that has the ability to literally kill people should not be run in an environment which defaults to permissive... this means that ANY application on that system could potentially kill someone.
With the exception of a few wise souls here and there, nobody else seems to get the idea that this kind of thing can be stopped, dead, in its tracks. (Pun intended)
Capability based security offers a path forward to computers that trust nothing by default... the exact opposite of what we have now. They don't have to be unusable, nor layered with ineffective anti-spyware, anti-malware, etc...
Just stop trusting applications, and specify what they can do, as a maximum extent, before you execute them. This limits the damage a rogue (or just confused) application can incur before it's even run.
Now... I've obviously made some typos and a few things could be made clearer in the above... unfortunately /. doesn't allow editing or clarification of a post after it's written... nor does it offer any voting other than a popularity contest... so let the inefficient commenting begin.
I'd redo the moderating system to be tag oriented... so that a comment could be "funny" and "insightful" and "accurate" and "wise", etc... with each of the tags being given a weight by someone who casts a vote.. The tags would be just any old text, with the most common ones showing up in a list.
If we can then filter based on the tag weights, we could then filter out funny posts, or innacurate ones, or flamebait depending on our mood.
It can be MUCH better... but requires a shift in thinking away from the popularity contest.
... when a radical leftist president starts executing right wing militia people without due process, rush limbaugh will shit a brick. .
Well, constipation is the number one side effect of some things he's been known to take in the past.
Furthermore, when your mom makes toast... she doesn't have to worry about the toaster somehow accessing every previous piece of toast it ever had access to and suddenly sending those atoms to a temperature of 10000 degrees.... it's obvious when you have a toaster running what the inputs and outputs are.
Does your toaster automatically attach itself to bread as an option? - Computers are different beasts, and analogies don't always apply.... be careful.
When your mom buys a toaster, she doesn't have to wire it directly in to the house. She doesn't have to worry that plugging it in will cause the entire town to go into blackout. She doesn't have to worry that the toaster will somehow send all the money in her purse to a hacker group in Anchorage... why is that?
The outlets are generic and standardized, and protected by an operating environment which prevents the devices attached from consuming excess current.
The capability to draw up to 15 amps is a separate and distinct capability from the physical possession of a purse.
Even though she has all of those things, she knows better than to try to put her purse into the toaster.
Furthermore, she chooses exactly what food items to put into the toaster.... she's never mistakenly put the goldfish into the toaster... nor would she.
Note that none of this requires detailed knowledge of how toaster internals work... in the same way that users shouldn't have to know about application internals.
Choosing what goes into what appliance isn't rocket science... and to imply that a user can't make such decisions just because they happen to be managed inside a computer is insulting to the users, and incorrectly focuses the attention of those seeking to make things better.
No... it's not... SE Linux and App Armour enforce static rules.... not dynamic ones decided by users. However... it is a step in the right direction.
The responsibility for preventing security problems with PCs should strictly fall into 2 places, the User, and the OS.... however... not the way 99.99% of you are thinking about it.
The user should decide what resources a program NEEDS in order to do a task, such as which folder it can access, what network connections, etc. This allows the user to decide ahead of time what they are willing to risk. Once that determination is made, the user then would give that list, along with a pointer to the program, to the operating system.
The OS should then enforce the users choices.... if it's not in the list, the application shouldn't even be able to find it, let alone access it. If the OS fails to enforce the users will, then the OS is at fault.... if the User gave away the store, well... they gave away the store.
This requires a simple change to the base design of operating systems, instead of permitting everything, and limiting actions of a running program to that of the user's account... the OS should limit the actions of the program to a short list of resources supplied by the user... and nothing else. Of course, the refactoring of everything to add this additional layer of logic is a massive undertaking.
There would still be the traditional user rights, access control lists, etc.... but there would also be a level of control where the user decides which of the resources they have should be given to the application. This is called "capability based security", or cabsec for short.
It's going to take somewhere between 10 and 15 years before people are fed up enough to make the switch.... but it will happen eventually.
Security isn't an application issue... it never was, and never will be.
The only thing that MUST be verified is the OS kernel, the rest can be dealt with as untrusted code. L4 is at this stage.
If your disk driver isn't formally verified, it can overwrite the boot sector.
If your file system driver isn't formally verified, it can modify the operating system files.
The OS doesn't have to trust the boot sector, it can verify the information using cryptographic signatures. If you treat the block devices as untrusted, you will do things like using checksums, CRCs, ECC, etc... don't forget that hard drives typically get 1 out of 10^15 blocks wrong in the normal course of doing business.
You can also encrypt/sign the drivers so the OS can check for modifications, should a rootkit be present.
Since an untrusted file system driver would have to use the OS to read / write the block devices, you could present it with a read-only capability to the block device which contains the OS, stopping all modification. In the case of a need for an update, the OS could then use a read/write capability to do the update, and switch back when done. I'm sure someone with a good background in CS could figure out a more secure way of doing it.
If your video driver isn't formally verified, it can overwrite any location in memory.
Not if the memory management is working correctly... Windows NT 3.5 and earlier had video running outside the kernel... which is the right way to do things in terms of security.
If your (insert just about anything here) driver that supports DMA isn't formally verified, it can also overwrite any location in memory.
Drivers don't have to run in kernel mode to be efficient, and the DMA doesn't have to be set up directly by the drivers. The MMU and the control over input parameters to the DMA/Interrupt subsystems should suffice here as well.
If your BIOS flashing driver isn't formally verified, the next time you boot you have a rootkit.
True, but to have a rootkit, it has to be installed at some point, which a secure OS would prevent.
On the other hand, if your threat model includes nation states, you can't stop rootkits installed using physical access to the hardware, if they have enough time... even a checksum bios could be subverted with the right hardware between the motherboard and storage.
Either way, attempting to detect faults and fouls should be a normal part of the boot process.
If your window manager/login prompt/other common OS programs aren't formally verified, they will allow privilege escalation.
Yes, they MIGHT allow privilege escalation, especially if they aren't well constructed and fairly transparent in their operation to the user. The key is to provide an easy to use facility for specification of exactly what permissions are to be given to a program. This needs some work, the first few widely used iterations will be a bit rough around the edges, but after some use and tweaking, it should be pretty easy to do. This results in a secure, efficient Operating System, with no need to trust any program.
The primary reason we even worry about root kits is that Operating Systems haven't been designed to work in a world of untrusted code. Changing that one aspect of things, doing a hell of a lot of coding to build a capability based OS, provides an environment in which it is very unlikely that any rootkit would get the opportunity to be installed.
Kernels can be replaced in real time, it's been done in Linux.
Something in hardware (which is implied in this new technology) has to be updateable in order to resist threats over time. It too will have the same critical points as any system which doesn't trust the code running on it.
A capabilities based operating system would have about the same attack surface because it wouldn't trust anything by default, the opposite of the way things are now.
Instead of deploying a new hardware stack, isn't it better to just fix the software stack we already have?
The whole operating system doesn't need formal verification, just the kernel. If it does its job, then there is no point at which a rootkit will be given access to the underlying hardware, and thus it won't be installed.
As I pointed out less than 24 hours ago in response to a similar story... (mods in brackets)
I keep watch on "security" threads like this one, hoping to find sanity in at least one answer prior to mine.... and keep getting disappointed.
You're all wrong, so far. [Well, all but about 5 of you... progress is being made]
Why? It's simple, it's not a [Trusted Platform / Virus scanning] issue, it's an Operating System design issue.
The default permit environment present in everything except IBM's VM is the root cause of 99% of our problems. [Yes, including this one, trusting something not to install a rootkit once it gets past the virus scanner]
Instead of giving each PROCESS a list of resources and permissions, Linux, OS-X, Windows, and pretty much everything else, does it at the USER level. (Yes, I know about app-armor, but that's a special case[, and isn't dynamic enough to do a proper job of capabilities])
This means that all of the defenses are pointed in the wrong direction. (Imagine building a fort with 10 foot thick perimeter wall as its sole defense in the age of paratroopers and helicopters to get an idea of the scale of the problem). [In this case, they claim to have better walls]
It doesn't matter how careful or professionally trained the application programmers are, nor how safe the programming language used to write the application is, when the OS isn't even designed to limit what they can do. All programs have bugs, you shouldn't have to trust them not to have them.
Now, those skills and language enhancements are useful for building the operating system, especially when constructing the micro-kernel to run everything, so it's not wasted effort. [However... virus scanners are a waste, as we shouldn't need them at all]
I predict we'll see stories like this for at least 10 more years [well... that's #2 in the first 24 hours], regardless of the effort or money put in, because we haven't [corrected] our approach yet. It's going to take a few more years until the cognitive dissonance gets loud enough in peoples heads to prompt them to find a better OS, and a few more years to actually have something reasonably solid available. Until then, buckle up... it's going to be a VERY bumpy ride.
Cross-site data leakage IS a problem, of course...
One of the good design ideas that comes up when describing or building capability based security is the idea of moving file dialogs OUTSIDE of the control of the application. If done properly, the user might not even notice the difference, which is a very good thing.
If we move the selection of web sites outside the control of the browser in the same fashion, you could then add facilities to filter, log, proxy, etc... without the need to do anything different in the rendering part of the browser. Most of the code for a port to a capability system would survive intact, it's only the source dialog boxes and linking behavior that would have to be tweaked.
If you have a browser that works in a capability system, you would drop a connection to the web site into it, that connection could be restricted in any arbitrary number of ways by the OS, and by other helper filters it pipes through.
Thanks for giving me a different viewpoint to consider... you've covered a lot of ground in that write-up.
I like the idea of giving access to write to an email address as a privilege supplied to a program, instead of letting it just spam the world.
I'd to the same thing when it came to reading from a website, perhaps filtering to the domain *.slashdot.org, for example. If the user wanted to follow a link outside the domain, they would have to drag/drop the link into something outside the browser's control to get authorization, and continue. Letting the user set up a double-click shortcut way of doing links would make it close enough to browsing as it's done now to be acceptable.
I'll be reading this a few times to really let it sink in... thanks so much!
Well, the damage is limited to that specific machine, unless there are connections between the VMs. The principle of least privilege is a very powerful firewall if used correctly.
All operating systems should serve as a supervisor for the tasks running, that's why there are more than 2 rings of privilege in most CPUs. I'll go so far as to predict that eventually Linus will end up moving Linux to a micro-kernel system, but that's about 20 years from now.
The reason VMware and other virtualization is so popular right now is because it effectively does what the OS lacks... protecting things from damage. Instead of having multiple applications on a server, you just spool up a new server for each new application. It's darned close to the IBM VM model, all over again.
The reason things like CapROS haven't caught on is inertia... it's a huge pain in the ass to move things to a different desktop, let alone a completely different operating system, where you have to rewrite things, and adjust to a whole new set of annoyances.
The IBM VM model of things is a pure capability model, you give RAM, DISK, and I/O to a virtual machine, and it can't exceed it's authority. Of course the granularity is a bit rough when you have to do it in terms of disk systems instead of specific files, folders, etc. The need to have a system admin set things up, which isn't very user friendly either, so it's clearly not the exact way things will end up when capabilities go mainstream.
I see the easiest way as looking just like Windows, Linux, etc... except the shortcut to an application also includes a list of files, resources, quotas, etc... this would allow things like Accounting Applications which can't access the internet (unless you change their settings), etc.
Eventually, people will figure it out, but it's going to be a LONG wait. In the meanwhile, the insecurity of everything will get used to sell a lot of software, firewalls, etc... and the worst part is it offers the perfect excuse for filtering and censoring the internet.
I'm glad to see you here... now there are at least 2 of us. ;-)
I keep watch on "security" threads like this one, hoping to find sanity in at least one answer prior to mine.... and keep getting disappointed.
You're all wrong, so far.
Why? It's simple, it's not an application programming issue, it's an Operating System design issue.
The default permit environment present in everything except IBM's VM is the root cause of 99% of our problems.
Instead of giving each PROCESS a list of resources and permissions, Linux, OS-X, Windows, and pretty much everything else, does it at the USER level. (Yes, I know about app-armor, but that's a special case)
This means that all of the defenses are pointed in the wrong direction. (Imagine building a fort with 10 foot thick perimeter wall as its sole defense in the age of paratroopers and helicopters to get an idea of the scale of the problem).
It doesn't matter how careful or professionally trained the application programmers are, nor how safe the programming language used to write the application is, when the OS isn't even designed to limit what they can do. All programs have bugs, you shouldn't have to trust them not to have them.
Now, those skills and language enhancements are useful for building the operating system, especially when constructing the micro-kernel to run everything, so it's not wasted effort.
I predict we'll see stories like this for at least 10 more years, regardless of the effort or money put in, because we haven't changed our approach yet. It's going to take a few more years until the cognitive dissonance gets loud enough in peoples heads to prompt them to find a better OS, and a few more years to actually have something reasonably solid available. Until then, buckle up... it's going to be a VERY bumpy ride.