Bug 1879585

We should also fix the file context patterns for /run/stratisd/ directory:

# restorecon -Rv /run
Relabeled /run/stratisd/keyfiles from system_u:object_r:stratisd_var_run_t:s0 to system_u:object_r:var_run_t:s0
# service stratisd start
Redirecting to /bin/systemctl start stratisd.service
# service stratisd status
Redirecting to /bin/systemctl status stratisd.service
● stratisd.service - Stratis daemon
   Loaded: loaded (/usr/lib/systemd/system/stratisd.service; enabled; vendor pr>
   Active: active (running) since Tue 2021-02-16 22:15:26 CET; 2s ago
     Docs: man:stratisd(8)
 Main PID: 8800 (stratisd)
    Tasks: 1 (limit: 11379)
   Memory: 2.1M
   CGroup: /system.slice/stratisd.service
           └─8800 /usr/libexec/stratisd --log-level debug

Feb 16 22:15:26 linux systemd[1]: Starting Stratis daemon...
Feb 16 22:15:26 linux stratisd[8800]: [2021-02-16T21:15:26Z INFO  libstratis::s>
Feb 16 22:15:26 linux stratisd[8800]: [2021-02-16T21:15:26Z INFO  libstratis::s>
Feb 16 22:15:26 linux stratisd[8800]: [2021-02-16T21:15:26Z INFO  libstratis::e>
Feb 16 22:15:26 linux systemd[1]: Started Stratis daemon.
Feb 16 22:15:26 linux stratisd[8800]: [2021-02-16T21:15:26Z INFO  libstratis::s>
# restorecon -Rv /run
Relabeled /run/stratisd/keyfiles from system_u:object_r:tmpfs_t:s0 to system_u:object_r:var_run_t:s0
#

After stopping the service, the restorecon produces a different output:

# restorecon -Rv /run/
Relabeled /run/stratisd/keyfiles from system_u:object_r:stratisd_var_run_t:s0 to system_u:object_r:var_run_t:s0
#

(In reply to Milos Malik from comment #3)
> After stopping the service, the restorecon produces a different output:
> 
> # restorecon -Rv /run/
> Relabeled /run/stratisd/keyfiles from
> system_u:object_r:stratisd_var_run_t:s0 to system_u:object_r:var_run_t:s0
> #

Milos, is there anything that the Stratis team needs to do here, please advise, thank you.

(In reply to Dennis Keefe from comment #4)

> Milos, is there anything that the Stratis team needs to do here, please
> advise, thank you.

We know that stratisd service creates at least 1 file under /run/stratisd.
SELinux policy, which now misses at least 1 file context pattern, needs to be improved, so that the correct SELinux label (stratisd_var_run_t) on /run/stratisd/keyfiles remains there even after calling the restorecon tool.

We would like to know if the stratisd service creates files/directories/sockets somewhere else? For example: under /var or /etc.
If it does, we would like to know the locations of these objects.

This bz is for RHEL 8.4 which include Stratis 2.3.0 release. I expect that for RHEL 8.5, where Stratis 2.4 release is landing there will have to be further updates to the selinux config since that release includes stratisd-min, which uses a different IPC mechanism. If it is appropriate a new bz should be filed for that.

For RHEL 8.4 (Stratis 2.3.0) we will review and give you a list.

Hi Milos,
For a little bit more context, /run/stratisd/keyfiles is a workaround that will eventually go away once https://bugzilla.redhat.com/show_bug.cgi?id=1862173 is resolved. A couple notes:

* The mount at /run/stratisd/keyfiles should stay mounted for the lifetime of the stratisd running but will be unmounted, destroyed, recreated, and remounted if stratisd is restarted.
* Under /run/stratisd/keyfiles, stratisd will mount other filesystems in a private mount namespace. I'm not entirely sure how this will interact with SELinux.

This mount point is the only file or mount point that I've added so if everything else is appropriately handled in the current SELinux policy, I think this should be the only new case that needs to be handled for this release. Let me know if you have any other questions!

(In reply to John Baublitz from comment #7)
> Hi Milos,
> For a little bit more context, /run/stratisd/keyfiles is a workaround that
> will eventually go away once
> https://bugzilla.redhat.com/show_bug.cgi?id=1862173 is resolved.

John,

I see your bz has been resolved, but in current RHEL 8 the runtime dir is still in place:

# rpm -q stratisd
stratisd-2.4.2-2.el8.x86_64
# grep /run/stratis /proc/mounts
tmpfs /run/stratisd/keyfiles tmpfs rw,seclabel,relatime,size=1024k 0 0
# ls -lZa /dev/stratis
ls: cannot access '/dev/stratis': No such file or directory

The service as such starts fine.

Has something changed, or do we just need to set up something for the stratisd service?

> A couple
> notes:
> 
> * The mount at /run/stratisd/keyfiles should stay mounted for the lifetime
> of the stratisd running but will be unmounted, destroyed, recreated, and
> remounted if stratisd is restarted.
> * Under /run/stratisd/keyfiles, stratisd will mount other filesystems in a
> private mount namespace. I'm not entirely sure how this will interact with
> SELinux.
I can't see any further AVC denials.

Hi Zdenek!
This directory will only be created if you create a pool and filesystem. It is handled by udev so unless there is a filesystem device created that triggers those udev rules, it will not be present. Let me know if you have any other questions!

(In reply to John Baublitz from comment #14)
> Hi Zdenek!
> This directory will only be created if you create a pool and filesystem. It
> is handled by udev so unless there is a filesystem device created that
> triggers those udev rules, it will not be present. Let me know if you have
> any other questions!
Thank you, John, so both are needed. Fortunately I added both the directories to the PR so I think no change is required, the file-context file content is now:

/usr/libexec/stratisd		--	gen_context(system_u:object_r:stratisd_exec_t,s0)

/dev/stratis(/.*)?  gen_context(system_u:object_r:stratisd_data_t,s0)

/stratis(/.*)?  gen_context(system_u:object_r:stratisd_data_t,s0)

/var/run/stratisd.*		--	gen_context(system_u:object_r:stratisd_var_run_t,s0)
/var/run/stratisd(/.*)?			gen_context(system_u:object_r:stratisd_var_run_t,s0)

That looks reasonable to me!

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:1995