Add option to checkpoint to specify SELinux label

[adrianreber]

To checkpoint a process CRIU injects a parasite code into the process to
be checkpointed. This parasite code tries to communicate over a socket
with the main CRIU process. To SELinux this looks like a process inside
of a container tries to open a socket to another process.

This adds an option to runc to call setsockcreatecon() before running
CRIU to label all sockets with a certain label. Having the possibility
to specify a certain label makes it easier to write corresponding
policies.

[adrianreber]

@rhatdan as discussed in containers/podman#2334

[rhatdan]

I don't think we need an option here. runc should just be setting the socket label to match the process label if the process label is set. This indicates that the socket is to be used by the container process.
I don't like allowing the caller to set the label, since this is not the way SELinux works. Potentially I could see passing a flag that says "don't set the label", but I really see that as a corner case.

[adrianreber]

Unfortunately this does not work at all. I was using an instrumented CRIU which did the setsockcreatecon() just before creating the socket without noticing it. I think I have to do this directly in CRIU because if I do setsockcreatecon() in runc before calling CRIU and if I then do a getsockcreatecon() in CRIU I get a null. It seems setsockcreatecon() does not survive exec(), right?

[rst0git]

It seems setsockcreatecon() does not survive exec(), right?

From the man page of setsockcreatecon(3):

• The sockcreate context is automatically reset after the next execve(2), so a program doesn't need to explicitly sanitize it upon startup.

I think I have to do this directly in CRIU because if I do setsockcreatecon() in runc before calling CRIU and if I then do a getsockcreatecon() in CRIU I get a null.

Would it be possible to pass the value of opts.SELinuxSocketLabel to CRIU via opts.lsm_profile?
Note that this option is also used in by LXC.

[adrianreber]

It seems setsockcreatecon() does not survive exec(), right?

From the man page of setsockcreatecon(3):

* The sockcreate context is automatically reset after the next execve(2), so a program doesn't need to  explicitly sanitize it upon startup.

Thanks for that pointer. So it cannot work with setsockcreatecon() from the parent application.

I think I have to do this directly in CRIU because if I do setsockcreatecon() in runc before calling CRIU and if I then do a getsockcreatecon() in CRIU I get a null.

Would it be possible to pass the value of opts.SELinuxSocketLabel to CRIU via opts.lsm_profile?

So far I tried setexeccon() before calling CRIU, but that failed and I kind of expected that, because CRIU is then running in the wrong context. The problem I also detected is that the restore process is running in the wrong context anyway, so this needs some work on CRIU. As far as I understand it opts.lsm_profile is only relevant during restore, but the current problem needs a certain label on the sockets during checkpoint. We could use opts.lsm_profile during checkpointing to pass the desired socket label, but I think a new option would be cleaner.

Note that this option is also used in by LXC.

I have also looked at this code already 😁 .

[adrianreber]

Closing this as it does not work and I have a change in CRIU to do it correctly: checkpoint-restore/criu#648