Slashdot Mirror
Security is an Important Coding Consideration Even When You Use Containers (Video)
Last month Tom Henderson wrote an article titled Container wars: Rocket vs. Odin vs. Docker. In that article he said, "All three are potentially very useful and also potentially very dangerous compared to traditional hypervisor and VM combinations."
Tom's list of contributions at Network World show you that he's not a neophyte when it comes to enterprise-level security, and that he's more of a product test/analytical person than a journalist. And afraid to state a strong opinion? That's someone else, not Tom, who got flamed hard for his "Container Wars" article, but has been proved right since it ran. Tom also says, in today's interview, that the recent Apple XcodeGhost breach should be a loud wake-up call for developers who don't worry enough about security. But will it? He's not too sure. Are you?
Tom's list of contributions at Network World show you that he's not a neophyte when it comes to enterprise-level security, and that he's more of a product test/analytical person than a journalist. And afraid to state a strong opinion? That's someone else, not Tom, who got flamed hard for his "Container Wars" article, but has been proved right since it ran. Tom also says, in today's interview, that the recent Apple XcodeGhost breach should be a loud wake-up call for developers who don't worry enough about security. But will it? He's not too sure. Are you?
Containers are even more dangerous than VMs since you lose even more virtualization. All these technologies sit on a spectrum of resource-cost-to-containment with the hardest containment being a different physical machine. Even process isolation yields some amount of containment (can't snoop cross-process memory) but this is typically trivial to breach for any malware.
A large part of the security problem can be solved with simple configuration cleanliness. Do you know what software you're running? If you don't then no amount of containment will help and it's just a matter of time before your network is pwned.
NT
There are 11 types of developers when it comes to security.
00) Wot? 70% of them. Probably 95% of web designers.
01) I care about security, but I don't have to do anything about it in my layer. Another 20%.
10) I care about security and it is my problem. Just 10%. Maybe.
This guy is preaching to group 10 and trying to get group 01 to care. It's nice to see something else out there fighting the good fight.
There are too many new developers coming in. The older guys may know how to write secure code, but then you have a bunch of new people and they have to learn the lessons of security all over again.
There is no "magic bullet." Garbage collection won't save you, a container won't save you. In the end, you need to be thinking about security every line you write, or you'll end up with an integer overflow that allows hackers to take over your container.
"First they came for the slanderers and i said nothing."
Containers are even less separate than jails, of course they're near the bottom of the barrel in terms of security. Why the Container fad when the overhead of proper virtualization is now so very low it's negligible on any modern server processor?
never use gotos,
There's nothing wrong with GOTO statements, and there never was. This is a rather popular misconception.
Sixth, never ever use exception handlers. You have a non-deterministic path through the program and therefore no means of knowing if the state of the program is valid. You also want the program to crash if it encounters a situation that it shouldn't, it means there's a catastrophic fault in the machine or the software. There are no exceptions to this rule. Exception handling is one of the worst mistakes ever made in software engineering.
Oh, so you're trolling.
The majority of developers are complete fucktards when it comes to best practices for secure development. The shit I've seen so-called "expert" developers do ... man, the whole DevOps thing gives me nightmares. The *last* thing the world needs is more developers in control of production environments...
How is exception handling non-deterministic?
At any point, you can easily tell where the exception will get handled, or if it will not, which will cause it to crash.
In C, you can completely ignore an error code and your program won't crash, in most cases, if you don't.
Just crashing is stupid. You need to log where the error happened and what state it was in at the time.
Function calls, conditionals, loops, continue and break are all goto's.
Depending on the language/compiler a warning is sometimes impossible to get rid of and yes, there are warnings you need to heed and others that cause no ill harm.
You aren't even a good troll.
The rest of you are helpless on computers minus devs making tools you merely USE, user.
GOTO...a popular misconception that actually gained traction, unfortunately. There are good times to use GOTO but they'll never work in my organization because "scary". Exception handlers usually get panned because of their typically poor performance and difficulty to control in C++ (also their tendency to skirt past legacy malloc/free code and leak horribly). For any good modern C++11 or C++14 code these are usually moot points because you're using unique_ptr or something and such leaks can't exist with RAII semantics like that. Performance points are probably moot based on the observation that some of these places will soap-box the exceptions to death and then proceed to write O(n^4) algorithms anyway (how's that performance working out for ya?). Still, the lobby for good old fashioned "if (!blah()) return false;" is still large and we'll be dealing with it for quite a while yet.
Given that xcode is free (as in comes with OS X), why would you get it from a source other than Apple?
linquendum tondere
There are always bugs. These can be used to break out of the container. For 25+ yrs, people have been trying to secure the base OS. Since the late 1990s, VMware has been trying to secure their VMs. Since 2005-ish - Linux containers have been trying to be secure.
None of them has succeeded, but the length of time directly correlates with the security provided. At this point, and until 2020, I wouldn't deploy any container on an internet facing system. They have uses - for development teams and internal production systems only. There is simply too much risk with Linux containers today for other use to be considered.
Solaris containers are different and have 5 more years of effort. They are 'safe enough' - IMHO.
That is only true if you categorise anyone who writes code as a developer.
Plus with your definition most developers are also only user since they only use tools developed by someone else without whom they would be unable to develop the tool to develop.
http://www.c0t0d0s0.org/archives/3651-Theo-de-Raadt-about-virtualisation.html says it all
This presumes that the instance's NON-INTERNET-FACING side is secure, and don't be so assured that it is.
---- Teach Peace. It's Cheaper Than War.
Is it just me who hates all these stupid sounding technology names?
GoTo statements are like a straight razor. They work just fine in capable hands, meaning they don't get abused. The problem was the abuse which was rampant.
Saying "there's nothing wrong with GOTO statements" is like saying "there's nothing wrong with rocket launchers." It's true only if you ignore the realities of implementation. Technically true but so what?
Security isn't a product. It cannot be introduced by bolting on one specific feature. It cannot be addressed by adding a wrapper. It cannot be implemented by inserting one variable or removing one parameter. It cannot be added with code scanning, static or dynamic analysis, fuzzing, spoofing, QA, UAT, black hats, white hats, pen testing, VMs, containers, or PHBs.
Security is a process. And the longer and more prevalent that process is, the more secure the system is.
Who needs to argument about contributions to show "he's not a neophyte", has other problems. Especially if i needs to think about if he needs security even in containers. i mean, what the fuck.