133 karma · joined December 30, 2010
Except that: containers share the same kernel. If a contained application is hijacked with a privilege escalation vulnerability, all running containers and the host are compromised. Also, several resources are not namespaced. Nothing with a shared kernel is going to be very secure.
Malicious container can easily compromise a vulnerable host OS, and an already compromised host OS completely owns the container. This is no different from the failed experiments in sandboxing on PCs.
Can your container share a Linux instance with containers from other customers in the cloud? Not with any confidence, no. Containers do not contain: http://opensource.com/business/14/7/docker-security-selinux
Mr Büker calls for NATO to abandon its "nuclear sharing" agreement, which allows for nuclear weapons to be deployed in Europe. Really? Should we just ignore the Russian threat? It is known that Russia's military doctrine supports pre-emptive/first-use nuclear strike strategy, and recently it has warned that it could resort to use of nuclear weapons if Ukraine tries to retake Crimea[2].
Hope is expressed, but no explaination has been given on how nuclear non-proliferation can be achieved, in practical terms. This is a game-theory problem. Why would you give up your nukes first?
Lest we forget, "Ukraine was once the third-largest nuclear power[3]. In 1994, Ukraine performed a remarkably peaceful act, an act which no other state has since done, nor which any nation will henceforth undertake in the future. It gave-up its nuclear weapons in order to secure its sovereignty, its borders, and its freedom. In return, Ukraine was promised recognition and respect for its borders. Instead, Ukraine has now been made to pay for its naïveté. Those states which now possess or seek to acquire nuclear weapons will take their lead from Ukraine's folly and they will hold-on, fastidiously, to their own nuclear threats and ambitions until they are taken from them by force alone. Until the Ukrainian nation is made whole, all others will know that those bold promises made two decades ago were simply worthless and foolhardy."
--
[1] "Western nations view Russian bellicosity and belligerence as having markedly increased as of late, with tests of new nuclear-capable missiles occurring on a regular basis, military conflicts with neighboring states, claims of a Russian "sphere of influence" on the perimeter of the old Soviet Union, the rise of ultra-nationalist "Putin Youth" groups, aggressive politicization of and threats of withdrawal of natural gas supplies to Europe should the Europeans not make certain policy concessions, and even threats of a nuclear first strike against Poland have been heard to be made by certain Russian generals." Source: http://en.wikipedia.org/wiki/Pre-emptive_nuclear_strike
[2] http://thediplomat.com/2014/07/russia-threatens-nuclear-stri...
[3] http://www.kyivpost.com/opinion/op-ed/john-f-hall-jr-364916....
Yes.
"We will map your social graph, compromise every computer and smartphone in your country"
https://www.youtube.com/watch?v=Mu9puGKfdZE
He is a long-time proponent of export controls for cryptography and government mandated escrow-keys. In 1994, he wrote an article for Wired Magazine titled: "Don't Worry Be Happy: Why Clipper Is Good For You". This guy is a cryptowars veteran.
So, in a sense--you're right, he's not incompetent. Rather, he is a professional ideologue: making the case against privacy rights that crypto-tech enables. If you have experience with KGB "agitprop" and "active measures", you'll be very familiar with the techniques that these sort of people employ for their cause. We should promptly react to his demagoguery by showing it for what it is--sophistry.
They got away with customer data and who-knows-what-else. I'm pretty sure JP Morgan has a bigger cyber-security budged than the whole state of Estonia, many times over. And then check the laundry list of these: http://cybercampaigns.net/
The basic truth is: we still don't quite know how to design digital information systems that can resist attacks from very persistent or nation state level actors. Even if these are air-gaped (as demonstrated by Stuxnet).
E-future cannot be built if we don't fix serious issues with software engineering. There is no guarantee of security. There is no assurance. We basically don't know how to build secure systems yet. As daily events show (from #fappening, #shellshock to Snowden's revelations), this is one of those "hard", unresolved problems...and not just from algorithmic (non-repudiation) perspective, but also from a practical engineering perspective (we are still dealing with buffer overflows).
“The software security industry today is at about the same stage as the auto industry was in 1930" ... "it looks fast, goes nice but in an accident you die.” ... "The major shortfall is absence of assurance (or safety) mechanisms in software. If my car crashed as often as my computer does, I would be dead by now.” -- Brian Snow, Former Technical Director of the NSA, We Need Assurance http://www.research.att.com/talks_and_events/2008_distinguis....
"He beckons me over to one of his eight computers and presses several keys, activating Blockfinder. In less than 30 seconds, the program lists all of the Internet Protocol address allocations in the world — potentially giving him access to every computer connected to the Internet. Appelbaum decides to home in on Burma, a small country with one of the world's most repressive regimes. He types in Burma's two-letter country code: "mm," for Myanmar. Blockfinder instantly starts to spit out every IP address in Burma. Blockfinder informs Appelbaum that there are 12,284 IP addresses allocated to Burma, all of them distributed by government-run Internet-service providers. In Burma, as in many countries outside the United States, Internet access runs through the state. Appelbaum taps some keys and attempts to connect to every computer system in Burma. Only 118 of them respond. "That means almost every network in Burma is blocked from the outside world," he says. "All but 118 of them."
These 118 unfiltered computer systems could only belong to organizations and people to whom the government grants unfettered Internet access: trusted politicians, the upper echelons of state-run corporations, intelligence agencies.
"Now this," Appelbaum says, "is the good part."
He selects one of the 118 networks at random and tries to enter it. A window pops up asking for a password. Appelbaum throws back his head and screams with laughter — a gleeful, almost manic trill. The network runs on a router made by Cisco Systems and is riddled with vulnerabilities. Hacking into it will be trivial.
It's impossible to know what's on the other side of the password. The prime minister's personal e-mail account? The network server of the secret police? The military junta's central command? Whatever it is, it could soon be at Appelbaum's fingertips."
You're probably referring to Stephen Watt (a.k.a. "Unix Terrorist"), who wrote the POS sniffer. His friend, Albert Gonzalez, then used it to steal 170 million credit cards from TJ Maxx and other vendors back in 2006-2007.
“The software security industry today is at about the same stage as the auto industry was in 1930" ... "it looks fast, goes nice but in an accident you die.” ... "The major shortfall is absence of assurance (or safety) mechanisms in software. If my car crashed as often as my computer does, I would be dead by now.” -- Brian Snow, Former Technical Director of the NSA, We Need Assurance http://www.research.att.com/talks_and_events/2008_distinguis...
“Most programmers think that getting run-time errors, and then using a debugger to find and fix those errors, is the normal way to program. They aren't aware that many of those errors can be detected by the compiler. And those that are aware, don't necessarily like that, because repairing bugs is challenging, and, well, sorta fun.
You are not giving a programmer good news when you tell him that he'll get fewer bugs, and that he'll have to do less debugging. Basically, we still live in the dark ages of programming, not unlike the time engineers were learning about boiler technology by figuring out why a boiler exploded, scalding people to death (remember the Therac-25?). People will probably have to die in order for "software engineering" to be a true engineering profession, instead of the buzzword that it is today. Sad but true.” -- Mathew Heaney
As someone said here on HN, it took two major disasters for people in the Netherlands to build coastal defence structures. We only seem to learn from disasters.
"What would you like to tell people?
I don’t know… I think I’d like to say only that they should learn to be alone and try to spend as much time as possible by themselves. I think one of the faults of young people today is that they try to come together around events that are noisy, almost aggressive at times. This desire to be together in order to not feel alone is an unfortunate symptom, in my opinion. Every person needs to learn from childhood how to be spend time with oneself. That doesn’t mean he should be lonely, but that he shouldn’t grow bored with himself because people who grow bored in their own company seem to me in danger, from a self-esteem point of view."
http://www.brainpickings.org/index.php/2013/03/13/tarkovsky-...
Alas, there's no way to "follow" on HN.
The above article was published in 2012. They are right on track, all predictions, down to the last detail, have come true in 2014.
Unfortunately, NSA sabotaged IPv6 goal of "encrypting everything by default":
https://en.wikipedia.org/wiki/IPsec#Alleged_NSA_interference
Specifically,
"IPsec was originally required in IPv6 before RFC 6434 made it only a recommendation"
https://en.wikipedia.org/wiki/Default_effect_%28psychology%2...
http://www.examiner.com/article/jimmy-wales-breaks-wikipedia...
That is not, by any measure, careful. That's awful OPSEC, and what got him in the end. He thought Tor to be inconveniently "slow", and used VPN instead.
http://www.al-monitor.com/pulse/tr/contents/articles/busines...
http://arstechnica.com/security/2013/09/fatal-crypto-flaw-in...