#505 RFC: Make /var/srv system_u:object_r:container_file_t:s0 by default
Closed: Duplicate 2 years ago Opened 2 years ago by walters.

SELinux and containers - a fairly nontrivial difference we carry from other distributions (Ubuntu, CL) etc. that either don't use SELinux or aren't enforcing. See this blog for some discussion about the :z/:Z flags.

The fact that we require these labels to be set very, very commonly trips up people. And further, I think a big problem with :z is that it forces a relabel every time - it's much better to have the labels set up correctly in the first place!

Another related issue is that people do e.g. -v /home/myuser:/home:z which will completely break the OS which expects /home/myuser to be user_home_dir_t etc.

Hence, my proposal is: For Atomic Host, change /var/srv to be system_u:object_r:container_file_t:s0 by default. It can then be assumed as a default interchange point for containers and the host - no labeling required.

Positives: We can start documenting this, and other tools (like a pet container one) can just assume this works.

Downsides: If we don't do this for classic as well, we'll have introduced a new special distinction between AH and classic - we currently have very few of those.


seems reasonable to me.

@dwalsh, mind weighing in?

Why would /var/srv be totally labeled as container content? I could see /var/srv/containers or something like that.

ALso :z relabels to container_file_t:s0 not container_share_t. container_share_t is read/only to the containers, while container_file_t:s0 is writable by ALL of the containers.
Labeling something container_file_t:s0 allows all of the containers to attack each others content based on SELinux.

I could see /var/srv/containers

Sure. Though what else would one be doing in /srv on AH/Silverblue? That said I'm fine with a subdirectory.

Labeling something container_file_t:s0 allows all of the containers to attack each others content based on SELinux.

One use case I have is for different "pet" containers to be able to easily exchange data. Or in general, to run a perhaps less-trusted container, point it at -v /srv/somedata, and then kill it. At that point I can safely interact with /srv/somedata.

To rephrase the original rationale: If you prefix your bind mount with /srv[1] then you don't have to worry about SELinux labeling.

[1] Or whatever prefix we decide on

can we agree on /var/srv/containers/ for atomic and /srv/containers as a sensible default on fedora?

Maybe the toolbox package can provide that dir. :)

Metadata Update from @dustymabe:
- Issue close_status updated to: Duplicate
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata