Security is an Important Coding Consideration Even When You Use Containers (Video)

← Back to Stories (view on slashdot.org)

Security is an Important Coding Consideration Even When You Use Containers (Video)

Posted by Roblimo on Wednesday September 23, 2015 @08:40AM from the fun-with-hypervisors dept.

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?

57 comments

Min score:

Reason:

Sort:

The spectrum of virtualization by Anonymous Coward · 2015-09-23 08:52 · Score: 3, Interesting

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.
1. Re:The spectrum of virtualization by phantomfive · 2015-09-23 09:01 · Score: 1
  
  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.
  If you have a server (in a container or whatever), with all your user's passwords going through it.....then it really doesn't matter if the malware can't get out of the container, it can still sniff the passwords as they go through.
  
  --
  "First they came for the slanderers and i said nothing."
2. Re:The spectrum of virtualization by Anonymous Coward · 2015-09-23 09:05 · Score: 1
  
  All these technologies sit on a spectrum of resource-cost-to-containment with the hardest containment being a different physical machine.
  Physical separation opens up an entirely different set of security problems. I can purge and redeploy a few thousand containers before you've got a single physical machine halfway through re-imaging. You've also got to face the fact that security does not live in a bubble. Managing a metric crapload of containers or even full-blown VMs is far, far more efficient (cost and timewise) than managing a metric crapload of physical machines.
  
  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.
  This, though. In rare cases where shitty application code isn't to blame, I've found it's always been some asinine distribution-supplied bullshit that isn't even actually used. But it's installed and running anyway. Oh, and yes, everybody updates. All the time. Except when they don't. Which is pretty much always. Because testing/QA, rolling through dev/staging onto a scheduled production release...
  Meanwhile, uselessshitd is sitting there vulnerable. For absolutely no reason.
  Argh.
3. Re:The spectrum of virtualization by Anonymous Coward · 2015-09-23 10:44 · Score: 0
  
  Containers should be treated as one step above chrooting and one step below virtualization. I wouldn't completely toss Docker as a tool like the people at boycottdocker.org have done, but I would view it as limited, and combine it with virtualization, similar to how AIX machines have LPARs (VMs) with WPARs (app partitions). There are other containerization players, but with the impetus given by Microsoft, Docker is the leading one as of now.
  Security now is OK with no major breaks... but Microsoft probably addresses it in the best way possible. It gives the option of just running a container, running the container in a Hyper-V VM, or running a container in a VM with a very scaled down OS.
  The best of all worlds is to use both virtualization and containerization.
4. Re:The spectrum of virtualization by Anonymous Coward · 2015-09-23 11:12 · Score: 0
  
  Yes. There are some docker solutions using KVM+Docker or Docker+KVM
-1 Registration Required by Luthair · 2015-09-23 08:54 · Score: 1

NT
There are 11 types of developers... by xxxJonBoyxxx · 2015-09-23 08:58 · Score: 2

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.
1. Re:There are 11 types of developers... by Anonymous Coward · 2015-09-23 09:12 · Score: 0
  
  100) If the security guys can't get it right, then I'm certainly not going to be able too either, so I'm not going to bother with it.
2. Re:There are 11 types of developers... by Anonymous Coward · 2015-09-23 09:28 · Score: 0
  
  11) I know how to count in binary without skipping numbers, unlike those guys in group 100.
3. Re:There are 11 types of developers... by Darinbob · 2015-09-23 11:38 · Score: 1
  
  You need other subcategories of number 10. Those who care about security, have to interface with security and use security features, but who are not the security expert. These are different from the developers who actually implement the security. Who may also different from the people who decide the policy of security (who may or may not be software/firmware people).
4. Re:There are 11 types of developers... by Anonymous Coward · 2015-09-23 23:42 · Score: 0
  
  You need other subcategories of number 10.
  Is there any value to this, other than the first laugh? Next "we need a subcategory for 10-E-beta for developers named Bob married to Jolene with a *white* dog".
