I told the reporter that you could cause two containers to run with the same MCS labels by using the -security-opt label:level:MCSLABEL option.ĭocker run -it -rm -security-opt label:level:s0:c1000,c1001 -name server -v myvol:/tmp test /serverĭocker run -it -rm -security-opt label:level:s0:c1000,c1001 -name client -v myvol:/tmp test /client How would I make two containers share the same SELinux labels?ĭocker by default launches all containers with the same type field, but different MCS labels. With a shared IPC the SELinux labels for both of the reporters containers were the same, and SELinux allowed the passing. If docker did not do this SELinux would block processes from container A access to IPCs created in Container B. The reason for this is when you share the same IPC Namespace, docker automatically caused the containers share the Same SELinux label. Surprisingly he also figured out if he shared IPC namespaces between the containers, SELinux would not block. The reporter also figured out that he could get this to work by disabling SELinux either on the host or inside of the container. We would not want to allow a confined container to be able to read/write socket file descriptors from another container by default. The bug reporter was reporting that by default he was not able to pass the descriptor, which is goodness. If I have a process labeled system_u:system_r:svirt_lxc_net_t:s0:c1,c 2 and I pass that file descriptor to a process in a different container labeled system_u:system_r:svirt_lxc_net_t:s0:c4,c 5, SELinux will block the access. In containers, even though by default all container processes have the same SELinux typo, they have different MCS Labels. If it does not SELinux will block the transfer. If this socket descriptor is passed to another process the new process label has to have access to the socket with the "socket label". SELinux would then check to make sure that unconfined_t is able to connecto docker_t sockets. The client is probably running as unconfined_u:unconfined_r:unconfined_t:s 0-s0:c0.c1023. For example when the docker service (docker_t) listens on /var/run/docker.sock and a client connects the docker service, the docker service end of the connection gets labeled by default with the label of the docker process. When a process accepts a connection from a remote system, the file descriptor is created by a process it automatically gets assigned the same label as the process creating the socket. Lets look at what happens when a socket file descriptor is created by a process. SELinux controls passing of Socket file descriptors between processes.Ī Fedora user posted a bugzilla complaining about SELinux blocking transfer of socket file descriptors between two docker containers.
0 kommentar(er)
