Good article even though I don't agree with all the conclusions.
I find a good way to think about things is that every single dependency you have adds another set of people you have to trust.
You're trusting the competence of the developer (i.e. that the library has no security flaws), you're trusting their intent (i.e. that they don't deliberately put malicious code into the library) and you're trusting their Operational Security practices (i.e. that their systems don't get compromised, leading to loss of control of their libraries).
Now when you think about how little you know about most of the owners of libraries you use, you can see possibility for concern.
The bit I disagree with the article about is signing. I personally think that developer signing is a useful part of this as it takes the repository owner out of the trust picture (if done correctly). Without it you're also trusting the three items above for the repository provider and it's worth noting that a large software repo. is a very tempting target for quite a few well funded attackers.
Docker at least has provided some of the technical pieces to address this in their repositories with content trust...
This is v.cool, although for the Windows version it'd be great if it became possible to swap out the virtualization back-end so it's not tied to Hyper-V.
At the moment VMWare Workstation users will be a bit left out as Windows doesn't like having two hypervisors installed on the same system...
yep the linux repositories are generally way ahead of the programming language lib ones in this regard (evidently with the exception of Maven), one of the reasons that it's a shame to see newer ones not learn the lessons that previous repo's have on security
I really doubt anyone checks them. It's not integrated or enabled by default, there's no way to pin keys in the build files, etc. GPG isn't the solution to such problems, unfortunately.
In one of my old projects (bitcoinj) we did write a Maven plugin that let you put the hashes of the dependencies into your build file.
However it's rare to see Maven/Gradle builds that accept version ranges. And once downloaded it's cached.
For example, RubyGems it's possible to sign them, but it's not used as much as it should be because option security never gets used. Waxseal is a gem to sign other gems.
Generally though, it's a worse vulnerability than bitsquatting because it gives quarter to silent, advanced, persistent threats by definition. (Dynamic, untrusted code modification either in-flight or at-rest in difficult to prevent/audit ways.)
The primary way for change to happen is for some company to get hacked, but then it will only change for that one platform because most people are reactive not proactive. Changing this proactively seems painful, but it's less onerous than the risks of the alternatives. The key point is to make end-to-end verification and public key management mandatory and simple.
With 1.10 you can just enable User namespaces, which allows for root in a container to map to a non-privileged user outside the container, that way it's a one-time (per instance) change.
While this is a nice security boost once you're in the container, don't you still need to be root (docker group) in order to start the container? It honestly doesn't help me much if I have to give users root in order to start a container, even if they are wrapped inside the container.
Yep, at the moment, with raw docker engine, if a user has access to create containers, they're basically able to get root on the box, as the docker daemon runs as root and there isn't any authorization control by default, so it doesn't work well for that kind of scenario.
With that said there's a couple of ways this is getting addressed.
1) in 1.10 authorization plugins landed as a feature,so it's possible to add this functionality.
2) there's a number of services which run on top of Docker Engine (e.g. Docker Universal Control Plane) which have authentication/authorisation at that level.
This doesn't work when users may need to run arbitrary (or user-defined) containers. You can only sudo so much... But, perhaps you could restrict it to "sudo docker run". I'll have to give that a try. But that would make it extraordinarily more difficult for a user to stop / rm / kill a container. Plus, it's not like docker has the concept of an "owner" for a container - does it?
Nonetheless, you shouldn't need to run anything as root in order to start a container that doesn't require extra privileges .
I'd say that it's a trade-off whether you think the enhanced isolation provided by containerization/virtualization is more of a security benefit than the risks posed by the increased attack surface of another layer in the stack...
Good presentation. One thing I'd mention is that they talk about the CIS security guide, but it's currently pretty out of date as it covers 1.6 and therefore misses a lot of Docker features like Content Trust, User Namespaces and Seccomp-BPF.
In general I'd say that Docker security is getting better, although I'm really looking forward to getting a better authentication/authorisation model on the docker engine as right now it's all or nothing, which is a pretty blunt instrument. Also this model causes problems when people do things like mount docker.sock inside a container for introspection as anyone compromising that container can take over the host. A better authorisation model would allow safer introspection...
Also worth noting as it's not in the presentation, one of the key Docker security features, User Namespaces, is not switched on by default, so you need to enable it on the daemon.
Presumably because no one wants to live in Dumfries and Galloway. That's not meant to be a slant against the place -- I don't think I've ever been there -- but the price will drop if there's a decrease in demand with flat/rising supply.
Whilst other areas are expensive London it totally in a league of it's own.
Edinburgh (most expensive part of scotland) average property price £234k. London, average property price £642k
Also people in Scotland and areas like Manchester can more easily get on the property ladder by buying in cheaper nearby areas. for Edinburgh places like West Lothian (average price £164K) make a much easier starting point.
Heck with improving internet access, if you can do your job remotely the western isles are nice and cheap (average price around £100k)
For me the UKs property market is heavily split between London and the south east and "the rest of the country", a lot of the stories about expensive UK property don't seem to cover those aspects.
Prices in many parts of the UK have been more or less static since 2008, and in some cities they've actually fallen.
The hot spots are all "capital" cities for their catchment areas.
>if you can do your job remotely the western isles are nice and cheap
I've considered this, but I decided that moving to Europe is a better idea, for cultural and political reasons.
Also, it doesn't rain nearly as much; climate change is going to flood/rot a lot of the UK's housing stock and infrastructure over the next few decades, and I'd rather be somewhere hotter and drier.
I find a good way to think about things is that every single dependency you have adds another set of people you have to trust.
You're trusting the competence of the developer (i.e. that the library has no security flaws), you're trusting their intent (i.e. that they don't deliberately put malicious code into the library) and you're trusting their Operational Security practices (i.e. that their systems don't get compromised, leading to loss of control of their libraries).
Now when you think about how little you know about most of the owners of libraries you use, you can see possibility for concern.
The bit I disagree with the article about is signing. I personally think that developer signing is a useful part of this as it takes the repository owner out of the trust picture (if done correctly). Without it you're also trusting the three items above for the repository provider and it's worth noting that a large software repo. is a very tempting target for quite a few well funded attackers.
Docker at least has provided some of the technical pieces to address this in their repositories with content trust...