Security is hard by phantomfive · 2015-09-23 08:59 · Score: 1

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."
1. Re:Security is hard by postbigbang · 2015-09-23 09:05 · Score: 1
  
  Nobody knows WTF is inside of a container except the person that built it, and no one knows if they MD5'd the contents, used all of the appropriate checked libs, and made sure that processes/confs/symlinks that were unnecessary were removed from the container. The same needs to be done to hypervised VMs. You can MD5 the container once built, but then checking to see if something ugly's been added isn't simple.
  Then there's the job of doing update/patch/fix, and ensuring that those payloads have a chain of course/authorities. Lacking that, downloading a container is a serious gamble, IMHO.
  
  --
  ---- Teach Peace. It's Cheaper Than War.
2. Re:Security is hard by Anonymous Coward · 2015-09-23 09:07 · Score: 0
  
  In my experience, it has been the old codgers that don't give a proper thought to security. They didn't need it "back in the day" and they don't need it now. The sooner the crappy coders of all ages get out of the business, the better.
  And there is a magic bullet. It's called "knowing what you're doing", and it's not as magic to those who have it as it is to those who don't.
3. Re:Security is hard by phantomfive · 2015-09-23 09:20 · Score: 1
  
  And there is a magic bullet. It's called "knowing what you're doing"
  Sounds like......you have a genius idea there.
  
  --
  "First they came for the slanderers and i said nothing."
4. Re:Security is hard by Darinbob · 2015-09-23 11:45 · Score: 1
  
  Experience causes people to think about security. Thus the old codgers who have the most experience are also more experienced at having run into these problems before. I see plenty of young coders repeating the same mistakes that were made back in the 70s.
  The same group of kids who think that their parents will never see their drunken pictures on instagram are not the ones who have the proper paranoia to code securely.
5. Re: Security is hard by Anonymous Coward · 2015-09-23 14:19 · Score: 0
  
  I was taught in a SUNY (State University of New York) accredited school that "it is better to look like you know what you're doing than actually know something". Luckily I haven't applied that philosophy and work hard to ensure that every line I write IS secure.
6. Re: Security is hard by phantomfive · 2015-09-23 14:41 · Score: 1
  
  I......work hard to ensure that every line I write IS secure.
  Then keep up the good work, we need more programmers like you.
  
  --
  "First they came for the slanderers and i said nothing."
7. Re:Security is hard by Anonymous Coward · 2015-09-23 16:22 · Score: 0
  
  Nobody knows WTF is inside of a container except the person that built it
  That's a part of the whole Docker ecosystem I Just Don't Get. Why's it even possible--and why could anybody think it's a Good Thing--that someone would want to deploy and trust a Docker image from whatever site where just anyone can push an image. It's a whole lot like the funky repositories like Packagist. I think of these things as analogous to vectors of social diseases. Who can tell what kind of bad thing you can catch from these?
  If you're not competent to build up your own Docker image, you're not competent enough to use Docker. Sorry.
EVEN WHEN??!!!! by rubycodez · 2015-09-23 09:01 · Score: 3, Interesting

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?
1. Re:EVEN WHEN??!!!! by Anonymous Coward · 2015-09-23 09:10 · Score: 0
  
  Because on top of the miniscule overhead of virtualization, you have the not-so-miniscule overhead of running a guest operating system. The whole point of containers is to run a VM that "borrows" its OS from the host.
  Yes, it's as sketchy as it sounds. No, that doesn't stop hype-addled nitwits from jumping on the bandwagon.
2. Re:EVEN WHEN??!!!! by Anonymous Coward · 2015-09-23 09:27 · Score: 0
  
  The usage scenario is key here...what is the container for? If it isn't public facing, containers have benefits...
  If you need containers and security, use LXC and a grsec kernel.
3. Re:EVEN WHEN??!!!! by sjvn · 2015-09-23 09:28 · Score: 1
  
  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?
  Because you can run three to four more server apps on the same architecture than you can using even efficient VMs such as KVM. That, in turn, means you have o pay for fewer servers.
4. Re:EVEN WHEN??!!!! by Anonymous Coward · 2015-09-23 09:46 · Score: 0
  
  CPU overhead for visualization may be minimal but the impact on RAM is not. VM's require an allocation of RAM beyond what the application(s) will use. This additional RAM multiplied by a large number of VM's results in a lot of wasted RAM. Containers consume just the amount of RAM used, potentially freeing up a LOT of RAM to be used to run more applications on a server.
