Bug 1224417 - add selinux label for /var/lib/kubelet
Summary: add selinux label for /var/lib/kubelet
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: docker
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lokesh Mandvekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-22 21:31 UTC by Eric Paris
Modified: 2015-06-02 17:58 UTC (History)
18 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-06-02 17:58:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Eric Paris 2015-05-22 21:31:50 UTC
can we get system_u:object_r:svirt_sandbox_file_t:s0 added as the filecontext for /var/lib/kubelet to the docker-selinux package?

can/should we maybe break docker-selinux into it's own package?

Comment 2 Daniel Walsh 2015-05-27 02:10:10 UTC
We could put it in its own package.  But not sure that would buy us much.  You want the /var/lib/kublet writable by all containers?

Comment 3 Eric Paris 2015-05-27 14:04:39 UTC
I'll let you tell me the right label, this is likely not quite it, but the best we can do now.

Lets assume you define a pod that uses an NFS mount as its volume. The kubelet will mount the NFS export inside /var/lib/kubelet/$somedir and will then tell docker to volume mount /var/lib/kubelet/$somedir into the container.

If you define a 'secret' for a container the kubelet will mount tmpfs in /var/lib/kubelet/$somedir and the secret as a file in the tmpfs, and then tell docker to volume mount it into your container.

At this point kube is pretty stupid, it does no/little labeling really. I think we're going to need to move the docker/svirt level knowledge up into kube. (It'll eventually land on pmorie's plate I'd bet) so that kube can mount with good labels that docker can use.

But for now, kubelet does nothing smart...

This is a lot like the label on /var/lib/docker/[something]

Which you know better than me....

Comment 4 Daniel Walsh 2015-05-27 20:26:37 UTC
Well I see a couple of problems here.  docker_var_lib_t would be the label I would add, so it matches and is not writable by the container.  Mounting the tmpfs would end up being tmpfs_t and nfs would probably be nfs_t, unless you are using labeled nfs.  

Volume mounting with the Z,z would solve some problems, at least for the tmpfs_t.

Comment 5 Daniel Walsh 2015-06-02 17:58:43 UTC
Should be in the latest docker-1.7 release.


Note You need to log in before you can comment on or make changes to this bug.