Skip to content
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

Docker should not accept conflicting selinux labels #31328

Open
coeki opened this issue Feb 24, 2017 · 3 comments
Open

Docker should not accept conflicting selinux labels #31328

coeki opened this issue Feb 24, 2017 · 3 comments
Labels
area/security/selinux kind/enhancement Enhancements are not bugs or new features but can improve usability or performance.

Comments

@coeki
Copy link

coeki commented Feb 24, 2017

Description
Docker accepts 2 conflicting security-opt types, only the last one given is used as the process label.

Steps to reproduce the issue:

  1. docker run -ti --security-opt label=type:container_t --security-opt label=type:spc_t fedora sleep 5

Describe the results you received:

docker inspect results in:

"MountLabel": "system_u:object_r:container_file_t:s0:c118,c497",
"ProcessLabel": "system_u:system_r:spc_t:s0:c118,c497",

snip

"SecurityOpt": [
"label=type:container_t",
"label=type:spc_t"

Describe the results you expected:

Throw an error and make sure there can only be one type of each of the selinux labels, type, role, user, level, disable

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Docker version 1.12.6, build ae7d637/1.12.6

Output of docker info:

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 13
Server Version: 1.12.6
Storage Driver: devicemapper
Logging Driver: journald
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: null host overlay bridge
Swarm: inactive
Runtimes: oci runc
Default Runtime: oci
Security Options: seccomp selinux
Kernel Version: 4.9.9-200.fc25.x86_64
Operating System: Fedora 25 (Cloud Edition)
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 2
CPUs: 2
Total Memory: 992.6 MiB
Name: master-01
ID: O6ZD:L2TB:XTDS:GBOW:YUHF:YXLX:TDKU:7TF3:V67I:62I7:RQRF:CCGV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
 127.0.0.0/8
Registries: docker.io (secure)

Additional environment details (AWS, VirtualBox, physical, etc.):
virtualbox

@coeki
Copy link
Author

coeki commented Feb 24, 2017

cc @rhatdan @eparis @luxas @runcom

@thaJeztah thaJeztah added area/security/selinux kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. labels Feb 27, 2017
@coeki
Copy link
Author

coeki commented Sep 28, 2023

Hi,
After an update to related bugs, still confused. However my original issue seems to still exists in latest version.

Client: Docker Engine - Community
 Version:           24.0.6
 API version:       1.43
 Go version:        go1.20.7
 Git commit:        ed223bc
 Built:             Mon Sep  4 12:33:18 2023
 OS/Arch:           linux/amd64
 Context:           default

[snip]

"SecurityOpt": [
"label=type:container_t",
"label=type:spc_t"

Not sure how to proceed.

@thaJeztah
Copy link
Member

I had a very brief look at the code that sets these labels, and that looks to be happening in parseSecurityOpt;

securityOptions.ProcessLabel, securityOptions.MountLabel, err = label.InitLabels(labelOpts)

That code depends on the label.InitLabels from the github.com/opencontainers/selinux module, which has an error-return, so perhaps the best place to handle conflicting labels would be there; https://github.com/opencontainers/selinux/blob/1b71cb461a20c1150d77d3858609ead9e816afd8/go-selinux/label/label_linux.go#L23-L29

@rhatdan @kolyshkin any thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/security/selinux kind/enhancement Enhancements are not bugs or new features but can improve usability or performance.
Projects
None yet
Development

No branches or pull requests

2 participants