5. Re:EVEN WHEN??!!!! by Trepidity · 2015-09-23 09:47 · Score: 1
  
  It's not a terrible idea, but it takes effort and some time to get a solid and reliable implementation. The part where you do that first, before deploying them in production, seems to have been skipped with Linux. I'd trust Solaris or Illumos Zones, because they've been around for years and have had a lot of testing. IBM WPARs are probably also fine, if you can afford AIX (not that I can). But the bundle of duct tape and bailing wire that Docker has used to cobble together containers on Linux, which changes significantly with every release, leaves me less confident.
  
  --
  10 PRINT CHR$(205.5+RND(1)); : GOTO 10
6. Re:EVEN WHEN??!!!! by rubycodez · 2015-09-23 10:20 · Score: 1
  
  You are completely full of shit, I'm looking at a VM right now at work with gigabytes provisioned but the actual RAM in use is but hundreds of megabytes. Enterprise class virtualization has evolved beyond whatever silly system you imagine
7. Re:EVEN WHEN??!!!! by phantomfive · 2015-09-23 10:38 · Score: 1
  
  The part where you do that first, before deploying them in production, seems to have been skipped with Linux
  Don't worry, the systemd programmers will take care of that!
  
  --
  "First they came for the slanderers and i said nothing."
8. Re:EVEN WHEN??!!!! by Anonymous Coward · 2015-09-23 14:18 · Score: 0
  
  You have an excellent point. No idea. Of course jumping on the latest bandwagon is all the rage.
  I view it as somewhat useful if you are a developer, as a system admin it's just another layer of complexity that needs to be managed. My former company went in that direction and it became a monumental clusterfuck. But the Docker folks flew a team of 8 folks in for us to buy a $100 a month docker hub account. They might see a return of that investment in two years. Managers felt important and trendy and further dove into it to the point of it being a unmanageable mess. Wrap that shit around devops (as valid as "webmaster" is 1995) and agile am I wanted to physically hurt people.
  "How can we further obfuscate the process?"
  I'm sick of trendy glasses, feel good culture, family like environment and fucking "architect" titles. I'm tired of tech fluff and containers. If I heard another "We are going to revolutionize" or "we're passionate about" phrases, shit's going to get ugly.
  The last place I worked was a "consumer reviews" company and nothing stuck for a week. Horrible attrition rate and each new face had a completely different idea to complicate what were simply issues to resolve. I learned to hate docker mainly because the hyperbole caused several different interpretations of how to use it. Last I heard they had 30 staging environments for every possible version some jackass "architect' could conjure. Isolate that shit to your local workstation dumbass!
  "I'm more comfortable with Puppet."
  "Saltstack is awesome!"
  "Docker rocks."
  "Ansible is more elegant."
  Pick one fucking thing and stick to it. Elegance is simplicity.
  I've never seen such a bunch of smart people that were collectively a bunch of fucking idiots.
  END OF RANT
  Yeah plain ole virtualization is fine.
9. Re:EVEN WHEN??!!!! by Anonymous Coward · 2015-09-23 21:48 · Score: 0
  
  Building containers is easy to automate and integrate as part of a build process. For example, Docker has Dockerfiles that describe how to build a container image based on an existing image (like base operating system image, or another image you have built).
  A script could be, for example:
  1. Start at a premade operating system image (e.g. Ubuntu)
  2. Run command to install a web application container
  3. Copy this web application archive from local system to container's web application directory
  4. At runtime, expose port 8080
  5. When starting image, run this command (start web application)
  A real example can be seen at here.
  Apart from that, containers are pretty similar to virtual machines. I failed to find similar utilities for creating virtual images.
10. Re:EVEN WHEN??!!!! by damaki · 2015-09-23 22:07 · Score: 1
  
  The main bottleneck of virtualization is not CPU, which is already optimized as hell, it's I/O. With virtualization you add additional layers to access storage and network devices, and thus destroying your random read/writes performances. Sure, that is not an issue for the average app, but virtualize your favorite brand of database server and you will enter a world of pain at the worst time ever possible (a high load scenario).
  
  --
  Stupidity is the root of all evil.
11. Re:EVEN WHEN??!!!! by Anonymous Coward · 2015-09-24 02:00 · Score: 0
  
  Why blame a management issue on technology?
