Add --security-opts options to allow user to customize container labels.

[rhatdan]

security-opts will allow you to customise the way that a labeling system like
SELinux will run on a container.

--security-opt="user:USER"  : Set the label user for the container
--security-opt="role:ROLE"  : Set the label role for the container
--security-opt="type:TYPE"  : Set the label type for the container
--security-opt="level:LEVEL"  : Set the label level for the container
--security-opt="disabled"  : Turn off label confinement for the container

Since we are passing a list of string options instead of a space separated
string of options, I will change function calls to use InitLabels instead of
GenLabels. Genlabels interface is Depracated.

Docker-DCO-1.1-Signed-off-by: Dan Walsh dwalsh@redhat.com (github: rhatdan)

[crosbymichael]

@rhatdan can you give me a couple of examples to test this one my machine? I guess I can set some options then look at the process labels?

[jamtur01]

Docs LGTM

[SvenDowideit]

I would love to have an example of how and why to use this in the documentation - otherwise, yup, Docs LGTM too

[rhatdan]

I added some examples.

[rhatdan]

If you wanted to try out the svirt_apache_t example, here is some simple policy I threw together for it.
Create a file called svirt_apache.te with the following content.
#==================================================================
policy_module(svirt_apache,1.0)
virt_sandbox_domain_template(svirt_apache)

allow svirt_apache_t self:tcp_socket create_stream_socket_perms;
allow svirt_apache_t self:udp_socket create_socket_perms;
corenet_tcp_bind_generic_node(svirt_apache_t)
corenet_udp_bind_generic_node(svirt_apache_t)
corenet_tcp_bind_http_port(svirt_apache_t)
corenet_udp_bind_http_port(svirt_apache_t)

sysnet_dns_name_resolve(svirt_apache_t)
#======================================================

Now run

make -f /usr/share/selinux/devel/Makefile svirt_apache.pp

semodule -i svirt_apache.pp

Now you should be ready to use the svirt_apache_t type.

docker run --label-opt type:svirt_apache_t -v /usr:/usr --rm -ti fedora /bin/sh
sh-4.3# nc -l 80
^C
sh-4.3# nc -l 22
Ncat: bind to :::22: Permission denied. QUITTING.

Of course there is probably more policy you would need to write to fully get apache to run in this environment, but it is a quick example of how to do it.

[SvenDowideit]

This :)

[SvenDowideit]

merci for the example - and the one in here. @fredlf it would be great if we can work out how to flesh out the Apache example Dan's given us here post merge.

Docs LGTM - minor nits can be carried by whomever touches the PR with git next :)

[vieux]

Code LGTM, is there a way to add some test ?

[rhatdan]

@vieux Do we have any way to test docker run? Do you have examples?
For example running the following and seeing if there is output would be a valid test.

docker run --rm -ts --label-opt level:s0:c0,c100 ps -eZ | grep s0:c0,c100

docker run --rm -ts --label-opt disable ps -eZ | grep -v svirt

Would be another.

[cpuguy83]

@rhatdan See integration-cli for docker run tests.

[wyaeld]

@rhatdan I know you're looking at this from a SELinux perspective, but I'm wondering whether @smarterclayton can offer an opinion on whether the same functionality can do double-duty for a label-based orchestration tech like kubernetes.

It would be fantastic if the --label-opt functionality can solve both use-cases at once, but if order for that to work as I understand it, you need the ability to both add and remove labels as the container is running, as well as when you launch.

[rhatdan]

Modifying a container while it is running, really has no precedent from docker, as far as I know. I know that google and Red Hat have been working on docker exec, but this is about adding a process to a running container.

The reason I called this --label-opt rather then --selinux-opt was to allow other labeling systemd like smack to be able to use the same options. But if you can think of other tools using it, that is fine with me. As long as we don't overload the name value pairs.

[smarterclayton]

I know there was a desire to have things like labels in Docker (metadata related to a container that could be set by consumer applications for identification / tweaking), but I suspect it would not overlap with selinux labels unless there was a really strong 1-1 connection, because of side effects (i.e. you use a label to identify a container that means something different in selinux).

