New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

If caller specifies label overrides, don't override security options #30652

Merged
merged 1 commit into from Mar 28, 2017

Conversation

@rhatdan
Contributor

rhatdan commented Feb 1, 2017

If a caller specifies an SELinux type or MCS Label and still wants to
share an IPC Namespace or the host namespace, we should allow them.
Currently we are ignoring the label specification if ipcmod=container
or pidmode=host.

Signed-off-by: Daniel J Walsh dwalsh@redhat.com

- What I did

- How I did it

- How to verify it

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

Show outdated Hide outdated daemon/create.go
@runcom

This comment has been minimized.

Show comment
Hide comment
@runcom
Member

runcom commented Feb 15, 2017

LGTM ping @cpuguy83 @mrunalp

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Feb 22, 2017

Contributor

Not sure I feel comfortable reviewing this change...

@justincormack ?

Contributor

cpuguy83 commented Feb 22, 2017

Not sure I feel comfortable reviewing this change...

@justincormack ?

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah
Member

thaJeztah commented Feb 28, 2017

ping @justincormack PTAL

If caller specifies label overrides, don't override security options
If a caller specifies an SELinux type or MCS Label and still wants to
share an IPC Namespace or the host namespace, we should allow them.
Currently we are ignoring the label specification if ipcmod=container
or pidmode=host.

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
@rhatdan

This comment has been minimized.

Show comment
Hide comment
@rhatdan

rhatdan Mar 17, 2017

Contributor

Any chance we can get people to look at this? This is a serious problem with kubernetes use of docker.

Contributor

rhatdan commented Mar 17, 2017

Any chance we can get people to look at this? This is a serious problem with kubernetes use of docker.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Mar 17, 2017

Contributor

Is this function really more of a getSelinuxLabel? If so, LGTM.
generateSecurityOpt is throwing me off because --security-opt is used for a lot more.

Contributor

cpuguy83 commented Mar 17, 2017

Is this function really more of a getSelinuxLabel? If so, LGTM.
generateSecurityOpt is throwing me off because --security-opt is used for a lot more.

@rhatdan

This comment has been minimized.

Show comment
Hide comment
@rhatdan

rhatdan Mar 17, 2017

Contributor

I think we could rename it to generateSELinuxLabel, or duplicateSELinuxLabel.
The idea is that docker generates SELinux labels on the fly for container separation, but if the container is joining an existing containers IPC Namespace you want to use the same label as you are joining, if you are using the pid host namespace, then you will need to run with no labels, since SELinux isolation will break stuff.

BUT if the caller has specified an SELinux Label to use, docker should just use the label, figuring the caller knows what it wants.

This is important for POD situations, where you could potentially want to containers sharing content but running with different SELinux labels.

Imaging you have a daemon container, but you another container to the pod that you want to have limited access, it can not use the network, or it can look at the process but not examine any content. Bottom line it gives better flexibility to the caller of the docker-engine to specify the labels that it wants.

Contributor

rhatdan commented Mar 17, 2017

I think we could rename it to generateSELinuxLabel, or duplicateSELinuxLabel.
The idea is that docker generates SELinux labels on the fly for container separation, but if the container is joining an existing containers IPC Namespace you want to use the same label as you are joining, if you are using the pid host namespace, then you will need to run with no labels, since SELinux isolation will break stuff.

BUT if the caller has specified an SELinux Label to use, docker should just use the label, figuring the caller knows what it wants.

This is important for POD situations, where you could potentially want to containers sharing content but running with different SELinux labels.

Imaging you have a daemon container, but you another container to the pod that you want to have limited access, it can not use the network, or it can look at the process but not examine any content. Bottom line it gives better flexibility to the caller of the docker-engine to specify the labels that it wants.

@rhatdan

This comment has been minimized.

Show comment
Hide comment
@rhatdan

rhatdan Mar 28, 2017

Contributor

What do you guys want me to do with this? Change the function names or allow it to go in as is?

Contributor

rhatdan commented Mar 28, 2017

What do you guys want me to do with this? Change the function names or allow it to go in as is?

@vdemeester

LGTM 🐯
I guess we can go as is.

@cpuguy83 cpuguy83 merged commit b6cb416 into moby:master Mar 28, 2017

6 checks passed

dco-signed All commits are signed
experimental Jenkins build Docker-PRs-experimental 31822 has succeeded
Details
janky Jenkins build Docker-PRs 40443 has succeeded
Details
powerpc Jenkins build Docker-PRs-powerpc 536 has succeeded
Details
windowsRS1 Jenkins build Docker-PRs-WoW-RS1 11523 has succeeded
Details
z Jenkins build Docker-PRs-s390x 424 has succeeded
Details

@GordonTheTurtle GordonTheTurtle added this to the 17.05.0 milestone Mar 28, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment