Safety analysis of service­-oriented programming

Abstract

Over the last few years, the use of virtualization technologies has increased dramatically. Therefore, the need for effective and secure virtualization solutions is becoming increasingly apparent. Container-based virtualization and hypervisor-based virtualization are the two main types of virtualization technologies that have appeared on the market. Of these two classes, container-based virtualization can provide a lighter and more efficient virtual environment, but not without security issues. This article analyzes the security level of service-oriented programming, which is based on application containerization. Let’s look at two areas: the internal security of serviceoriented programming and how it interacts with Linux kernel security features such as SELinux and AppArmor to enhance host security. The analysis shows that service oriented programming provides a high level of isolation and resource limiting for its containers using namespaces, cgroups, and its copy-on-write file system, even with the default configuration. It also supports several kernel security features, which help to hardening the security of the host. The only problem we found with service oriented programming was related to its default networking model. The virtual ethernet bridge which service oriented programming uses as its default networking model, is vulnerable to ARP spoofing and MAC flooding attacks since it does not provide any filter on the network traffic passing through the bridge. However, this problem can be solved if the administrator manually adds filtering, such as ebtables, to the bridge, or changes the networking connectivity to a more secure one, such as virtual network. It is also worth highlighting that if the operator runs a container as «privileged», service oriented programming grants full access permissions to the container, which is nearly the same as that of processes running natively on the host. Therefore, it is more secure to operate containers as «non-privileged». Furthermore, even though containers can provide higher density of virtual environments and better performance, they have a bigger attack surface than virtual machines since containers can directly communicate with the host kernel. However, it is possible to reduce the attack surface while maintaining these advantages. For example, this can be achieved by placing containers inside virtual machines.