In our first article – Is your container really secure? on security of containers, we questioned whether the containers we are used to using are natively secure. Our goal was to warn that the use of containers is also observed more carefully.
So, basically what we answered was “what is not secure about containers?
In this article, our goal is to extend a little more on this subject, bringing a little more information on the topic and showing some possible solutions.
When we look at the security of containers, we have to imagine some borders of protection. We have to protect the container host, and the container of other containers.
As in many aspects of application security, our first thought is to have security thought in layers, and with that reinforce the best use of each one of them. So we must think about how to combine multiple security controls to mitigate possible weaknesses and thus protect our assets.
File Systems
For a container to function properly, considering a linux host, some file systems must be mounted. But, in the same way, we must understand that not all these file systems need to be mounted with full access, we can improve this.
This way, we can mount these filesystems in a read-only way, thus limiting their use. This is because the vast majority of applications will not really need to have another type of access than just read-only, here’s our first tip: Know well which access and which structures your application should have.
So, we can suggest some filesystem spaces to be mounted with read-only access and they are: /sys, /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus. However, always evaluate if these are sufficient, both for more and for less.
If we can keep these filesystem spaces restricted, we also guarantee that the container can only read these files, so there is no way to affect the host system.
However, there is still one other thing to remember: we have to limit the possibility of the container reassembling these file systems in another way. That is, return to the full access permission pattern.
Capabilities
But be cautious, limiting access to privileged container processes too much may cause the application to work incorrectly or even not work in your container. Therefore, we want to suggest some capabilities that are used by containers and should be treated with care. They are: chown, dac_override, fowner, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, setfcap and audit_write.
There are also a set of capabilities that are taken from the containers by default, and we will only use two examples of these. When removing the SYS_MODULE capabilities, the container will not be able to load or unload any kernel module, for example.
Or, if the NET_ADMIN capability is disabled, the container will not be able to modify for example its own IP address, or even add new routes in its routing table, or even modify some iptables firewall rule.
There is still another very important component to be removed. SYS_ADMIN allows containers with privileged processes of this capability to perform for example a namespace modification action or even a syscall call. You don’t want your container running this kind of action, do you ?
Here it’s still worth the tricks, if you don’t need it, you can take it back!
Ah ok, but how can I remove these features? It’s simple, and besides withdrawing, you can put it in the moment you think it’s necessary. Just use the –cap-add or –cap-drop commands when running your container.
Namespaces
We have already mentioned in our other article about the namespaces, but we want to detail some of them.
PID settings (–pid)
The first thing we have to remember is that, by default, every container already has the PID enabled.
The PID provides the containers, or even any linux system, with the separation of processes. Thus, the PID removes the vision we can have about the processes, and if you do not see a process, it becomes more difficult to take action on it.
However, in some cases, you need the container to share host processes using your namespace. And basically what will happen is that the process inside the container will see your host’s process.
It is not necessary to remember that this type of action requires a careful and much more elaborate evaluation. But let’s say you want to run some debugging tools, but using your host’s namespace. Risky but possible.
So, PIDs give us this kind of limitation to processes, which can be a good step for the security of our container and the host itself.
Network settings in container
As with any machine, the containers also have the characteristics of network configurations. And by default they are already enabled on all containers created.
One of the possible scenarios is that you can have a specific DNS set for your containers, providing for example, that your container set has DNS managed traffic but restricted.
Configuring your container network is first of all about understanding that containers can have some types of configurations. As is the case with the “none” option, that is, without any kind of network, or even the “bridge” option where the default settings of the Docker will be used.
We still have the “host” options, and here the container will use and have available the network interfaces of the host. And there is also the container option, where one container can use the network configuration of another.
There are many ways to configure a container when thinking about networks and it is worth a good read in the official documentation of the Docker is very detailed and very explanatory.
CONTACT US ABOUT OUR SERVICES
Conclusion
As always, our main goal is to bring topics that can stimulate the study and reading of subjects related to AppSec.
In this specific topic, we can see that there is a great field of study and evaluation when we talk about container security. We need to understand the tool, know what its weaknesses are and how we can act on them.
What we can’t in any way be is to be simple observers of a process that has been maturing with time and not participate in it in a correct way.
We want to help everyone who is now starting their journey with containers to do it correctly. Remember: containers are tools that can bring us great gains, but can also put us into much bigger problems.
The correct construction and use of containers can be the difference between keeping your structure secure or having a weak point within your system.
I hope I have helped!
See you next time!
