Red Hat 계정으로 회원 프로필, 기본 설정 및 고객 상태에 따라 다음의 서비스에 액세스할 수 있습니다.
아직 등록하지 않으셨습니까? 등록해야 하는 이유:
- 한 곳에서 기술 자료 문서를 탐색하고, 지원 사례와 서브스크립션을 관리하고, 업데이트를 다운로드 할 수 있습니다.
- 조직 내의 사용자를 보고, 계정 정보, 기본 설정 및 권한을 편집할 수 있습니다.
- Red Hat 자격증을 관리하고 시험 내역을 조회하며 자격증 관련 로고 및 문서를 다운로드할 수 있습니다.
Red Hat 계정으로 회원 프로필, 기본 설정 및 자신의 고객 상태에 따른 기타 서비스에 액세스할 수 있습니다.
보안을 위해, 공용 컴퓨터 사용 중에 Red Hat 서비스 이용이 끝난 경우 로그아웃하는 것을 잊지 마십시오.로그아웃
A few weeks ago, I wrote a blog on removing capabilities from a container. But what if you want to add capabilities?
While I recommend that people remove capabilities, in certain situations users need to add capabilities in order to get their container to run.
One example is when you have a app that needs a single capability, like an Network Time Protocol (NTP) daemon container that resets the system time on a machine. So if you wanted to run a container for an ntp daemon, you would need to do a
--cap-add SYS_TIME. Sadly, many users don't think this through, or understand what it means to add a capability.
The most dangerous capability:
Whenever I present on container security I explain that the power of root was originally broken into 32 separate capabilities. These capabilities were originally fairly fine grained. But two things conspired to make some of them become very powerful.
- As number of available capability slots were used up, the cost of using up a new capability versus just assigning a permission check to an existing capability increased.
- Kernel developers being lazy and not wanting to go through the hassle of allocating a new capability began to say stuff like: "This permission check is an admin function, I have a capability called SYS_ADMIN, I will just use that."
This led the
SYS_ADMIN capability to need two pages of the capability man page just to list the features given to a process with the
The main feature that containers take advantage of when removing the ability for processes inside of the container to mount new file systems.
Recently I received an email from a co-worker showing me what they could do with the
Talking about selinuxfs, there is also an quick exploit that allows disabling the host selinux from a container, although so far it needs CAP_SYS_ADMIN (to mount selinuxfs) and without --selinux-enabled (like in previous overlayfs) in docker.
# docker run -it --rm --cap-add SYS_ADMIN rhel7 bash [root@d2b1fb6bd57c /] mount -t selinuxfs none /mnt [root@d2b1fb6bd57c /] getenforce Enforcing [root@d2b1fb6bd57c /] setenforce 0 [root@d2b1fb6bd57c /] getenforce Permissive [root@d2b1fb6bd57c /] exit # getenforce Permissive
Bottom line: giving a process SYS_ADMIN capability is pretty close to removing all isolation. As a rule, you shouldn't do this, but it's helpful to know that you can if you need to for some reason.
About the author
Joe Brockmeier is the editorial director of the Red Hat Blog. He also acts as Vice President of Marketing & Publicity for the Apache Software Foundation.
Brockmeier joined Red Hat in 2013 as part of the Open Source and Standards (OSAS) group, now the Open Source Program Office (OSPO). Prior to Red Hat, Brockmeier worked for Citrix on the Apache OpenStack project, and was the first OpenSUSE community manager for Novell between 2008-2010.