More open but not privileged domain?

[cgwalters]

I'm using Fedora Atomic Workstation:

fedora-ws-27:fedora/27/x86_64/workstation
Version: 27.20171110.n.1 (2017-11-10 12:05:52)

And previously my "devshell" container was run with --privileged, which I'm trying to get away from for obvious reasons. However, my daily development involves testing rpm-ostree which uses bwrap. I am running with --security-opt seccomp:unconfined since I obviously want to be able to use strace/gdb in my devshell. However, the default SELinux policy denies a lot of things that one wants to do when creating user namespaces.

type=AVC msg=audit(1510840822.440:772): avc: denied { mount } for pid=27009 comm="bwrap" name="/" dev="tmpfs" ino=313846 scontext=system_u:system_r:container_t:s0:c47,c237 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem permissive=0

Now, things do work with --security-opt label:disable. But I actually want some of the protections of SELinux here. So, maybe something like --security-opt label:unconfined? Basically the way I think of this is it should have a quite similar set of permissions as a default unprivileged login shell i.e. unconfined_t.

[rhatdan]

security-opt label:disable does not disable SELinux, it just disables SELinux separation for the container running, the container as spc_t, which is pretty much the same as unconfined_t.

You could also attempt to run --security-opt label=type:unconfined_t which should get close to what you want if it works.

[cgwalters]

Yeah, but spc_t is very privileged right?

$ sudo docker run --security-opt seccomp:unconfined --security-opt label:type:unconfined_t --rm -ti --entrypoint bash  cgwalters/fdev
standard_init_linux.go:178: exec user process caused "permission denied"

type=AVC msg=audit(1510848928.752:945): avc:  denied  { transition } for  pid=18742 comm="runc:[2:INIT]" path="/usr/bin/bash" dev="dm-1" ino=549992339 scontext=system_u:system_r:container_runtime_t:s0 tcontext=system_u:system_r:unconfined_t:s0:c271,c960 tclass=process permissive=0

[cgwalters]

There's a whole other topic here in that I am increasingly feeling Docker isn't the right solution for "user pet containers" as I really want the container to be a child process of my login session for example. But...that's a whole other thing.

[rhatdan]

cgwalters, kpod might give you something closer.

[rhatdan]

We now have container_userns_t domain whose goal is to satisfy these needs.

[rhatdan]

@cgwalters https://github.com/containers/udica is an effort to facilitate this.