Unable to copy files using Python across certain contexts

[containers]

Unable to copy files using Python across certain contexts

If i understand correctly from op, then this does not happen with cp -a. I wonder whether that is because coreutils is built with libselinux whereas python is not built with selinux awareness. (As per the container spec, entities linked against libselinux should know what to do and what not to do when selinuxfs is mounted r/o)

[leiflm]

If i understand correctly from op, then this does not happen with cp -a.

correct.

[rhatdan]

In this container could you run id -Z, to see if the container thinks SELinux is disabled. It looks like Python3 is attempting to do an SELinux action, but it is not supposed to think SELinux is enabled within the container.

[leiflm]

In this container could you run id -Z, to see if the container thinks SELinux is disabled.

# id -Z
id: --context (-Z) works only on an SELinux-enabled kernel

It looks like Python3 is attempting to do an SELinux action, but it is not supposed to think SELinux is enabled within the container.

As mentioned above, this is stock fedora:latest container. Should I be running something different?

[leiflm]

In this container could you run id -Z, to see if the container thinks SELinux is disabled.

# id -Z
id: --context (-Z) works only on an SELinux-enabled kernel

Regarding the reliability of id -Z, I'd like to cite @rhatdan from another bug report here:

Sorry id -Z might be lying to you.
Inside the container do:
cat /proc/self/current/attr

There is a small swapping mistake in the path argument there, yet here we go.

Inside the container:

# cat /proc/self/attr/current 
system_u:system_r:container_t:s0:c189,c689

Outside the container:

$ getenforce 
Enforcing

Yet I'm not really sure what to do with this information. Is Python looking at the wrong info here? I.e. not asking libselinux?

[rhatdan]

This is what I am thinking. Could you open a bugzilla on Python and add me as a CC. Then we can discuss it with the packagers.

[leiflm]

Thanks for your help here.

Could you open a bugzilla on Python and add me as a CC. Then we can discuss it with the packagers.

https://bugs.python.org/issue38893

I hope the description is correct. If not, feel free to add information or let me know what to change about it.

[adelton]

@rhatdan, Is it expected / correct that with rootless podman containers and FUSE, the content of the image inside of the container is labelled with fusefs_t, instead of container_file_t? If the labels were container_file_t, python would likely not try to set the attributes and thus would not do the relabelling.

[rhatdan]

@giuseppe Could you try to use fuse-overlayfs with a context mount?
context="system_u:system_r:container_file_t:s0:c1,c2"

If this worked we could solve the issue.

[adelton]

@rhatdan How can that be done for the / filesystem? I tried to change this rootless container

$ podman run --rm -v /data registry.fedoraproject.org/fedora:31 ls -laZ /data
total 8
drwxr-xr-x. 2 root root system_u:object_r:container_file_t:s0 4096 Feb 28 14:23 .
drwxr-xr-x. 3 root root system_u:object_r:fusefs_t:s0         4096 Feb 28 14:23 ..

to have container_file_t on the parent (/) directory but --security-opt=label=filetype:container_file_t did not seem to help:

$ podman run --security-opt=label=filetype:container_file_t --rm -v /data registry.fedoraproject.org/fedora:31 ls -laZ /data
total 8
drwxr-xr-x. 2 root root system_u:object_r:container_file_t:s0 4096 Feb 28 14:25 .
drwxr-xr-x. 3 root root system_u:object_r:fusefs_t:s0         4096 Feb 28 14:25 ..

[rhatdan]

Rootless containers use a fuse-overlay system for the host image, which basically is labeled fusefs_t. Their is no way currently to do what you want.
@giuseppe Does fuse-overlay support a context mount? I am not sure if fuse file systems do this at all.
@adelton The --security-opt is only for process labels, we don't allow users to specify mount_labels directly.

[giuseppe]

@giuseppe Does fuse-overlay support a context mount? I am not sure if fuse file systems do this at all.

AFAICS, the context= option has no effect with FUSE

[rhatdan]

@stephensmalley WDYT

[stephensmalley]

I'm not sure I follow. The context= mount option is handled by SELinux not by the individual filesystems (the security-related options get extracted from the mount option list by the kernel and fed to the security modules to consume, then the rest go to the filesystem). The context= mount option should work with FUSE just as it does for other filesystems that do not truly support file security labeling, e.g. vfat or nfs < 4.2.

[rhatdan]

That means in rootless containers we should be mounting the fuse-overlay fs with context_mount of the container.

[rhatdan]

This issue has nothing to do with container-selinux and can not be fixed in this repo. Now that the kernel supports rootless overly mounts, this problem may not exist any longer.