If we use the new API in the root of the selinux package, functions like:

// ReserveLabel reserves the MLS/MCS level component of the specified label
func ReserveLabel(label string) {
	if len(label) != 0 {
		con := strings.SplitN(label, ":", 4)
		if len(con) > 3 {
			mcsAdd(con[3])
		}
	}
}

do not return the error from mcsAdd().

How do we detect duplicate labels from this or does this matter anymore? Should we handle this in higher layers or should we expand the package a little bit to add functions like:

MustReserveLabel(label string) error { ???

Currently chcon of large directories takes a very long time. We have experimented with kicking off a thread for each directory and recusively calling chown, and have seen serious improvements in speed.
Up to 10 times faster

Here is my experimental code
https://github.com/rhatdan/tools/blob/master/chown.go

It would be nice to use this inside of the selinux library.

Hi I enjoy my container life with podman and have an issue on Gentoo with SELinux targeted environment.

Here is the output of running container from the podman tutorial.

kenya888@xps13 ~ $ sudo podman run -dt -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd
panic: runtime error: index out of range

goroutine 1 [running]:
github.com/projectatomic/libpod/vendor/github.com/opencontainers/selinux/go-selinux.NewContext(0xc42024108b, 0x21, 0xc)
        /var/tmp/portage/app-emulation/podman-9999/work/podman-9999/src/github.com/projectatomic/libpod/vendor/github.com/opencontainers/selinux/go-selinux/selinux.go:300 +0x2af
.
.
.

It seems that the environment which doesn't have the 'range' field (like 's0') in fcontext is not considered in the go-linux.NewContext() (and ReserveLabel() below)

In the Gentoo's SELinux instruction labeling fcontext with targeted type doesn't provide the 'range' field because it isn't MLS/MCS type.

kenya888@xps13 ~/ctr $ LANG=C ls -lZ
total 0
drwxr-xr-x. 1 kenya888 wheel unconfined_u:object_r:user_home_t 42 Feb  6 20:50 lib
drwxr-xr-x. 1 kenya888 wheel unconfined_u:object_r:user_home_t  0 Feb  6 20:49 run

I know it doesn't occur in Fedora/RHEL because they are always provided with 'range' fcontext.
Should I label it to my system even if I don't use the field? I cannot find right information that this field is always needed as SELinux spec.

We can easily reproduce this issue with the code as following.

package main

import (
        "fmt"
        "strings"
)

func main() {
        label := "unconfined_u:object_r:user_home_t"
//      label := "unconfined_u:object_r:user_home_t:s0"
        fmt.Println(label)
        con := strings.SplitN(label, ":", 4)
        fmt.Println(con[3])
}

Is there a way to check using this library if MLS is enabled on a system?

Package name in selinux_test.go is selinux instead of selinux_test. Is it intentionally changed or typo ?

@kolyshkin the following change 86a2c3f seems to cause an issue in the kubernetes typecheck scripts. Please see the output in:
https://prow.k8s.io/view/gcs/kubernetes-jenkins/pr-logs/pull/86975/pull-kubernetes-typecheck/1232997816310173697

The kubernetes PR where we are trying to update to newer selinux package is:
kubernetes/kubernetes#86975 (comment)

For the record the error is:

ERROR(linux/386,linux/arm) vendor/github.com/opencontainers/selinux/go-selinux/selinux_linux.go:118:17: unix.SELINUX_MAGIC (untyped int constant 4185718668) overflows int32
exit status 1
!!! Type Check has failed. This may cause cross platform build failures.
!!! Please see https://git.k8s.io/kubernetes/test/typecheck for more information.

Is a bad data for options in InitLabels(options []string) if the value is the form like {"user:", "role:user_r", "type:", "level:s0:c1,c2"}? Test case does not contain this.

Hope to get help, thanks! : )

/cc @caniszczyk

I noticed that #59 is not in the current (v1.3.0) release, which means that projects using go mod will not automatically get that fix, which is an additional fix to CVE-2019-16884;

changes since v1.3.0: v1.3.0...0089225

Would it be possible to tag a new release? Following SemVer, v1.3.1 is probably most appropriate.

note that runc v1.0.0-rc10 currently vendors 5215b18, so it could be considered to either tag that commit, or to tag current master (which has one additional, but probably minor change: #60)

ping @rhatdan @cyphar @mrunalp PTAL 🤗

I noticed that libselinux implementation tries the default path (/sys/fs/selinux) first (checking its fstype and readonly flag), then the old default (/selinux), and only if that fails it goes on to parse /proc/self/mountinfo in order to find the selinux mount point. The relevant commit is SELinuxProject/selinux@e3cab998b48ab

The implementation in this repo doesn't do that, it parses /proc/self/mountinfo right away (albeit once), the code is here:

Maybe it makes sense to amend this function to try the default first (I guess there's no need to try the old default, no one uses it now). I would create a PR, but it will mess with #20 so I'm filing an issue instead.

Problem

As described in the comment, Relabel() should recursively change the SELinux label on a path and all entries beneath that path.

Currently, it skips symlinks (and instead relabels their targets).

Explanation

1b18907 changed the semantics of setFileLabel() from not-dereferencing to dereferencing symlinks before applying the label change. (It also introduced the non-dereferencing lSetFileLabel(): The setFileLabel/ lSetFileLabel semantics became the same as the one of the kernel syscalls setxattr/lsetxattr.)

Relabel() mentioned above calls (Relabel -> Chcon -> chcon ->) rchcon to get the job done. rchcon recursively calls setFileLabel on the path as well as on each item below.

Solution

This should be changed to lSetFileLabel().

Result

When running Kubernetes (kubelet) 1.23.4 on top of containerD 1.6.0 on a SELinux-enabled system, this causes ConfigMaps to be unusuable by normal Pods:

[root@node ~]# ls -laZR /var/lib/kubelet/pods/2839514d-bc4b-4521-b029-5474a9c96fc5/volumes/kubernetes.io~configmap/config
/var/lib/kubelet/pods/2839514d-bc4b-4521-b029-5474a9c96fc5/volumes/kubernetes.io~configmap/config:
total 0
drwxrwsrwx. 3 root core system_u:object_r:container_file_t:s0:c294,c792 89 Mar 17 21:48 .
drwxr-xr-x. 3 root root system_u:object_r:container_var_lib_t:s0        20 Mar 17 21:48 ..
drwxr-sr-x. 2 root core system_u:object_r:container_file_t:s0:c294,c792 36 Mar 17 21:48 ..2022_03_17_21_48_25.904560199
lrwxrwxrwx. 1 root core system_u:object_r:container_var_lib_t:s0        31 Mar 17 21:48 ..data -> ..2022_03_17_21_48_25.904560199
lrwxrwxrwx. 1 root core system_u:object_r:container_var_lib_t:s0        29 Mar 17 21:48 demo.json -> ..data/demo.json

/var/lib/kubelet/pods/2839514d-bc4b-4521-b029-5474a9c96fc5/volumes/kubernetes.io~configmap/config/..2022_03_17_21_48_25.904560199:
total 4
drwxr-sr-x. 2 root core system_u:object_r:container_file_t:s0:c294,c792  36 Mar 17 21:48 .
drwxrwsrwx. 3 root core system_u:object_r:container_file_t:s0:c294,c792  89 Mar 17 21:48 ..
-rw-r--r--. 1 root core system_u:object_r:container_file_t:s0:c294,c792 350 Mar 17 21:48 demo.json

(In contrast to the directories and normal files, the symlinks have not been relabeled and are therefore not readable by any process running inside of the container.)

This is a proposal to get rid of pullapprove for this repository.

Pullappove was probably added when github did not have its own mechanism to do LGTMs. For quite some time, such a mechanism exists: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/approving-a-pull-request-with-required-reviews

There is also a mechanism to require a certain number of LGTMs before it is possible to merge a PR: https://help.github.com/en/github/administering-a-repository/about-required-reviews-for-pull-requests, although I don't think it is necessary, since all the moderators here are able to count how many green check marks are there in the top left corner of a PR page.

So, unless I am missing something, there is no value that pullapprove adds to what github has.

Please let me know what you think.

Similar discussions: opencontainers/runc#2388, opencontainers/runtime-spec#1057

@kolyshkin @caniszczyk @mrunalp @vbatts @giuseppe @saschagrunert @thaJeztah
FYI

The changes are (v1.8.5...HEAD):

• #159
• #161

The last one is needed to get cri-o/cri-o#5373 out of draft.

Hi all,
thank you for opensourcing this package, I would like to see how should I best this package if I need to set a specific label for my Go program?

In Rocky Linux v9+ a specific selinux label defaul value has changed, causing programs to fail with Segmentation violation - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.0_release_notes/new-features#BZ-2055822

As a result, SELinux users cannot enter commands using libraries that require text relocation, unless the library files have the textrel_shlib_t label.

I wonder, how should I set this label globally for my program and any goroutines it might spawn?

@rhatdan

Can we remove selinux build tag?

This package is matured and does not have any cgo dependency, so it seems safe to build-in the package by default.

The build tag seems introduced in the initial commit moby/moby@4c43566 (moby/moby#4211).

to reproduce: $ TESTFLAGS=-race make test

<snip>
    TestWalk: pwalk_test.go:40: concurrency: 8, files found: 61
--- PASS: TestWalk (0.01s)
=== RUN   TestWalkManyErrors
==================
WARNING: DATA RACE
Read at 0x00c00011a080 by goroutine 17:
  github.com/opencontainers/selinux/pkg/pwalk.WalkN()
      /home/vagrant/go/src/github.com/opencontainers/selinux/pkg/pwalk/pwalk.go:91 +0x1f8
  github.com/opencontainers/selinux/pkg/pwalk.Walk()
      /home/vagrant/go/src/github.com/opencontainers/selinux/pkg/pwalk/pwalk.go:35 +0x321
  github.com/opencontainers/selinux/pkg/pwalk.TestWalkManyErrors()
      /home/vagrant/go/src/github.com/opencontainers/selinux/pkg/pwalk/pwalk_test.go:54 +0x2e8
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:992 +0x1eb

Previous write at 0x00c00011a080 by goroutine 18:
  github.com/opencontainers/selinux/pkg/pwalk.WalkN.func1()
      /home/vagrant/go/src/github.com/opencontainers/selinux/pkg/pwalk/pwalk.go:53 +0xa6

Goroutine 17 (running) created at:
  testing.(*T).Run()
      /usr/local/go/src/testing/testing.go:1043 +0x660
  testing.runTests.func1()
      /usr/local/go/src/testing/testing.go:1285 +0xa6
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:992 +0x1eb
  testing.runTests()
      /usr/local/go/src/testing/testing.go:1283 +0x527
  testing.(*M).Run()
      /usr/local/go/src/testing/testing.go:1200 +0x2ff
  main.main()
      _testmain.go:48 +0x223

Goroutine 18 (finished) created at:
  github.com/opencontainers/selinux/pkg/pwalk.WalkN()
      /home/vagrant/go/src/github.com/opencontainers/selinux/pkg/pwalk/pwalk.go:52 +0x125
  github.com/opencontainers/selinux/pkg/pwalk.Walk()
      /home/vagrant/go/src/github.com/opencontainers/selinux/pkg/pwalk/pwalk.go:35 +0x321
  github.com/opencontainers/selinux/pkg/pwalk.TestWalkManyErrors()
      /home/vagrant/go/src/github.com/opencontainers/selinux/pkg/pwalk/pwalk_test.go:54 +0x2e8
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:992 +0x1eb
==================
    TestWalkManyErrors: pwalk_test.go:61: found 192 of 361 files
    TestWalkManyErrors: testing.go:906: race detected during execution of test
--- FAIL: TestWalkManyErrors (0.05s)
    : testing.go:906: race detected during execution of test
FAIL
FAIL	github.com/opencontainers/selinux/pkg/pwalk	0.069s
FAIL
make: *** [Makefile:48: test] Error 1

As a consumer of this, it took me quite a while to realize that all of the projects where I'm using it were only using the stub code path because of the undocumented selinux build tag.

I'm going to open up a PR as well, but wanted to doc this as an issue first.

At least build and run unit tests?

Go modules require that semver is used. I need to rewrite a go module path to the labels package in this repo:

replace github.com/opencontainers/runc/libcontainer/label => github.com/opencontainers/selinux/go-selinux/label v1.2

However, version 1.2 is incompatible with go modules and I can't do this rewrite. If I pin to you're 1.0.0 tag, the labels package appears to not exist yet, which also isn't going to work.

Here is the error go gives when I attempt to rewrite label package dependencies to your repository: /Users/egreer200/git/kuberhealthy/pkg/go.mod:9: invalid module version github.com/opencontainers/selinux/go-selinux/label: no matching versions for query "v1.2"

Also, just ot be sure, github.com/opencontainers/runc/libcontainer/label was moved to github.com/opencontainers/selinux/go-selinux/label, right?

Some changes went into master and are not yet tagged in a release; v1.6.0...master

No major changes, but it'd be nice to have go.mod depend on a tagged version of willf/bitset;

• #113 Clarify documentation for Set{Task,Exec}Label
• #114 go.mod: update willf/bitset v1.1.11
• #115 travis: add go 1.15, rm unsupported versions

@rhatdan @kolyshkin @mrunalp ptal

Currently we're relying on string parsing for setting selinux labels. This requires runtime checking and is prone to error.
It would be good if the package provided a strongly typed object for interacting with.

Swarmkit uses this:

type SELinuxContext struct {
	Disable bool

	User  string
	Role  string
	Type  string
	Level string
}

Hey, can we please draft a new release to fix the 32bit build issue? This also hinders us in upgrading to buildah to v1.14.1.

Podman failed to mount runtime directory for rootless netns: no such file or directory. These are the logs I could find related to podman in /var/log/messages: http://dpaste.com/FRZSBJKZL
Podman related entries in audit.log: http://dpaste.com/4BEM47HHL
More on the issue here: containers/podman#13703

I am currently going through Podman's dependencies (updating the vendor.conf) trying to pin them to releases when possible and available. Some distribution, Debian in particular, are very conservative regarding go packaging as many libraries don't have any release (or no semantic versioning).

Can we tag a new release?

The default behavior for rootless podman is to create a running container that transitions from the user's SELinux user and role to system_u:system_r. Instead, the default behavior should be to keep the user's user and role when the container process is created.

This is showing to be problematic in refpolicy, where userdomains do not have the can_change_object_identity attribute, and thus cannot relabel files that do not match their user. An unprivileged user can create a container with rootless podman with shared files in the container, which will cause the files to become relabeled to system_u:object_r:container_file_t:MCS, and the user can no longer relabel these files because of SELinux constraints (staff_u != system_u).

Expected behavior:

$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023
$ podman run --rm -it alpine:latest sh
...
$ ps -Z | grep container_t
staff_u:staff_r:container_t:s0:c556,c718 1051869 pts/0 Ss+   0:00 sh

Actual behavior:

$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023
$ podman run --rm -it alpine:latest sh
...
$ ps -Z | grep container_t
system_u:system_r:container_t:s0:c556,c718 1051869 pts/0 Ss+   0:00 sh

@rhatdan @runcom We can move the SELinux policy for containers to this repo for a one stop for all things SELinux for containers.

When I tried to start a container with SELinux labeling for volume, I got the following error and could not start a container.

$ docker run --log-driver=journald -d --name=kubelet --read-only --network=host \
--uts=host --pid=host --privileged \
--tmpfs=/tmp --volume=/var/lib/kubelet:/var/lib/kubelet:rshared,z \
quay.io/cybozu/kubernetes:1.25.6.1 kubelet

docker: Error response from daemon: 
error setting label on mount source '/var/lib/kubelet': 
lstat /var/lib/kubelet/seccomp/2/pwalk-test-1270530707/d-2753637893/f-1857926114: no such file or directory.

I think this error was returned from pkg/pwalk in opencontainers/selinux.
I found that the error lstat no such file or direcotry is returned if a file is deleted while filepath.Walk of the pwalk function is retrieving the list of files in a directory.
In my environment, it is possible that files under the target directory are frequently deleted during the process of SELinux labeling.
I think it is undesirable behavior to return an error, even if it is a specific environment.
How about adding error handling to make it work in such environment?
https://github.com/opencontainers/selinux/blob/main/pkg/pwalk/pwalk.go#L88C2-L91

Environments.

• docker version: v20.10.18
• opencontainers/selinux version: v1.8.0

To Reproduce.

1. Add a function for testing to pwalk_test.go
2. Create a direcotry and files for testing using the prepareTest function
3. Execute the Walk function on the created direcotry.

err = Walk(dir,
		func(p string, i os.FileInfo, e error) error {
			return nil
		})

4. Deletes all files under a particular directory during execution of the pwalk.Walk function.
5. Get an error lstat <directory/file name> no such file or directory

delete pwalk-test-2649712757/d-1782752606 directory
--- FAIL: TestRemoveFile (0.01s)
    pwalk_test.go:55: lstat pwalk-test-2649712757/d-1782752606/d-2791693006: no such file or directory
FAIL
exit status 1
FAIL    github.com/opencontainers/selinux/pkg/pwalk     0.011s

Could you please clear up the copyright status? There is no copyright header in any code file and in the LICENCE it is stated as:

Copyright {yyyy} {name of copyright owner}