What could cause this warning? I’m on Ubuntu 19.04 now
cmd_run.go:876: WARNING: cannot create user data directory: failed to verify SELinux context
Tha’s unexpected. Is your Ubuntu somehow using SELinux?
Can you post the output of the following commands?
snap debug sandbox-featuressnap versionsnap list |grep -e core -e snapdmount |grep selinux
Ah, you made a point, I didn’t remember that regular Ubuntu has selinux enabled. I see other reports said that this is only happens on 5.0 kernels. I have mainline kernel because my mouse has problems which fixed in 5.0.8. I’ll try stock kernel tomorrow.
alvin@alvin-BM1AF:~$ snap debug sandbox-features
confinement-options: classic devmode
dbus: mediated-bus-access
kmod: mediated-modprobe
mount: freezer-cgroup-v1 layouts mount-namespace per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles stale-base-invalidation
seccomp: bpf-argument-filtering kernel:allow kernel:errno kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap kernel:user_notif
udev: device-cgroup-v1 tagging
alvin@alvin-BM1AF:~$ snap version
snap 2.38+19.04
snapd 2.38+19.04
series 16
ubuntu 19.04
kernel 5.0.9-050009-generic
alvin@alvin-BM1AF:~$ snap list |grep -e core -e snapd
core 16-2.38 6673 stable canonical* core
core18 20190409 941 stable canonical* base
alvin@alvin-BM1AF:~$ mount |grep selinux
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)This is bit puzzling. You’re running a mainline kernel, which comes up with SELinux enabled, but actually have no policy defined. Things that see that SELinux is enabled and try to use that will fail, probably in some interesting ways. I would suspect there’s more trouble from snapd ahead too.
For starters, strict confinement is not supported, because AppArmor appears to be disabled, so you do not benefit from sandboxing of snaps.
The upcoming snapd release 2.39, may also cause trouble as we assume that you actually have a SELinux policy if you boot with SELinux enabled (why would it be otherwise?). In which case, installation of new snaps will probably fail.
If you need to use a mainline kernel, please try to use a sensible config that would match the userland.
1 Like
when you say ‘mainline’, do you mean one of the ones from https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0.8/ ? (those should mostly work afaik?)
Maybe we can work around this somehow. Can you provide the output of the following commands?
cat /sys/fs/selinux/policyversod -x /sys/fs/selinux/statussestatusls /etc/selinux/targeted
alvin@alvin-BM1AF:~$ cat /sys/fs/selinux/policyvers
31alvin@alvin-BM1AF:~$ od -x /sys/fs/selinux/status
0000000 0001 0000 0000 0000 0000 0000 0000 0000
0000020 0001 0000
0000024
alvin@alvin-BM1AF:~$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: default
Current mode: permissive
Mode from config file: permissive
Policy MLS status: disabled
Policy deny_unknown status: denied
Memory protection checking: requested (insecure)
Max kernel policy version: 31
alvin@alvin-BM1AF:~$ ls /etc/selinux/targeted
ls: cannot access ‘/etc/selinux/targeted’: No such file or directory
Thanks. I’ve left a note under the github ticket as well.
I would strongly suggest using a kernel that is known to work with the userspace. Perhaps getting in touch with poeple that maintain the PPA and letting them know would be useful too.
1 Like
Confirmed that stock kernels does not have this problem.
As a workaround, install selinux-policy-default, and set SELINUX=disabled in /etc/selinux/config, like so:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
...
Then reboot the system.
1 Like
since these kernels seem to show up more often here recently, a quote from
“These kernels are not supported and are not appropriate for production use.”
people using such kernels for more than verifying upstream fixes should really keep in mind that they do not receive any security support/fixes and might have bugs a tested ubuntu kernel does not have.
Hi there…
“me too!”
I have Ubuntu 19.04 presently. Before I had the same problem with Ubuntu 18.10.
I don’t intentionally wish to be using SELinux … As I understand the world Ubuntu and Snaps are using AppArmor.
Do they not do the same thing?
So far, when using software I find it better to just choose one way of doing things; else-wise trying two systems to do more or less the same thing always leads to conflicts, confusion and frustration.
Is there some way to just permit a snap to be a snap an skip this alternative lifestyle?
many thanks in advance … p
are you using an ubuntu kernel (that should definitely default to apparmor, enabling selinux with an ubuntu kernel requires some manual tinkering) ?
what does
snap version
return ?
I have retried this activity using Ubuntu 20.10 and the current snap version.
$ snap --version
snap 2.48+20.10
snapd 2.48+20.10
series 16
ubuntu 20.10
kernel 5.8.0-36-generic
And reinstalled LXD. It chugs along for a little bit and then dies.
$ sudo snap install lxd --channel=stable
error: cannot perform the following tasks:
- Run install hook of “lxd” snap if present (run hook “install”: cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_XNXKcV//dev: No such file or directory)
The directory mentioned actually exists. However I have no permission to the directory.
$ ls -ld /tmp/snap.rootfs_XNXKcV
drwx------ 2 root root 4096 Jan 11 13:11 /tmp/snap.rootfs_XNXKcV
Since the install command was run with sudo, I am surprised about that!