Fix SELinux process labeling and label sockets correctly #648
Conversation
|
Cool! Is it possible for the container itself to have transitioned to some policy inside? What happens in that case here, does that person have to modify their policy inside the container to support checkpoint restore? |
Can you describe in more detail what you mean? I do not think I understand what you are asking. |
|
On Tue, Mar 12, 2019 at 03:18:37PM -0700, Adrian Reber wrote:
> Cool! Is it possible for the container itself to have transitioned to some policy inside? What happens in that case here, does that person have to modify their policy inside the container to support checkpoint restore?
Can you describe in more detail what you mean? I do not think I understand what you are asking.
Maybe what I'm asking isn't possible without selinux namespacing now
that I think about it.
What I was wondering is, if inside the container, an ngnix process
installs its own selinux policy and switches to the ngnix_t context,
will CRIU have a problem restoring that, i.e. will the external policy
have to be modified to talk about this policy inside the container?
|
Thanks for the explanation. Not sure. From what I have seen the processes in the container are always using the policy set from the outside. But I actually do not know. If a container could bring its own policy the socket labeling should still work. The process labeling on restore would fail and require a special policy, because, as far as I understand it, the container-selinux package only allows a transition from 'container_runtime_t' (this is what CRIU would be running as) to 'container_t' (what the container is running as). If the container is running as anything else CRIU would not be allowed to transition the container process to that policy. The whole CRIU SELinux integration heavily relies on having the correct policies available. |
Based on this, SELinux will always appear to be "disabled" in a container because the SELinux file system is mounted as read-only, thus processes inside containers must not be able set their own separate SELinux policies. |
|
On Wed, Mar 13, 2019 at 09:49:19AM +0000, Radostin Stoyanov wrote:
> Maybe what I'm asking isn't possible without selinux namespacing now that I think about it.
Based on [this](https://youtu.be/zWGFqMuEHdw?t=1791), SELinux will always appear to be "disabled" in a container because the SELinux file system is mounted as read-only, thus processes inside containers must not be able set their own separate SELinux policies.
Ah, ok. Thanks for the explanation. Anyway, glad to see someone
finally figured out how to do this, thanks Adrian :)
|
|
@adrianreber I was wondering if we could create test case(s) to confirm that the SELinux policy is restored correctly? |
In theory it is possible and easy. Run a test case, set a context, checkpoint that process, restore that process, compare the process label. But, as far as I know, travis does not support SELinux, so the test case will not run. The bigger problem is, that it is not easy for the test case to switch to a meaningful SELinux context. So the process would be running as 'unconfined_t' before and after restore. But as that is the default context, nothing would be really tested. Initially I wanted to add a test case, but it seemed so useless, as it cannot test anything without a special test policy. I can still add it if people think it would make sense. |
We have one Fedora host in Jenkins:
I don't understand this. Is it hard to create a test context? We run tests in Jenkins with root privileges.
Pls, add this special test policy together with a test. Our past experience showed many times that if something isn't tested, it doesn't work and will be broken soon. |
|
Added a test case. Let's see what travis thinks about this. I will fix the other review points later today. |
There was support for SELinux process labels in CRIU but because it was never tested or verified CRIU only supported the 'unconfined_t' process label. This was basically no SELinux support. For successful container checkpoint and restore on a SELinux enabled host it is necessary that the restored container has the same process context as before checkpointing. This commit only removes the check if the label is 'unconfined_t' and now stores any process label to be restored. For 'normal' processes started from the command-line which are usually running in the 'unconfined_t' this just works. For the container use case this needs additional policies. The latest container-selinux package on Fedora has the necessary policy to allow CRIU (running as 'container_runtime_t' when used from Podman) to transition the restored process to 'container_t'. Restoring a process running under systemd's control (which means 'unconfined_service_t' without additional policies) will fail because CRIU will be not allowed to change the context of the restored process. For each additional CRIU use case on SELinux enabled systems, besides container processes and command-line/shell processes, additional SELinux policies are required to allow CRIU to do a 'dyntransition' (change the Signed-off-by: Adrian Reber <areber@redhat.com>
If running on a system with SELinux enabled the socket for the
communication between parasite daemon and the main CRIU process needs to
be correctly labeled.
Initially this was motivated by Podman's use case: The container is
usually running as something like '...:...:container_t:...:....' and
CRIU started from runc and Podman will run as
'...:...:container_runtime_t:...:...'. As the parasite will be running
with the same context as the container process: 'container_t'.
Allowing a container process to connect via socket to the outside
of the container ('container_runtime_t') is not desired and therefore
CRIU needs to label the socket with the context of the
container: 'container_t'.
So this first gets the context of the root container process and tells
SELinux to label the next created socket with the same label as the root
container process. For this to work it is necessary to have the correct
SELinux policies installed. For Fedora based systems this is part of the
container-selinux package.
This assumes that all processes CRIU wants to dump are labeled with the
same SELinux context. If some of the child processes have different
labels this will not work and needs additional SELinux policies. But the
whole SELinux socket labeling relies on the correct SELinux being
available.
Signed-off-by: Adrian Reber <areber@redhat.com>
This tests if CRIU can restore a process with the same policy as during checkpointing. The test selinux00 is started and if SELinux is available the test process moves itself to another process context. To make this possible either a new SELinux policy needs to be available containing: fedora-selinux/selinux-policy@2d537ca Or for a short time SELinux is switched to permissive mode. The correct SELinux setup is done by zdtm/static/selinux00.checkskip and zdtm/static/selinux00.hook and after the test the previous SELinux policy state is restored. After the test case is restored the test case checks if it still has the same SELinux process context as before. If not the test cases fails. Signed-off-by: Adrian Reber <areber@redhat.com>
|
I just discovered that this does not work for non-single-threaded processes: https://github.com/torvalds/linux/blob/master/security/selinux/hooks.c#L6268 If CRIU tries to restore the process context of each thread via And the following errors in the audit.log: @tych0 do you have any ideas how solve this? Or who could have an idea how solve this? |
|
From the man page of
|
|
@rst0git Yes, that is my fallback plan. The problem is, that this does not correspond to CRIU's idea to set the credentials as late as possible. I guess I have to try out if this works. If the process context is changed much earlier different things CRIU has to do might no longer work. All of a sudden most of the restore steps will be performed in the target context. But this can be solved by additional policies. Currently the only policy needed is to allow the process to change its process context. If the process context is set before thread creation we might need much more policies. Thanks for the pointer, I need to try it out. |
|
@rst0git Setting the process context before forking works. The necessary code changes also are not too bad, but I get something like 50 new SELinux denials. The restored process and all its threads are now running in the process context of the to be restored container (which is good) but to restore the process CRIU does a lot of steps (including different mounts) which does not sound like something which a container process should be allowed to do, but which is necessary for CRIU. For CRIU it would be much better to be able to change the process context as late as possible. |
The reason for this dynamic context transition support restriction is:
Another option could be (from man page of setcon(3)): https://selinuxproject.org/page/Bounds_Rules |
|
Just as a status update: I found a better place for setting the context. In the restorer just before creating the threads. This reduces the necessary SELinux policy to a single policy to allow writing the log file. That sounds doable. |
This changes is motivated by containers/podman#2334
The main problem when trying to checkpoint a container on a SELinux enabled system is, that the connection from the parasite daemon to the main CRIU process is blocked by SELinux. The error looks something like:
That SELinux blocks a connect() from the container process to the outside of the container is understandable.
The solution discussed and which has been implemented in this PR is, that CRIU now labels the socket on a SELinux enabled system with the same SELinux context as the parasite daemon running in the container. With the socket correctly labeled Podman can now checkpoint a container on a SELinux enabled system without denials, because the parasite daemon can access the main CRIU process.
This PR also removes CRIU limitation to only work with the SELinux context 'unconfined_t'. According to @tych0 this limitation was introduced as, at that time, no one was sure if the SELinux implementation actually works. With the correct SELinux policies it works correctly. The biggest problem is, that usually it is not expected that a process changes its own process context. CRIU, however, has to do it. With this change a restored container has the same process context as during checkpointing.
For the container use case the Fedora package container-selinux has introduced a policy to allow CRIU to transition from one process context to another (containers/container-selinux@891a85f containers/container-selinux@a2fc030).
Processes started from the shell are usually running as 'unconfined_t' if no special policy exists and as CRIU will then also be running as 'unconfined_t' it should just work as before. For any process running in another process context additional SELinux policies have to be defined in the future.