[thockin]

Yeah, we'd really like to be able to attach semi-arbitrary metadata to containers (and be able to query that back), but this seems like it is coupled to selinux at a low level, unless I am misunderstanding

[thaJeztah]

@thockin isn't this what you're looking for: #7470 ?

[crosbymichael]

That is a good point. Maybe a better flag name for this feature could be something like --security-label or --selinux-label ??

[wyaeld]

Main questions seem to be around terminology.

SELinux needs a concept of immutable labels which are set at container startup, and can't be modified.

Orchestration technologies - eg. Kubernetes, and if I'm understand correctly, openshift in future, look for a more dynamic labelling feature that can be added and removed. Normally I'd think of that as Tags, but Docker already has a meaning for Tag, and Google calls in labels in their context.

https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/labels.md

I guess the points I'm aiming for are:
a) do we know of more label-related use-cases other than the security and runtime orchestration ones?

b) if there are only 2 that are considered critical, should they have slightly more targetted names?

Even without kubernetes running in my environments, I'd really like to be able to easily label running containers with their current status/purpose etc, and script my other parts of my systems to recognise that. A particular deployment might be an RC, and then after testing I want to promote it to production and rebalance over it, without making any changes to the actual running state of the containers.

That would also potentially require adding/removing labels to interact with the emitted docker events, which again might be quite different than this specific use-case.

Just brainstorming, but the above feature is still K,V pairs, so has the overall interface required. Would it overcomplicate things too much if the labels concept extended to having a namespace type feature? Docker already does :repo/:image/[:tag]

what if for @rhatdan use case this was

--label-opt="selinux:user:USER" : Set an selinux label user for the container

and orchestration techs etc could do

--label-opt="kubernetes:env:PRODUCTION" or

--label-opt="pod:env:PRODUCTION" --label-opt="pod:tier:FRONTEND"

Then specific 3rd party services, like selinux, kubernetes, openshift (which is using pods in future I think) or anything else could pay attention only to the labels that correspond to their namespace.

[rhatdan]

I agree with @thaJeztah, what you are describing is more the META patch which I have a pull request available. My pull request is more about labeling the content of the image, you could easily extend that concept to add labels or META data about the running container.

@crosbymichael I do not want to move SElinux into the label, since I think other security labeling systems could take advantage of the options. Maybe security-opt might be better to prevent confusion like the kubernetes guys are having.

[bfirsh]

Agree with @crosbymichael, this should be called something like --security-option to avoid confusion with more generic labels.

[rhatdan]

I have no problem, except that --security-option might lead people to look at configuring capabilities with it. But we are looking to add a new patch with libseccomp functionality, and we are going to want options for that. I will change to --security-opt flag.

[crosbymichael]

Maybe it should have something like

--security-opt label:user:USER

So that it sends these options to the labeling system

[rhatdan]

Well I changed to --security-opt, but did not do the label:user:USER change.

[rhatdan]

@crosbymichael Switched to using

--security-opt label:user:USER

Since we are working on the seccomp subsystem, this made sense.

[crosbymichael]

Ok, thanks. I'll review this week

[crosbymichael]

ping @shykes please review this new flag. We can also use this to set apparmor profiles via --security-opt apparmor:unconfined or such

[rhatdan]

@crosbymichael @shykes @cpuguy83 Anything I can do to move this one along?

[rhatdan]

In order to get the --ipc command to work well with SELinux, I will need this patch to be merged?
@crosbymichael @tianon @shykes @SvenDowideit Can we get this in before 3.0?

[crosbymichael]

Ok, thanks for letting us know

[vieux]

busybox compiled ps doesn't support -Z

[fredlf]

Some docs issues. Please LMK if my comments aren't clear.

[vieux]

I don't see where this one is filled from config.SecurityOpt

[crosbymichael]

@rhatdan

@vieux and I will take over this PR and get it merged for 1.3. We will take care of updating the docs as well as adding apparmor support for distros that support it.

Thanks!

[vieux]

PR replaced by #8299, @fredlf your changes are in there.