I installed LXD with snap (source here) on Centos 8, and on starting a container, I get this error. I just need a hack around this. Or, is there a config flag (or something similar) for snap to not bother with the security subsystem? (I am not using a mainline kernel because I have some patches in this which I need, its all dev env, I don’t need a production-ready hack for this)
lxc start ready-frog
2020/07/10 12:57:58.062876 cmd_run.go:918: WARNING: cannot create user data directory: failed to verify SELinux context of /root/snap: exit status 1
cannot create SELinux context from context string kernel: Invalid argument,
$ snap version
I can NOT disable SELinux as a workaround because that is what I am working on. Any help?
Welcome. Are you use SELinux is enabled and correctly set up in your system? Can you include the output of
sestatus ? Is this happening when you run
lxc start .. in your terminal? Can you also attach the output of
id -Z ?
From what I can tell, snap-confine (an intermediate process that sets up the sandbox) is running with the
kernel SELinux context. AFAICT this is highly unexpected, either your policy is misconfigured or it’s quite different from the targeted policy shipped with stock CentOS. On top of that the current kernel
4.18.0-193.6.3.el8_2.x86_64, yours is
5.7.0-rc1, so indeed some low level customization?
Thanks @mborzecki for your reply
Yes, I am working on something peculiar on SELinux (namespacing, which is patch work, not in mainline kernels and is prototype level only) and it is happening on running
lxc start or as a matter of fact any
lxc command like
Here is the output of
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33
id -Z (when
snapd throws an error):
You are right, I am working on something lowlevel, which is under dev, just looking for a hack (nasty is also fine as long as I can launch my container). Is there a way you you can help me with?
snap, such issues do not show up. I was wondering whether there is a way to just ignore this in
snap. Thanks in advance.
I think you can build the relevant pieces yourself then. The error you saw comes from this place: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/selinux-support.c#L60 looks like libselinux does not like the current process context. Well,
kernel is kind of special, so I don’t think it’s wrong about that.
Anyways, you can clone the snapd source tree, then:
# hack the source code
The code in the bit I linked is slightly native, and tries to manually set up the conttext for next exec when it is running a service. Something was able to transition to
snappy_confine_t, it means there was a targeted policy for the whole snapd chain applied so far, since we don’t really support sandboxing with SELinux for snap applications, the next exec to a process inside the snap mount namespace will transition to
unconfined_service_t. In your case, you can probably skip the whole setup and return early there.