Default Snapd installation with SELinux causes AVC failures

[Joe McCall]

This was originally reported here: https://github.com/fedora-selinux/selinux-policy/issues/237.

Output of `snap version`:
```
snap 2.36.3-1.fc29
snapd 2.36.3-1.fc29
series 16
fedora 29
kernel 4.19.13-300.fc29.x86_64
```

Steps to reproduce:

* Ensure SELinux is enforcing
* `sudo dnf install snapd`
* `snap version`

Expected results:
The snap version is printed with zero AVC denials.

Actual results:
The following AVC denials occur:
```
----
type=AVC msg=audit(01/07/2019 08:27:58.993:858) : avc: denied { read write } for pid=24514 comm=mount name=loop-control dev="devtmpfs" ino=18081 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:loop_control_device_t:s0 tclass=chr_file permissive=1
----
type=AVC msg=audit(01/07/2019 08:27:58.993:859) : avc: denied { open } for pid=24514 comm=mount path=/dev/loop-control dev="devtmpfs" ino=18081 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:loop_control_device_t:s0 tclass=chr_file permissive=1
----
type=AVC msg=audit(01/07/2019 08:27:58.993:860) : avc: denied { ioctl } for pid=24514 comm=mount path=/dev/loop-control dev="devtmpfs" ino=18081 ioctlcmd=0x4c82 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:loop_control_device_t:s0 tclass=chr_file permissive=1
----
type=AVC msg=audit(01/07/2019 08:27:58.993:861) : avc: denied { read write } for pid=24514 comm=mount name=loop0 dev="devtmpfs" ino=173360 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=1
----
type=AVC msg=audit(01/07/2019 08:27:58.993:862) : avc: denied { open } for pid=24514 comm=mount path=/dev/loop0 dev="devtmpfs" ino=173360 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=1
----
type=AVC msg=audit(01/07/2019 08:27:58.993:863) : avc: denied { ioctl } for pid=24514 comm=mount path=/dev/loop0 dev="devtmpfs" ino=173360 ioctlcmd=0x4c00 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=1
----
type=AVC msg=audit(01/07/2019 08:27:59.006:864) : avc: denied { mounton } for pid=24514 comm=mount path=/tmp/sanity-mountpoint-212486593 dev="tmpfs" ino=346409 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=1
----
type=AVC msg=audit(01/07/2019 08:27:59.013:865) : avc: denied { getattr } for pid=24516 comm=umount name=/ dev="loop0" ino=2 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem permissive=1
```

Please let me know if you need any other details.

[Maciej Borzecki (maciek-borzecki)]

Thanks for the report. The work to address this is ongoing, you can track it here: https://github.com/snapcore/snapd/pulls?q=is%3Apr+is%3Aopen+label%3ASELinux Since 2.37 release is near, I'm afraid the full set of fixes won't be available until 2.38.

[Wes Turner (wes-turner)]

Looks like "SELinux is preventing umount from 'getattr' accesses on the filesystem /." may contain reports of one of these AVC denials: https://bugzilla.redhat.com/show_bug.cgi?id=1597878

Would a run of `audit2allow` be sufficient to update the policy?

This is sufficient to cause AVC denials:

```bash
sudo dnf install -y snapd
```

... This causes quite a few more; which is tragically unfortunate.

```bash
snap install microk8s --classic
```

Is snap fundamentally incompatible with MAC: Mandatory Access Control systems like SELinux?
Or would it be necessary to require package authors to include SELinux labels?

[Maciej Borzecki (maciek-borzecki)]

See my previous comment. Things have slipped a bit and the current target for the fixes is 2.39.

[Zygmunt Krynicki (zyga)]

Dear Maciej, can you please update this bug with relevant information. What is the situation in snapd 2.41?