"You incorrectly stated that this system is an example of a "meritocracy." The leader of Ubuntu does not have the ability, he has the money to buy the time of people with the ability."
That's your opinion. Mine is that you incorrectly misunderstand "ability" for "technical ability". That Shuttleworth has the ability to make Ubuntu happen is not an opinion but an stated fact since Ubuntu in fact happens because the obvious reason that he has both the intention and the ability (word that comes from "able" not from "technician") to make it happen.
"It is not ability that determines leadership, it's money."
Again you misunderstand "ability" for "technical ability". Leadership becomes determined by... leadership abilities, not the lessen of them is money to make things happen as planned.
"That makes it, by definition, a plutocracy, not a meritocracy."
Not, and not by definition. While it's true that "plutocracy" is (by wikipedia) "...rule by the wealthy, or power provided by wealth" that a needed condition, but not a sufficient one.
The same definition follows with "In a plutocracy, the degree of economic inequality is high while the level of social mobility is low" which is far away for the reality here: Debian is a well-known and respected Linux distribution as it is Ubuntu. They both are in the position they are for their own merits which is the mark of a meritocracy while the abilities used to achieve that similar position are quite different: money and goal on the focus in the case of Ubuntu, volonteer effort and pure technical reasons on the other. *Both* are abilities since they *both* are *able* to push their respective projects to a notable position. Since it's not money the only asset that stablishes or garantees a meritorial position on the Linux world (you have Red Hat or Ubuntu, but you have Debian, Slackware or Arch too) nor it is the main merit even within Ubuntu (are top Ubuntu individuals chosen because of the money wealth they control or, maybe, because they have already demonstrated their value for the project? and remember that quite some of then are current and former Debian Developers themselves).
"Any other points you made on the subject are orthogonal"
Sure they are! Since they are there "just" to support my claim, they must be orthogonal to the subject, yeah, sure.
"I don't care if ubuntu is a plutocracy, I was just calling you on your false statement."
I hear the call; it's only it's not a false statement by any regard. Or are the packages within Ubuntu chosen by the money amount provided by their respective stakeholders?
"Must be a usage of the word "Merit" I was not previously aware of."
So it must be. Even as a general matter, one of the meanings of merit is "Demonstrated ability or achievement": take for granted that money is a great source fo merit because of its "demonstrated ability or achievement".
But regarding open source you can order merits (the ability to reach achievement) this way:
1) Doing it yourself 2) Using your money so others will do it in your regard 3) Taking what you can for free 4) Bemoaning and crying to get nothing but upset people of higher ranks
You see, all this was about people at level 4 doing their labour (moaning) and somebody at level 2 (Shuttleworth) explaining that 2 > 4 and that means that it's he the one that gets to make things happening the way he wants, not them.
Shuttleworth's was not an exercise of dictatorship, as you seem to think, but just a plain explanation of how things happen.
"How broad those tests will become is a very interesting question, obviously no sane parent would want their child to marry a smooth talking, charming, psychopath."
No parent would mark his child to be a sociopath is that means ruining his future.
But on a more to the spot issue, no boss would test to demonstrate his own socipathy nor any minion would ask for his sociopath boss to be tested that way.
"modern data center [...] Oil immersion may or may not be more efficient, but it doesn't seem like it would scale well. In a large data center where some hardware component is failing on a daily basis, because you have tens of thousands of servers"
In a modern, large datacenter you don't repair each failing component; you just redrive your computing load around it.
"Well, it sounds like it would still be faster than a cold boot."
Yes. But it's unsafer too: if the system happens to be compromised prior to the load of the RAM checker (i.e. through boot loader -on a cold boot you can use a different boot loader) bad luck.
Again, even if you can be sure the booting up system is not compromised, of course it should be faster: it will only review some gigs of RAM out of hundreds or even thousands gigs of storage each of them can be hiding unrevealed malware.
And finally, OK, so the RAM is clear of malware that insists on living on RAM at all costs, provided is not clever enough to hide even to kernel-mode code (so probably some malware on kernel modules would be able to trick this defense too). You still need to cope with all the other malware that will happily leave itself to be dumped out, which puts you again on square one with regards of 0-day exploits.
All in all it can be another tool on the belt but provided there's not a single line of code nor any kind of working proof of concept I don't think it deserves a scientific paper: neither novelty nor opening new paths.
"Any program -- good or bad -- that wants to be active in RAM has no choice but to take up some space in RAM. At least one byte, right?"
More news from Captain Obvious Dept.: any program -- good or bad -- that wants to be resilient between cold bootups has not choice but to take up some space in persistent storage. At least one byte, right?
"All we need is the help of an external verifier that knows how much RAM a device we want to protect has, and how fast its processor is. And ways to avoid latency variance when we measure the time to compute the checksum. This tells us a few interesting things. We can guarantee detection of malware. And that includes zero-day attacks and rootkits. We can even guarantee that we will detect malware that infected a device before we installed our detection program. Think about it. Or read more here and here."
What does it add to current solutions? My answer: almost nothing to absolutly nothing.
1) By trashing out everything from RAM you effectlively have disrupted the service so it's no advantage from other stablished disruptive means like... scanning the disk out of a cold boot.
2) By just cleanning RAM you will have only the ability, even if your system is 100% guaranteed, to detect *only* the malware that was in RAM by the time of the scan. A simple script running from cron will be absolutly undetectable unless it happens to be running by the time the scan was scheduled.
3) No, it won't work on already compromised systems: even if it's run from kernel mode the execution space will already be tainted: think about a virtual server and a virtualized box.
4) As I already said, for a system to survive cold boots it needs to go to persistent storage. If I can know what the RAM contents are expected to be I certainly can easilyl know what the HDD (or BIOS EEPROM, or any other persistent storage) should look like too, so I can compare checksums.
5) Oh! but the system used to get a clean checksum can be compromised! So does the system used to provide the RAM space.
So, in the end this system offers absolutly nothing from the "standard" off-line verification scenario: on a home system boot from CD and check the hard disk; on a corporate system boot from PXE and check the hard disk.
But it offers nothing either on the real time field: TPM can offer just the same only in real time so while it only inspects RAM it inspects RAM at every moment, so the moment the malware is trying to get into RAM it's the time it gets revealed.
"In order to doubt whether the government can be "trusted" with this information, you'd need to be able to give us some kind of scenario where/how this information could be ab-/mis-used."
No, he doesn't. It's the other way around.
"My genes are read a million times an hour by all kinds of mechanisms - some part of my own cellular apparatus, some part of external infrastructures like bacteria."
So what? Neither your cellular apparatus no bacteria are mean. And, by the way, your cellular aparatus is *yours* so certainly there would be no privacy concern even if it were concious.
And not a respresentative case till some time passes on. Right now they had a lot of youngsters hacking a lot of separated (micro)projects. Let's see in a few months if this hackaton doesn't become itself a maintenance nightmare, once bugs and design flaws arise.
"I rather notice an increasing trend of throwing money at a problem instead of addressing it properly."
Throwing money at it is the proper way to address the problem because the problem here is not the log entries but the lack of network security knowledge on a company that rely on Internet-facing servers to make a living.
They are critically risking their bussiness by this, so "The Management Consultant's answer" must be "gain that knowledge or affront consequences" and gaining the knowledge is going to involve money (either by hiring a sysadmin, outsourcing the service, educating internal staff...).
The only question still opened is where the sweet spot (how much money in exchange for how much knowledge) is going to be for their case.
"You need to gain some practical experience as to how key-based SSH access actually works. You obviously don't have any."
The point is that I *do* have practical experience on the issue. And as such I've seen attacks directed by the contents of.ssh/known_hosts (that's why the default has come lately to obfuscate its contents) and I know just too many users will use keypairs without password to protect them. Pair the two and, voila! access gained at first try.
"Because stealing RSA/DSA SSH keys is so much more common than dictionary/brute attacks..."
You seem to forget that if you are seeing those attack levels is because of user computers already rooted, so anything on the client's side it's already at the attacker disposal. What do you prefer? Seeing thousands of failed login attempts in your logs or not seeing anything because the attack succeded by taking control of the ssh keys on the client's machine?
"I'd also recommend hiring someone who focuses their efforts on managing the servers and taking care of network security. This job is usually referred to as a system administrator or network administrator. DOH!"
Quite to the point. There's a rising trend on questions like "I'm having problems about X but I prefer being cheap on coping with X, what should I do?". And then there's the rising trend on answering something else than "if you depend on X you'll need to invest on X".
And now, about the problem at hand: your (his) logs attest thousands of *failed* connection attempts through ssh. In the end... so what? Failed attempts are neither worrying nor in your hand to be avoided (changing your ssh port is the most cost effective remediation measure to maintain bots at a distance). Bellovin already stated quite some years ago (not his exact words, but their meaning): do not monitor on the outer side of your firewall if you are not in the position of avoiding the attacks; all you get will be headaches and a ton of meaningless logs to parse (and probably losing important information among the noise). The verily reason for your firewall to be there is already to maintain the attacks as failed attempts anyway. Do monitor from the inner side. In this case, monitor successful logins, not failed ones.
Of course it makes a difference, what you maybe mean is that it doesn't make a difference in any practical (related to the part of the situation you happen to highlight) mean.
You, as a lawyer and knowing the facts, can lay out (what you consider) a better action plan, maybe trying to bargaining a deal instead of pleading for inocence; maybe change your legal strategy; maybe even, rejecting the defense on ethical (and/or practical) grounds.
"And another interesting part of US law...people are presumed innocent until proven guilty. So a lawyer, or anyone else for that matter, "knowing his client is clearly guilty" is an impossibility in itself."
It is not, as it is not the same "knowing somebody to be guilty" to "knowing somebody to be declared guilty". Presumed means exactly that: pre-assumed. It's perfectly possible to know enough about the facts and about the legal system to know somebody is guilty before the trial outcome because then you are not pre-assuming anything: you know.
Justice is blind (for a very good reason), the same is not to be applied to those around her.
"the biggest problem with RAID is that all the drives must be stored in the same physical box."
Because? Say you have a RAID5 with five disks. You make your copy, turn off the system and send each disk to a different continent. Where's the problem?
"And your claims that it is just a pile of crap have no bearing on the issue."
Which in turn can be applied to any other work no matter how crappy is looks to you. I.e.: my photograph of your sculpture. It might seem that making just "click" doesn't merit the name but, hey, it was you not me the one going through that slippery slope (yes: I know what law says but laws might be wrong or even purpouselly evil).
"What about the rights of the person who created the ART of your event?"
They were properly covered by the money I got him in exchange for his services.
"They're also going to have a piss-poor eye, and will likely be late and unprofessional when it comes to delivering the images."
You are using the future tense. I remember you this was two years ago, the one I contracted had a good eye, was professional and came in time. I of course took my references.
"If you treat an artist like they're a tradesman, perhaps you don't really understand the scope of the service"
I fully understand the scope of the *service* and, yes, a wedding photographer is a tradesman no less than a lawyer or a milkman, I hired him for a service and as long as he is under contract the result of his work is my own. Maybe the photographer I hired is more professional than what you think since he had no problem understanding what I was hiring him for, professionally reaching a deal and professionally binding by it.
Slashdot Mirror
"When did I ever use the word "dictatorship?""
"plutocracy" then. Feel better?
"You incorrectly stated that this system is an example of a "meritocracy." The leader of Ubuntu does not have the ability, he has the money to buy the time of people with the ability."
That's your opinion. Mine is that you incorrectly misunderstand "ability" for "technical ability". That Shuttleworth has the ability to make Ubuntu happen is not an opinion but an stated fact since Ubuntu in fact happens because the obvious reason that he has both the intention and the ability (word that comes from "able" not from "technician") to make it happen.
"It is not ability that determines leadership, it's money."
Again you misunderstand "ability" for "technical ability". Leadership becomes determined by... leadership abilities, not the lessen of them is money to make things happen as planned.
"That makes it, by definition, a plutocracy, not a meritocracy."
Not, and not by definition. While it's true that "plutocracy" is (by wikipedia) "...rule by the wealthy, or power provided by wealth" that a needed condition, but not a sufficient one.
The same definition follows with "In a plutocracy, the degree of economic inequality is high while the level of social mobility is low" which is far away for the reality here: Debian is a well-known and respected Linux distribution as it is Ubuntu. They both are in the position they are for their own merits which is the mark of a meritocracy while the abilities used to achieve that similar position are quite different: money and goal on the focus in the case of Ubuntu, volonteer effort and pure technical reasons on the other. *Both* are abilities since they *both* are *able* to push their respective projects to a notable position. Since it's not money the only asset that stablishes or garantees a meritorial position on the Linux world (you have Red Hat or Ubuntu, but you have Debian, Slackware or Arch too) nor it is the main merit even within Ubuntu (are top Ubuntu individuals chosen because of the money wealth they control or, maybe, because they have already demonstrated their value for the project? and remember that quite some of then are current and former Debian Developers themselves).
"Any other points you made on the subject are orthogonal"
Sure they are! Since they are there "just" to support my claim, they must be orthogonal to the subject, yeah, sure.
"I don't care if ubuntu is a plutocracy, I was just calling you on your false statement."
I hear the call; it's only it's not a false statement by any regard. Or are the packages within Ubuntu chosen by the money amount provided by their respective stakeholders?
"Must be a usage of the word "Merit" I was not previously aware of."
So it must be. Even as a general matter, one of the meanings of merit is "Demonstrated ability or achievement": take for granted that money is a great source fo merit because of its "demonstrated ability or achievement".
But regarding open source you can order merits (the ability to reach achievement) this way:
1) Doing it yourself
2) Using your money so others will do it in your regard
3) Taking what you can for free
4) Bemoaning and crying to get nothing but upset people of higher ranks
You see, all this was about people at level 4 doing their labour (moaning) and somebody at level 2 (Shuttleworth) explaining that 2 > 4 and that means that it's he the one that gets to make things happening the way he wants, not them.
Shuttleworth's was not an exercise of dictatorship, as you seem to think, but just a plain explanation of how things happen.
" Shuttleworth may not be able to tell his UI from a hole in the ground, but he's got the money"
Therefore he has the better merits.
QED.
"Well, if that's all there is to it, then it would always be the salesman who climbs the ladder."
As, in fact, it happens.
"How broad those tests will become is a very interesting question, obviously no sane parent would want their child to marry a smooth talking, charming, psychopath."
No parent would mark his child to be a sociopath is that means ruining his future.
But on a more to the spot issue, no boss would test to demonstrate his own socipathy nor any minion would ask for his sociopath boss to be tested that way.
"Open source is communism, not democracy. All are equal, but some are more equal than others :)"
Bullshit. Open Source is meritocracy: the one with better merits gets to stablish what's done.
Of course the most affordable merit is your own time and ability but money will work just as good.
"modern data center [...] Oil immersion may or may not be more efficient, but it doesn't seem like it would scale well. In a large data center where some hardware component is failing on a daily basis, because you have tens of thousands of servers"
In a modern, large datacenter you don't repair each failing component; you just redrive your computing load around it.
"Well, it sounds like it would still be faster than a cold boot."
Yes. But it's unsafer too: if the system happens to be compromised prior to the load of the RAM checker (i.e. through boot loader -on a cold boot you can use a different boot loader) bad luck.
Again, even if you can be sure the booting up system is not compromised, of course it should be faster: it will only review some gigs of RAM out of hundreds or even thousands gigs of storage each of them can be hiding unrevealed malware.
And finally, OK, so the RAM is clear of malware that insists on living on RAM at all costs, provided is not clever enough to hide even to kernel-mode code (so probably some malware on kernel modules would be able to trick this defense too). You still need to cope with all the other malware that will happily leave itself to be dumped out, which puts you again on square one with regards of 0-day exploits.
All in all it can be another tool on the belt but provided there's not a single line of code nor any kind of working proof of concept I don't think it deserves a scientific paper: neither novelty nor opening new paths.
"Still haven't read the article, eh?"
I did. The relevant parts:
"Any program -- good or bad -- that wants to be active in RAM has no choice but to take up some space in RAM. At least one byte, right?"
More news from Captain Obvious Dept.: any program -- good or bad -- that wants to be resilient between cold bootups has not choice but to take up some space in persistent storage. At least one byte, right?
"All we need is the help of an external verifier that knows how much RAM a device we want to protect has, and how fast its processor is. And ways to avoid latency variance when we measure the time to compute the checksum.
This tells us a few interesting things. We can guarantee detection of malware. And that includes zero-day attacks and rootkits. We can even guarantee that we will detect malware that infected a device before we installed our detection program. Think about it. Or read more here and here."
What does it add to current solutions? My answer: almost nothing to absolutly nothing.
1) By trashing out everything from RAM you effectlively have disrupted the service so it's no advantage from other stablished disruptive means like... scanning the disk out of a cold boot.
2) By just cleanning RAM you will have only the ability, even if your system is 100% guaranteed, to detect *only* the malware that was in RAM by the time of the scan. A simple script running from cron will be absolutly undetectable unless it happens to be running by the time the scan was scheduled.
3) No, it won't work on already compromised systems: even if it's run from kernel mode the execution space will already be tainted: think about a virtual server and a virtualized box.
4) As I already said, for a system to survive cold boots it needs to go to persistent storage. If I can know what the RAM contents are expected to be I certainly can easilyl know what the HDD (or BIOS EEPROM, or any other persistent storage) should look like too, so I can compare checksums.
5) Oh! but the system used to get a clean checksum can be compromised! So does the system used to provide the RAM space.
So, in the end this system offers absolutly nothing from the "standard" off-line verification scenario: on a home system boot from CD and check the hard disk; on a corporate system boot from PXE and check the hard disk.
But it offers nothing either on the real time field: TPM can offer just the same only in real time so while it only inspects RAM it inspects RAM at every moment, so the moment the malware is trying to get into RAM it's the time it gets revealed.
"In order to doubt whether the government can be "trusted" with this information, you'd need to be able to give us some kind of scenario where/how this information could be ab-/mis-used."
No, he doesn't. It's the other way around.
"My genes are read a million times an hour by all kinds of mechanisms - some part of my own cellular apparatus, some part of external infrastructures like bacteria."
So what? Neither your cellular apparatus no bacteria are mean. And, by the way, your cellular aparatus is *yours* so certainly there would be no privacy concern even if it were concious.
"You don't get given authority to say what you please, you get given authority to apply policy."
Point being he was the CISO. He is the very one not to apply but to *create* the policy in regards to IT security incidents.
If you don't want somebody to have such power you don't get to create the role.
"Not exactly a representative sample."
And not a respresentative case till some time passes on. Right now they had a lot of youngsters hacking a lot of separated (micro)projects. Let's see in a few months if this hackaton doesn't become itself a maintenance nightmare, once bugs and design flaws arise.
"The moment life is detected else where will once and for end the silly notion of god or religion."
Because?
"I rather notice an increasing trend of throwing money at a problem instead of addressing it properly."
Throwing money at it is the proper way to address the problem because the problem here is not the log entries but the lack of network security knowledge on a company that rely on Internet-facing servers to make a living.
They are critically risking their bussiness by this, so "The Management Consultant's answer" must be "gain that knowledge or affront consequences" and gaining the knowledge is going to involve money (either by hiring a sysadmin, outsourcing the service, educating internal staff...).
The only question still opened is where the sweet spot (how much money in exchange for how much knowledge) is going to be for their case.
"You need to gain some practical experience as to how key-based SSH access actually works. You obviously don't have any."
The point is that I *do* have practical experience on the issue. And as such I've seen attacks directed by the contents of .ssh/known_hosts (that's why the default has come lately to obfuscate its contents) and I know just too many users will use keypairs without password to protect them. Pair the two and, voila! access gained at first try.
"Because stealing RSA/DSA SSH keys is so much more common than dictionary/brute attacks..."
You seem to forget that if you are seeing those attack levels is because of user computers already rooted, so anything on the client's side it's already at the attacker disposal. What do you prefer? Seeing thousands of failed login attempts in your logs or not seeing anything because the attack succeded by taking control of the ssh keys on the client's machine?
"I'd also recommend hiring someone who focuses their efforts on managing the servers and taking care of network security. This job is usually referred to as a system administrator or network administrator. DOH!"
Quite to the point. There's a rising trend on questions like "I'm having problems about X but I prefer being cheap on coping with X, what should I do?". And then there's the rising trend on answering something else than "if you depend on X you'll need to invest on X".
And now, about the problem at hand: your (his) logs attest thousands of *failed* connection attempts through ssh. In the end... so what? Failed attempts are neither worrying nor in your hand to be avoided (changing your ssh port is the most cost effective remediation measure to maintain bots at a distance). Bellovin already stated quite some years ago (not his exact words, but their meaning): do not monitor on the outer side of your firewall if you are not in the position of avoiding the attacks; all you get will be headaches and a ton of meaningless logs to parse (and probably losing important information among the noise). The verily reason for your firewall to be there is already to maintain the attacks as failed attempts anyway. Do monitor from the inner side. In this case, monitor successful logins, not failed ones.
"It doesn't make any difference."
Of course it makes a difference, what you maybe mean is that it doesn't make a difference in any practical (related to the part of the situation you happen to highlight) mean.
You, as a lawyer and knowing the facts, can lay out (what you consider) a better action plan, maybe trying to bargaining a deal instead of pleading for inocence; maybe change your legal strategy; maybe even, rejecting the defense on ethical (and/or practical) grounds.
"And another interesting part of US law...people are presumed innocent until proven guilty. So a lawyer, or anyone else for that matter, "knowing his client is clearly guilty" is an impossibility in itself."
It is not, as it is not the same "knowing somebody to be guilty" to "knowing somebody to be declared guilty". Presumed means exactly that: pre-assumed. It's perfectly possible to know enough about the facts and about the legal system to know somebody is guilty before the trial outcome because then you are not pre-assuming anything: you know.
Justice is blind (for a very good reason), the same is not to be applied to those around her.
"I've gotten as much as 5TB onto a single LTO-4 tape using the regular drive compression."
Regular *drive* compression? I hope you use it for short them backup, not long term storage.
"the biggest problem with RAID is that all the drives must be stored in the same physical box."
Because? Say you have a RAID5 with five disks. You make your copy, turn off the system and send each disk to a different continent. Where's the problem?
"And your claims that it is just a pile of crap have no bearing on the issue."
Which in turn can be applied to any other work no matter how crappy is looks to you. I.e.: my photograph of your sculpture. It might seem that making just "click" doesn't merit the name but, hey, it was you not me the one going through that slippery slope (yes: I know what law says but laws might be wrong or even purpouselly evil).
"If it is an original work of art, clearly the original artist can have a copyright on that work of art."
Apart from rupestric paintings, what's an original work of art is quite a questionable issue.
"you get to make the movie and keep all the profits?"
Disregarding current laws, why exactly not?
"What about the rights of the person who created the ART of your event?"
They were properly covered by the money I got him in exchange for his services.
"They're also going to have a piss-poor eye, and will likely be late and unprofessional when it comes to delivering the images."
You are using the future tense. I remember you this was two years ago, the one I contracted had a good eye, was professional and came in time. I of course took my references.
"If you treat an artist like they're a tradesman, perhaps you don't really understand the scope of the service"
I fully understand the scope of the *service* and, yes, a wedding photographer is a tradesman no less than a lawyer or a milkman, I hired him for a service and as long as he is under contract the result of his work is my own. Maybe the photographer I hired is more professional than what you think since he had no problem understanding what I was hiring him for, professionally reaching a deal and professionally binding by it.