12. Re:EVEN WHEN??!!!! by dj245 · 2015-09-24 02:52 · Score: 1
  
  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?
  Containers are easy for weekend IT guys like me who run our own servers. I don't have time to bother with learning an entirely new IT paradigm and setting it all up myself. Home server software makes all of that unnecessary and Docker containers are handled almost like "apps" in some software (like Unraid). I have to set directories and manage the network port mapping but everything else is done for me. It does what I need it to do without requiring much new knowledge or skill.
  
  --
  Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
13. Re:EVEN WHEN??!!!! by Anonymous Coward · 2015-09-24 04:41 · Score: 0
  
  Perhaps VMware vSphere 4 is enterprisey enough for you? Perhaps you should calm down and stop being a douche.
  Containers do have much less RAM overhead compared to the most advanced VM solutions out now and name calling doesn't win that argument.
14. Re:EVEN WHEN??!!!! by Anonymous Coward · 2015-09-24 07:59 · Score: 0
  
  With the username "rubeycodez" this guy obviously doesn't care about performance or scalability with a preference for Ruby.
15. Re:EVEN WHEN??!!!! by rubycodez · 2015-09-25 02:52 · Score: 1
  
  No, that's long obsolete. vSphere 6 is the current one, try to keep up
  Containers do not provide sufficient isolation, less secure even than jail
16. Re:EVEN WHEN??!!!! by allo · 2015-09-26 06:25 · Score: 1
  
  LXC does not add any IO.
17. Re:EVEN WHEN??!!!! by damaki · 2015-09-26 07:15 · Score: 1
  
  True.But a LXC is a container system; not a real virtualization solution. It's powerful, it's clean, it's wicked cool with btrfs and it's my favourite. It just lacks neat docker tools such as docker composer.
  
  --
  Stupidity is the root of all evil.
18. Re:EVEN WHEN??!!!! by allo · 2015-09-26 21:57 · Score: 1
  
  I just use it with rootfs-folder. Using a btrfs-volume may add some stuff.
  btw: Docker was based on LXC and i think it still supports it? So its just a aufs (unionfs) when using docker.
19. Re:EVEN WHEN??!!!! by damaki · 2015-09-27 02:59 · Score: 1
  
  btrfs volumes allows you to share core files between containers and not waste additional disc space. If you use a standard template to make other lxc containers, it makes new containers real cheap as it takes almost no additional disc space for each new one. Yup, I know that Docker uses the same kernel-level isolation mechanisms as LXC. But looks like it is not exactly the same as I've heard of recurrent garbage collection (files) issues with some Docker stuff. I could not guess how a properly designed docker container, with volumes for growing data, could lead to docker image growth. I thought that Docker images were meant to be read-only. BTW, ff your want Docker prebuilt containers, but bare LXC, runc (https://runc.io/) is a kind of Docker over LXC.As far as I could figure, it looks like it basically untars a docker archive in a lxc file tree. But it is still as alpha as one can do. I could not even build the damn stuff. Still, the core concept is really promising.
  
  --
  Stupidity is the root of all evil.
20. Re:EVEN WHEN??!!!! by allo · 2015-09-27 03:57 · Score: 1
  
  Yeah, docker creates a layer and then never changes it. With LXC backend, it uses aufs to stack them.
  I still prefer using bare LXC containers. There i know what i have and do not trust any prebuilt stuff. And when i start with creating a baseimage (debootstrap for ubuntu/debian), i just do the same as a "lxc-create -t debian" does.
  But maybe i am oldschool ;).
Security is easy, just tedious. by Anonymous Coward · 2015-09-23 10:03 · Score: -1

