Yes, it is less secure if "secure"=="verifiably secure". But that's not really a practical way of talking about security. I couldn't disagree more, but maybe we are talking about the same thing.
If you mean Formal Verification as in EAL7 then I agree, that isn't very practical.
But if what you mean is closer to what EAL3 calls "methodically tested", then that is quite practical and very useful. It's also a standardised and accepted way of talking about security.:-)
The concept, called mandatory access control, goes back decades. [...] A few years back, the NSA wrote an implementation of this for Linux. It's called SE Linux. I'm dimly aware of that. I've given some speeches on SELinux back in 2003/2004 and contributed some patches and policies.
Nothing in TFA makes me believe they've done what four years of NSA-supported SELinux development couldn't do: Make SELinux a viable option for a non-SELinux-expert sysadmin or user.
Parts of your reply hurt. Others were great. Allow me to concentrate on the ones that hurt:
* Sandboxing, aka Mandatory Access Controls. Not only have research systems built on this concept existed for years, but we also have a decade of practical experience with Java sandboxes, and several years of extensive experience with MAC on Linux (SELinux). Specialized high-security operating systems have employed MAC for decades.
* Chroot jails. Most sysadmins who are serious about security run all Internet-facing applications in jails, to limit the damage that can be done if the app is exploited. The only difference here is that the concept is being applied to all apps. This might be a language barrier, but "sandboxing" belongs to "chroot jails" conceptually. MAC is something else entirely, and while you can mix it with chroot to built pretty tough jails, it's a different concept. MAC means, in a very rough summary, that all accesses of every kind are checked all the time. It's counter-concept is DAC (discretionary access control), the standard Unix model, where access is checked only at specific points. For example, read access in Unix is checked for when you issue an fopen() call with the r bit set. It's not checked again whenever you read a byte from the file. In MAC, every read() call is also checked.
Jails, sandboxes, chroots, etc. are very useful and not new or special at all. Postfix runs in a chroot environment by default, right here on this Linux box.
* Digital signatures as a way to authorize applications to break out of their constrained (sandboxed and jailed) environments.
* Allowing users to authorize applications to break out of their constrained environments. Any means at all for an application to break out of a jail are playing with fire. You can quote me when the first exploit is in the wild.
* Security by default. The system is secure out of the box. That's just a marketing slogan. I know OpenBSD also uses it, but OpenBSD has years of track record to back it up.
Now, I do agree that OLPC is an incredible project. I do agree that it requires a non-traditional approach to security. I don't think it's the right environment to test a new approach to security. What if there's a horrible failure? Are they going to recall millions of machines?
All that said - I'm willing to bring the popcorn and watch the show.
I figure that means somewhere down the road there will be a court case that decides just how much a software vendor can control-via-license just what customers do with the software they paid for.
Until this system is rolled out and being used, we just don't know if it is better, worse, or about the same as our current security models No, but heuristics tell us that it's worse. Every new security system is worse, because it doesn't yet have the flaws found. Crypto people (who do a similar job to security people, but more professional in almost all cases) consider every new crypot broken until it has sustained some scrutiny from experts and is still standing.
I am a strong supporter of taking the same approach with new security systems: Consider them insecure until the worst bugs have been ironed out.
RTFA. This only protects "against" benign software. Intentionally malicious software has a few hurdles to jump over, but at least the app permission part requires the cooperation of the software in question. In other words: It protects against misbehaving or misappropriated software only.
Plus it's only a matter of time before the first solitaire clone ships with a "request everything available (and not conflicting with their simple limits model)" setting, because the app dev was too lazy to tie things down.
If you want a glance at that, install SELinux in non-enforcing mode and look at the log. You'll be surprised what kinds of system calls and file accesses your simple applications make that they don't really need. Much of that is just routine init stuff from some library they use, and most fails silently and with no trouble if they can't get that port or file lock they request, but still...
Security is a lot like crypto: Designing your own system is a recipe for desaster. Security is hard, and aside from the conceptual stages, small failures in implementation can destroy the best concept.
So anyone coming up with a "new and improved" security concept is selling an untested solution. Because security is always tested in the field, never (at least never properly) in the lab.
And yes, Unix permissions are primitive. But they work, they are reliable and we know their shortcomings and limitations.
I've set up enforcing mode webservers and database servers. I've had my notebook running in enforcing mode back when I was giving talks about SELinux, and put the wireless IP and root password on the board during presentations. But yes, it was tricky to get it running and many of the permissions weren't set as strict as they could've been.
The main project I've always had in mind, but never finished, was VM, just differently from yours: A very locked-down SELinux host machine that runs VMs that are non-SE. Make backups, whack it and replace if the VM gets cracked. Heck, replace it daily just to be sure. As long as your host machine is secure, you have a very controlled damage scenario.
Too much to ask I guess. SELinux allows you to fine-tune permissions to extreme detail, including everything you used as example (or at least the Linux-equivalent, as far as registry, etc. is concerned).
Problem: The complexity isn't for the faint of heart. So no distribution for the general public will actually use it as fine-grained as it allows you to be.
You are being short-sighted and petty. Maybe petty, yes. I doubt the short-sighted part. I don't have the links handy and I'm too lazy to dig them out, but the Gates Foundation has been critized as much as hailed, and there was some evidence for its research and AIDS vaccination "grants" to be veiled investments into pharma companies that Gates holds shares in.
I'm sure his money is doing good things. I'm not sure that the same money in the hands of other people wouldn't be able to do much better things. There are enough people on the ground in Africa who have made a difference with tiny fractions of that budget.
And yes, illegal business practices resulting in monopoly rents aren't theft. They're worse. At least theft is a zero-sum game. Monopoly (in the real world) is a game where the general public loses more than the monopolist gains.
...if Gates replaced his PR person recently? Lots of what he said these past weeks are just so tremendeously unbelievable blunders that it's hard to believe there hasn't been some change. Or maybe he fired his ghostwriter and is actually trying to be a public person all by himself?
I failed to see the part where Gates said that he's only talking to the rich ones and the poor ones are ok with him to copy "his" basic.
Don't be fooled by his foundation. That's a long tradition of robber barons to clear their names in the public eye. It's cheap, too. Steal 50 bio. from everyone, spend 5 bio. for a good cause and suddenly you're a hero.
Welcome to the 21st century, where thanks to the DMCA anything you made can be removed by a simple email from the right lawyer or big-sounding corporation, and you then have to prove that yours actually is yours, before its put online again... maybe.
You, Sir, are probably one in a thousand, likely less. Now put yourself in your doctor's shoes and realize that he has to treat the other 999 just as well. And that you, I and everyone else would look at him funny if he'd say "I don't give flu medicine to people who can't draw the flu virus DNA on the blackboard first".
If 10% of your users have a problem with your interface, that's enough to think about improvements. You knee-jerk reaction isn't one. There are entirely plausible and positive responses. For example, the interface might have been much improved (not only for your 10%, but for others as well, by changing it to:
search for: O song titles O author names
or whatever. That input from your 10th user that you put down is actually valuable feedback. And notice that I didn't suggest a change that makes the interface any less useful for the other 9 users. Almost always you can accomondate the minority without making things more difficult for the majority.
Nope, but what we (the security professionals) expect from users is much more than what doctors expect from patients.
Our equivalent isn't "take these twice a day", but more like "take 17.5 grams of these in equal intervals of precisely 3.45 mayan sun hours using only your left foot." - it makes no sense to the average user and is way too technical and complicated.
Again, see SSL. The principle "yellow lock means things are ok" works. Call it "dumbing down" if you insist, but if you deal with humans, you need to speak to humans.
The system expects people to do things that people do not usually do. How is that not a flaw in design?
The main failure of these "image recognition" systems is that they require the user to react to the absence of information. The lack of something, and especially something familiar, is very rarely even consciously registered, unless you are specifically trained to expect it and react to any change of presence.
Here's an experiment to try at home: Tell your spouse, kids, whoever, to choose one of the decoration items in your home. A vase maybe, or a small picture. Tell them to choose a day at least a month from now (so that you have forgotten) and on that day remove and hide that item. Check how long it takes you to notice that it's missing. Unless it's something of personal importance to you, or something very obvious, chances are it will be a long time before you notice at all. Since that item was part of the landscape for a long time, but had no special "use value" attributed to it, your mind has decided to filter it out of your conscious noticing in order to reduce the amount of information the consciousness has to handle.
The point is that people turn off their brain once told what to do by someone or something that appears to be a source of authority. Nonsense. We ask people to do things we can't expect them to - understand networking security. What we instead should do - and have been failing to for years - is build systems that are actually useable by human beings with little or no special computer knowledge. Or, if that is impossible (and the proof for that is still out!), insist on basic training as a prerequisite for letting people go online, much like a driving license.
Why is SSL accepted and widespread and PGP isn't? Because PGP requires people to deal with things they don't understand like fingerprints, keylengths and all that other technical stuff. SSL doesn't. If there's a yellow lock icon in the status bar, everything is good, otherwise something is wrong. That's the level that normal people deal with and it's not a fault of them.
You and I are the same, in areas we didn't study. What would you think if your doctor required you to understand every medical detail of that operation you need before he does it? You trust him to know his shit, that's what you pay him for, right?
It's time we earn our pay.
And I speak as a professional security guy. "User education" has failed because we tried to bring users to a high level of technical knowledge, instead of bringing the technical knowledge required down to their level.
Phishing attacks work because "security procedures" aren't.
You have formal and informal security. Formal security is long, complicated and tedious. I've yet to see it being used anywhere outside the military. Informal security works for normal people, but it is inherently flawed.
The problem isn't the user. The user is entirely himself. The problem is that we have no way to verify remotely that indeed he is he. All the additional bells and whistles are simply to cover up that simple fact. It's just another level of indirection, see RFC 1925.
He makes the claim that 'security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine.' Is this the windos after Vista? You know, Bill, the "most secure windos ev3r! f0r r34l!".
Security guys break windos every hour or so. There are millions of windos PCs in botnets. They're the #1 reason spam is the problem it is.
Aside from the fact that he is blatantly lying, but then again, the president does that at least once a week, so it's kinda become a part of US media culture, hasn't it?
I draw the line at "paid for". Because otherwise every link I sent to friends to tell them about something cool I found on the web would be "advertisement". In fact, everything you tell anyone about anything would be. So broad a definition can not be useful.
That's why I don't count the Firefox banner on my games login page as advertisement, because I get no money for it. It's simply a fact that Firefox works better than IE (I use transparent.png images, for example, and IE's CSS support is famously broken, google for "box model").
So if you are willing to agree with my definition that advertisement is where someone is paid to say something (usually positive) about some product or company, then I walk the walk. There is no advertisement whatsoever on my game, my private webpage or anything else I send out.
Slashdot Mirror
If you mean Formal Verification as in EAL7 then I agree, that isn't very practical.
But if what you mean is closer to what EAL3 calls "methodically tested", then that is quite practical and very useful. It's also a standardised and accepted way of talking about security.
A few years back, the NSA wrote an implementation of this for Linux. It's called SE Linux. I'm dimly aware of that. I've given some speeches on SELinux back in 2003/2004 and contributed some patches and policies.
Nothing in TFA makes me believe they've done what four years of NSA-supported SELinux development couldn't do: Make SELinux a viable option for a non-SELinux-expert sysadmin or user.
I'll be watching.
* Chroot jails. Most sysadmins who are serious about security run all Internet-facing applications in jails, to limit the damage that can be done if the app is exploited. The only difference here is that the concept is being applied to all apps. This might be a language barrier, but "sandboxing" belongs to "chroot jails" conceptually. MAC is something else entirely, and while you can mix it with chroot to built pretty tough jails, it's a different concept. MAC means, in a very rough summary, that all accesses of every kind are checked all the time. It's counter-concept is DAC (discretionary access control), the standard Unix model, where access is checked only at specific points. For example, read access in Unix is checked for when you issue an fopen() call with the r bit set. It's not checked again whenever you read a byte from the file. In MAC, every read() call is also checked.
Jails, sandboxes, chroots, etc. are very useful and not new or special at all. Postfix runs in a chroot environment by default, right here on this Linux box. * Digital signatures as a way to authorize applications to break out of their constrained (sandboxed and jailed) environments.
* Allowing users to authorize applications to break out of their constrained environments. Any means at all for an application to break out of a jail are playing with fire. You can quote me when the first exploit is in the wild. * Security by default. The system is secure out of the box. That's just a marketing slogan. I know OpenBSD also uses it, but OpenBSD has years of track record to back it up.
Now, I do agree that OLPC is an incredible project. I do agree that it requires a non-traditional approach to security. I don't think it's the right environment to test a new approach to security. What if there's a horrible failure? Are they going to recall millions of machines?
All that said - I'm willing to bring the popcorn and watch the show.
I figure that means somewhere down the road there will be a court case that decides just how much a software vendor can control-via-license just what customers do with the software they paid for.
I am a strong supporter of taking the same approach with new security systems: Consider them insecure until the worst bugs have been ironed out.
RTFA. This only protects "against" benign software. Intentionally malicious software has a few hurdles to jump over, but at least the app permission part requires the cooperation of the software in question. In other words: It protects against misbehaving or misappropriated software only.
Plus it's only a matter of time before the first solitaire clone ships with a "request everything available (and not conflicting with their simple limits model)" setting, because the app dev was too lazy to tie things down.
If you want a glance at that, install SELinux in non-enforcing mode and look at the log. You'll be surprised what kinds of system calls and file accesses your simple applications make that they don't really need. Much of that is just routine init stuff from some library they use, and most fails silently and with no trouble if they can't get that port or file lock they request, but still...
Security is a lot like crypto: Designing your own system is a recipe for desaster. Security is hard, and aside from the conceptual stages, small failures in implementation can destroy the best concept.
So anyone coming up with a "new and improved" security concept is selling an untested solution. Because security is always tested in the field, never (at least never properly) in the lab.
And yes, Unix permissions are primitive. But they work, they are reliable and we know their shortcomings and limitations.
I said it isn't for the faint of heart. :-)
I've set up enforcing mode webservers and database servers. I've had my notebook running in enforcing mode back when I was giving talks about SELinux, and put the wireless IP and root password on the board during presentations. But yes, it was tricky to get it running and many of the permissions weren't set as strict as they could've been.
The main project I've always had in mind, but never finished, was VM, just differently from yours: A very locked-down SELinux host machine that runs VMs that are non-SE. Make backups, whack it and replace if the VM gets cracked. Heck, replace it daily just to be sure. As long as your host machine is secure, you have a very controlled damage scenario.
Problem: The complexity isn't for the faint of heart. So no distribution for the general public will actually use it as fine-grained as it allows you to be.
I'm sure his money is doing good things. I'm not sure that the same money in the hands of other people wouldn't be able to do much better things. There are enough people on the ground in Africa who have made a difference with tiny fractions of that budget.
And yes, illegal business practices resulting in monopoly rents aren't theft. They're worse. At least theft is a zero-sum game. Monopoly (in the real world) is a game where the general public loses more than the monopolist gains.
...if Gates replaced his PR person recently? Lots of what he said these past weeks are just so tremendeously unbelievable blunders that it's hard to believe there hasn't been some change. Or maybe he fired his ghostwriter and is actually trying to be a public person all by himself?
I failed to see the part where Gates said that he's only talking to the rich ones and the poor ones are ok with him to copy "his" basic.
Don't be fooled by his foundation. That's a long tradition of robber barons to clear their names in the public eye. It's cheap, too. Steal 50 bio. from everyone, spend 5 bio. for a good cause and suddenly you're a hero.
Welcome to the 21st century, where thanks to the DMCA anything you made can be removed by a simple email from the right lawyer or big-sounding corporation, and you then have to prove that yours actually is yours, before its put online again... maybe.
Talk about balking up the wrong tree.
Mr. Gorbachev, with all due respect, you should have checked for Gates past before making yourself ridiculous.
You, Sir, are probably one in a thousand, likely less. Now put yourself in your doctor's shoes and realize that he has to treat the other 999 just as well. And that you, I and everyone else would look at him funny if he'd say "I don't give flu medicine to people who can't draw the flu virus DNA on the blackboard first".
That's the point.
If 10% of your users have a problem with your interface, that's enough to think about improvements. You knee-jerk reaction isn't one. There are entirely plausible and positive responses. For example, the interface might have been much improved (not only for your 10%, but for others as well, by changing it to:
search for:
O song titles
O author names
or whatever. That input from your 10th user that you put down is actually valuable feedback. And notice that I didn't suggest a change that makes the interface any less useful for the other 9 users. Almost always you can accomondate the minority without making things more difficult for the majority.
Nope, but what we (the security professionals) expect from users is much more than what doctors expect from patients.
Our equivalent isn't "take these twice a day", but more like "take 17.5 grams of these in equal intervals of precisely 3.45 mayan sun hours using only your left foot." - it makes no sense to the average user and is way too technical and complicated.
Again, see SSL. The principle "yellow lock means things are ok" works. Call it "dumbing down" if you insist, but if you deal with humans, you need to speak to humans.
I know that experiment. I also know how well-known it is and I expect a study done by two respectable universities to take its effects into account.
The system expects people to do things that people do not usually do. How is that not a flaw in design?
The main failure of these "image recognition" systems is that they require the user to react to the absence of information. The lack of something, and especially something familiar, is very rarely even consciously registered, unless you are specifically trained to expect it and react to any change of presence.
Here's an experiment to try at home: Tell your spouse, kids, whoever, to choose one of the decoration items in your home. A vase maybe, or a small picture. Tell them to choose a day at least a month from now (so that you have forgotten) and on that day remove and hide that item. Check how long it takes you to notice that it's missing.
Unless it's something of personal importance to you, or something very obvious, chances are it will be a long time before you notice at all. Since that item was part of the landscape for a long time, but had no special "use value" attributed to it, your mind has decided to filter it out of your conscious noticing in order to reduce the amount of information the consciousness has to handle.
Rule #1 of user interface design: The user is always right. If he does something wrong, thank him for pointing out a flaw in your interface.
Why is SSL accepted and widespread and PGP isn't? Because PGP requires people to deal with things they don't understand like fingerprints, keylengths and all that other technical stuff. SSL doesn't. If there's a yellow lock icon in the status bar, everything is good, otherwise something is wrong. That's the level that normal people deal with and it's not a fault of them.
You and I are the same, in areas we didn't study. What would you think if your doctor required you to understand every medical detail of that operation you need before he does it? You trust him to know his shit, that's what you pay him for, right?
It's time we earn our pay.
And I speak as a professional security guy. "User education" has failed because we tried to bring users to a high level of technical knowledge, instead of bringing the technical knowledge required down to their level.
Phishing attacks work because "security procedures" aren't.
You have formal and informal security. Formal security is long, complicated and tedious. I've yet to see it being used anywhere outside the military. Informal security works for normal people, but it is inherently flawed.
The problem isn't the user. The user is entirely himself. The problem is that we have no way to verify remotely that indeed he is he. All the additional bells and whistles are simply to cover up that simple fact. It's just another level of indirection, see RFC 1925.
Security guys break windos every hour or so. There are millions of windos PCs in botnets. They're the #1 reason spam is the problem it is.
Aside from the fact that he is blatantly lying, but then again, the president does that at least once a week, so it's kinda become a part of US media culture, hasn't it?
Good point, yes.
.png images, for example, and IE's CSS support is famously broken, google for "box model").
I draw the line at "paid for". Because otherwise every link I sent to friends to tell them about something cool I found on the web would be "advertisement". In fact, everything you tell anyone about anything would be. So broad a definition can not be useful.
That's why I don't count the Firefox banner on my games login page as advertisement, because I get no money for it. It's simply a fact that Firefox works better than IE (I use transparent
So if you are willing to agree with my definition that advertisement is where someone is paid to say something (usually positive) about some product or company, then I walk the walk. There is no advertisement whatsoever on my game, my private webpage or anything else I send out.