table { border: #ddd solid 1px; } td, th { padding: 8px; border: #ddd solid 1px; } td p { font-size: 15px !important; }
In this series of blog posts, we would like to introduce how containers could be isolated between each other and from the host system, why Multi-Category Security container separation could be considered more secure than Multi-Level Security, how you can increase security with container pipelines and how to use multiple trusted networks with containers in high security environments.
The first part of the series is focused on how SELinux technology separates containers.
Security Enhanced Linux (SELinux) is an additional security layer at the userspace level used by Red Hat Enterprise Linux (RHEL) and a number of other Linux distributions as an implementation of the mandatory access control concept.
SELinux is central to our support of container separation as well as Multi-Level Security (MLS). In containers we use SELinux to help prevent container attacks against the host file system. The standard Linux security model contains several security issues, like allowing the superuser “root” to bypass all security checks, possibility of using setuid bit to allow users to run an executable file with the permissions of the executable file owner, etc.
This could cause security issues on systems. SELinux technology doesn’t recognize which Linux user executed a binary file or which security bits are set to file. SELinux is a labeling system and SELinux cares only about labels. From the SELinux point of view each object on the system has an SELinux label (every file, directory, socket file, symlink, shared memory, semaphore, fifo file, etc.) and also every subject (running process, Linux user entity).
An example of a SELinux label for file /etc/passwd
: system_u:object_r:passwd_file_t:s0
An example of a SELinux label for running process (container process): system_u:system_r:container_t:s0:c940,c967
The system_u
label represents a SELinux user, which is not the same as a Linux user. Several Linux users can be mapped to a single SELinux user. This system_u user can be limited to a set of SELinux roles.
SELinux users can have multiple roles but only one can be active and these roles could be limited to a set of SELinux types. In the example above, SELinux type is passwd_file_t
(in file example) and container_t
(in process example). In this post we won’t focus on the Role Based Access Control (RBAC) security model but only the Type Enforcement security model where only types are used. Interactions between types are defined in the SELinux security policy and describe access between subjects and objects.
Example of an interaction (also called SELinux rule): allow container_t container_file_t:file {getattr open read};
The rule from this example shows that every process labeled as container_t
can get attributes, open and read any file labeled as container_file_t
on the filesystem!
As you can see, in the rule there is no name of process or file mentioned, nor path nor Linux user. SELinux cares only about labels.
The last part of the Security label is the MLS and Multi Category Security (MCS) piece. The combination of these two parts increases security because each sensitivity label is composed of a hierarchical classification and a set of non-hierarchical category compartments. With MCS, the SystemLow
sensitivity label is s0
and the SystemHigh
sensitivity label is s0:c0.c1023
while on an MLS system the two labels are SystemLow
(s0
) and SystemHigh
s15:c0.c255
.
MLS policy provides a much stricter security policy than the targeted policy. In addition to more restrictive Type Enforcement and RBAC rules, it also provides an MLS implementation based on the Bell-LaPadula mandatory access control model, which focuses on data confidentiality and controlled access to classified information. In an MLS system the primary aim is to prevent "read up" or "write down". "Read up" means reading data that is classified at a level higher than the process that is reading it, "Write down" means writing data into a level lower than the process that is writing it. MLS is a key requirement to meet the common criteria label security profile and is popular with many high security users in the government and intelligence communities.
MCS is used on container separation when running multiple containers with the same SELinux type is needed. Let’s say you’re running two containers with the same SELinux type container_t
and both of them accessing three files with the same SELinux type container_file_t
. The SELinux policy rule is then placed in the following SELinux policy:
allow container_t container_file_t:file { getattr open read write append ioctl lock };
This example is saying that every container process labeled as container_t
can read/write any file labeled as container_file_t
. But how to separate these containers? Let’s put containers and files categories as described in the following table:
container_file_t:s0:c1 |
container_file_t:s0:c2 |
container_file_t:s0:c3 |
|
container_t:s0:c1,c2 |
can access |
can access |
cannot access |
container_t:s0:c2,c3 |
cannot access |
can access |
can access |
The container labeled container_t:s0:c1,c2
can access files labeled as container_file_t:s0:c1
and container_file_t:s0:c2
because categories {c1} and {c2} are subsets of set {c1,c2} but it cannot access container_file_t:s0:c3
because category {c3} is not subset of set {c1,c2}. A similar concept also applies to container_t:s0:c2,c3
. When an object does not have any category (container_file_t:s0
) an empty set is also part of every process set, which means every container with whatever category can access it.
This figure illustrates how SELinux separates containers on a kernel level. If one container wants to access another container or some object on the host file system, this access must be allowed in the SELinux policy loaded to kernel space and also categories must be properly assigned based on the example described above.
![Figure 1: How SE Linux separates containers on the kernel level Figure 1: How SE Linux separates containers on the kernel level](/rhdc/managed-files/2020-05-12-selinux-image-figure-1.png)
Figure 1: How SE Linux separates containers on the kernel level
In the first part of the new containers security series, we discussed what is the SELinux technology and how it could be helpful to increase container security, how containers are labeled and what MLS and MCS are. In the next part of the containers security series, we will compare MLS and MCS security models that could be used in container environments to separate containers between each other.
저자 소개
Daniel Walsh has worked in the computer security field for over 30 years. Dan is a Senior Distinguished Engineer at Red Hat. He joined Red Hat in August 2001. Dan leads the Red Hat Container Engineering team since August 2013, but has been working on container technology for several years.
Dan helped developed sVirt, Secure Virtualization as well as the SELinux Sandbox back in RHEL6 an early desktop container tool. Previously, Dan worked Netect/Bindview's on Vulnerability Assessment Products and at Digital Equipment Corporation working on the Athena Project, AltaVista Firewall/Tunnel (VPN) Products. Dan has a BA in Mathematics from the College of the Holy Cross and a MS in Computer Science from Worcester Polytechnic Institute.
Lukas Vrabec is a Senior Software engineer & SELinux technology evangelist at Red Hat. He is part of Security Controls team working on SELinux projects focusing especially on security policies. Lukas is author of udica, the tool for generating custom SELinux profiles for containers and currently maintains the selinux-policy packages for Fedora and Red Hat Enterprise Linux distributions.
Simon Sekidde is a Solution Architect for the North America Red Hat Public Sector team specializing in the application of open source enterprise technologies for the Federal Department of Defense (DoD) customers.
Ben Bennett is a Senior Principal Software Engineer and is the group lead for the SDN, Routing, DNS, and Storage components of Red Hat OpenShift. He has more than 25 years of experience working with networking, distributed systems, and Linux.
유사한 검색 결과
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.