First, get the PRQA and CERT standards for software. PRQA will tell you how to avoid bugs, CERT will tell you how to avoid remaining bugs that pose a security threat. There are better standards, but I draw the line at paying $150 to learn that avionic standards are exactly the same as everyone else's. PRQA is good enough for embedded devices in vehicles, which is fine as long as you're not doing the original DARPA challenge.
Second, forget VMs and containers. Your software should not depend on unknowns for security, it should be secure in and of itself. Obviously that only goes so far, since someone breaking in through some other software may have privileges that undermine your best efforts. VMs and containers may be useful for actually running the program (but be warned, complexity is evil), however they should not be assumed. Not even in Java. Assume nothing about the environment.
Third, check for any potential race conditions. Temporary files have been used as an attack vector in the past, expect it again. They can be used safely, but it needs to be with care.
Fourth, follow CS protocol - define variables with the correct range, never use gotos, and functions should conform to a specification and written to a test.
Fifth, assume nothing. Avoid dynamic memory where at all possible, you can't be sure it'll be available and the OS will probably lie anyway. The exception is if you're using a malloc that has a pre-allocated pool that's actually (not theoretically) available. Don't rely on honest reporting of anything. That's a good way to get buffer overflows and underruns. Assume nothing about int or long int, either check the size or use the definitions that specify bit length.
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. Perl 6 and Visual Basic were the others.
Seventh, never ignore warnings. They're annoying, yes, and they can force you to recode things in a way that's BETTER. Slower, but better. You can afford the occasional extra millisecond far more than you can afford six million personal information files or ten million credit card details. You can get performance other ways. I've doubled the speed of websites simply by having static content cached rather than dynamically regenerated. It's static, for crying out loud! That's a bigger difference than you could possibly make by taking insecure shortcuts.
1. Re:Security is easy, just tedious. by sexconker · 2015-09-23 10:32 · Score: 2
  
  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.
2. Re:Security is easy, just tedious. by Anonymous Coward · 2015-09-23 11:23 · Score: 0
  
  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.
3. Re:Security is easy, just tedious. by Anonymous Coward · 2015-09-23 11:39 · Score: 0
  
  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.
4. Re:Security is easy, just tedious. by Anonymous Coward · 2015-09-24 09:52 · Score: 0
  
  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?
Developers are fucktards when it comes to security by Anonymous Coward · 2015-09-23 11:17 · Score: 0

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...
Re:Developers are fucktards when it comes to secur by Anonymous Coward · 2015-09-23 11:26 · Score: 0

The rest of you are helpless on computers minus devs making tools you merely USE, user.
I'm missing something by FrozenGeek · 2015-09-23 14:13 · Score: 1

Given that xcode is free (as in comes with OS X), why would you get it from a source other than Apple?

--
linquendum tondere
1. Re:I'm missing something by kauos · 2015-09-23 16:04 · Score: 1
  
  Given that xcode is free (as in comes with OS X), why would you get it from a source other than Apple?
  The quickest answer is that some countries fsck with the websites of others... I live in China and they love to play games with DNS resolving, temporary and permanent website bans, bandwidth restrictions (sometimes per service... ie just for www, but ssh is full speed).... and etcetera and so forth.
  
  Sometimes you will download from another site just so it doesn't take a week to download, sometimes you don't even realize that you are on a China specific site that is giving you different binaries (ie Skype).
Fucking White People by Anonymous Coward · 2015-09-23 17:07 · Score: -1

As a typical liberal /. user, I am not even going to read this racist bigoted bullshit. I do not have to. All I have to do is look at the guy in the video and realize HE is an old white male. I hate old people, I hate Males, and especially hate Whites. Seriously, when is /. going to get in with the new power of the hip hop generation. This is so obviously racists, I can't believe Hillary Clinton hasn't rounded you up and charged you with misogyny. The only acceptable reason to have a whitey I a video is if he is:
A) a dream boat like Justin Bever (b4 he got too old)
B) apologizing profusely for being white and a member of the race that did everything wrong to everyone at all times.
There are always bugs. These can be used to break by Anonymous Coward · 2015-09-23 23:49 · Score: 0

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.
Re:Developers are fucktards when it comes to secur by Anonymous Coward · 2015-09-24 02:11 · Score: 0

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.
Re:There are always bugs. These can be used to bre by Anonymous Coward · 2015-09-24 02:17 · Score: 0

http://www.c0t0d0s0.org/archives/3651-Theo-de-Raadt-about-virtualisation.html says it all
Re:There are always bugs. These can be used to bre by postbigbang · 2015-09-24 02:21 · Score: 1

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.
Doctor Who? by friesofdoom · 2015-09-24 05:23 · Score: 1

Is it just me who hates all these stupid sounding technology names?
Just a Restatement of What's Already Known by Anonymous Coward · 2015-09-24 10:44 · Score: 0

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.
Pointless by allo · 2015-09-26 06:14 · Score: 1

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.