RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1879585 - Stratis device paths move from /stratis to /dev/stratis
Summary: Stratis device paths move from /stratis to /dev/stratis
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: 8.6
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-16 14:56 UTC by Dennis Keefe
Modified: 2022-05-10 16:22 UTC (History)
6 users (show)

Fixed In Version: selinux-policy-3.14.3-89.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-10 15:14:56 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1798244 1 unspecified CLOSED Stratis devices should inhabit an existing root directory path 2023-06-26 14:08:20 UTC
Red Hat Product Errata RHBA-2022:1995 0 None None None 2022-05-10 15:15:13 UTC

Internal Links: 2039974

Description Dennis Keefe 2020-09-16 14:56:25 UTC 
Description of problem:

Selinux provided support for Stratis devices in /stratis, however it was suggested by multiple groups to move the devices to a root file system directory
that already existed, such as, /dev.  This work has been completed an is expected
to arrive in the next version of RHEL.  

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1798244

Please consider providing changes to selinux to support this change and removing previous code that allowed /stratis.

One of the known BZ from selinux: https://bugzilla.redhat.com/show_bug.cgi?id=1791557 for reference.

Please let me know if packages are needed for testing, as they don't currently exist in Fedora or RHEL yet.

Thank you.
Comment 2 Milos Malik 2021-02-16 21:23:09 UTC 
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
#
Comment 3 Milos Malik 2021-06-03 16:18:31 UTC 
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
#
Comment 4 Dennis Keefe 2021-06-03 17:17:30 UTC 
(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.
Comment 5 Milos Malik 2021-06-03 19:11:36 UTC 
(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.
Comment 6 mulhern 2021-06-04 13:39:06 UTC 
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.
Comment 7 John Baublitz 2021-06-04 14:46:28 UTC 
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!
Comment 9 Zdenek Pytela 2022-01-25 17:34:31 UTC 
(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.
Comment 14 John Baublitz 2022-01-27 14:18:15 UTC 
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!
Comment 15 Zdenek Pytela 2022-01-27 15:20:49 UTC 
(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)
Comment 16 John Baublitz 2022-01-27 15:26:43 UTC 
That looks reasonable to me!
Comment 22 errata-xmlrpc 2022-05-10 15:14:56 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.