Bug 1843238

Any update on this?  This bug has missed another RHEL release.  How can I raise the priority on this?

Any update?  This is blocking a major RFE for us.  The original issue (https://bugzilla.redhat.com/show_bug.cgi?id=1737550) was opened almost 2 years ago, but it was a bad fix and I had to open this bug.  Now we're going on 9 months with this new bug and no update.  How can I escalate this bug?

This bug has not been acknowledged by the selinux team to be resolved during the RHEL 8.4 development and testing phase, so it will be evaluated for inclusion into the next minor product update.

If you want to pursue this issue further, please attach information regarding severity of the bugzilla. If a fix in RHEL 8.4 is requested, raise the exception or blocker flag and answer the subsequent questions.

Well, since this is blocking an RFE I don't think we will get an exception this late into the 8.4 cycle.  At this point we can wait for RHEL 8.5, but I just want to make sure it's actually going to get addressed in 8.5 and not overlooked again.

Mark,

I read through this bz and the old one and I understand there is a need for supporting the correct label for /dev/shm/slapd-.*, e. g. /dev/shm/slapd-localhost. While we can define default file context for a file with a regexp, transitions need either exact filename or to know which process creates the file.

This is the current state in the policy: file context for /dev/shm/dirsrv/.* and file transitions for slapd and dirsrv services:

beaker-rhel8# semanage fcontext -l | grep dirsrv_tmpfs_t
/dev/shm/dirsrv(/.*)?                              all files          system_u:object_r:dirsrv_tmpfs_t:s0

beaker-rhel8# sesearch -T -s dirsrv_t -t tmpfs_t
type_transition dirsrv_t tmpfs_t:dir dirsrv_tmpfs_t;
type_transition dirsrv_t tmpfs_t:file dirsrv_tmpfs_t;
beaker-rhel8# sesearch -T -s slapd_t -t tmpfs_t
type_transition slapd_t tmpfs_t:file slapd_tmpfs_t;

We need to know which process creates the files, and if the part after the hyphen can be any string, i. e. is unpredictable from the policy point of view.

The process that creates this is "/usr/sbin/ns-slapd"

The "slapd-***" is name of the database instance, and it can be any alphanumeric combination, but no spaces.


And just to confirm, we want this regex for this directory and all files under it:

/dev/shm/slapd-*/

Not

/dev/shm/dirsrv/slapd-*/


Let me know if you need more info, I'd be glad to assistance in any way I can.  Thanks!

Thank you for the clarification. We will replace then the old file context specification and allow dirsrv read the files created by slapd. For that, we need to know which access permissions are required, is allowing dirsrv reading slapd tmpfs files enough?

If I understand, this was never in place so we can revert it:
commit 99f3ab969bf491a1080c57fd310a5bb5399e337f (HEAD -> rawhide)
Author: Lukas Vrabec <lvrabec>
Date:   Wed Sep 18 20:44:50 2019 +0200

    Label /dev/shm/dirsrv/ with dirsrv_tmpfs_t label

Then we allow read, write, or manage permissions:

allow dirsrv_t slapd_tmpfs_t:file getattr ioctl lock open read;

It would help if there was a simple reproducer or a test case.

(In reply to Zdenek Pytela from comment #8)
> Thank you for the clarification. We will replace then the old file context
> specification and allow dirsrv read the files created by slapd. For that, we
> need to know which access permissions are required, is allowing dirsrv
> reading slapd tmpfs files enough?

So the server will store its database mmapped files under /dev/shm/slapd-INSTANCE/.  It creates these files at every server startup, and then just reads from them once the server is running:  Here is how the current permissions look:

-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_var_lib_t:s0      1204224 May 26 15:49 __db.001
-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_var_lib_t:s0     24928256 May 26 15:49 __db.002
-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_var_lib_t:s0      7431608 May 26 15:50 __db.003



> 
> If I understand, this was never in place so we can revert it:
> commit 99f3ab969bf491a1080c57fd310a5bb5399e337f (HEAD -> rawhide)
> Author: Lukas Vrabec <lvrabec>
> Date:   Wed Sep 18 20:44:50 2019 +0200
> 
>     Label /dev/shm/dirsrv/ with dirsrv_tmpfs_t label

This label never worked correctly, not sure what was done, but it was not usable.  So yes it can be reverted.



> 
> It would help if there was a simple reproducer or a test case.



Sure, install "389-ds-base" package from module: 389-ds

Create an instance:

[1]  Create a setup INF file (/tmp/setup.inf):


[general]
config_version = 2
full_machine_name = localhost.localdomain
start = True

[slapd]
port = 389
root_dn = cn=dm
root_password = Secret123

[backend-userroot]
sample_entries = yes
suffix = dc=example,dc=com


# dscreate from-file /tmp/setup.inf

# dsctl slapd-localhost stop

# vi /etc/dirsrv/slapd-localhost/dse.ldif

Find this attribute:  nsslapd-db-home-directory

Change its value to: /dev/shm/slapd-localhost

Save file


Once the label is created by you guys, then we will enable the feature and then the server would create: /dev/shm/slapd-localhost at startup, but in this case you will need to do it manually since this code not enabled in the server yet.  Once /dev/shm/slapd-localhost/ is created (and relabeled) just attempt to the start the server:

# dsctl slapd-localhost start

If the server starts up we know the label is working correctly.

Following your scenario and adding a temporary selinux module:

beaker-rhel8# cat local_slapd.cil
(allow dirsrv_t slapd_tmpfs_t (file (getattr ioctl lock open read)))
beaker-rhel8# semodule -i local_slapd.cil

the service is running:

beaker-rhel8# dsctl slapd-localhost start
Instance "localhost" has been started
beaker-rhel8# dsctl slapd-localhost status
Instance "localhost" is running
beaker-rhel8# ps -eo pid,ppid,command,context | grep -e CONTEXT -e slapd -e dirsrv
    PID    PPID COMMAND                     CONTEXT
  60642       1 /usr/sbin/ns-slapd -D /etc/ system_u:system_r:dirsrv_t:s0
beaker-rhel8# ls -lZa /dev/shm/slapd-localhost
total 16792
drwx------. 2 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0      120 Jun  1 10:46 .
drwxrwxrwt. 3 root   root   system_u:object_r:tmpfs_t:s0              80 Jun  1 10:46 ..
-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0       51 Jun  1 10:46 DBVERSION
-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0  1179648 Jun  1 10:46 __db.001
-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0 14090240 Jun  1 10:46 __db.002
-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0  3761704 Jun  1 10:46 __db.003

so I will continue and put the same permissions into selinux-policy.

Mark,

I've submitted a Fedora PR:
https://github.com/fedora-selinux/selinux-policy/pull/764

and made it a draft eventually: The scenario works, but I cannot reproduce the failure. Do I need some newer version of the packages to see the service failing?

beaker-rhel8# rpm -qa "389*"
389-ds-base-legacy-tools-1.4.3.23-1.module+el8.5.0+11016+7e7e9011.x86_64
389-ds-base-libs-1.4.3.23-1.module+el8.5.0+11016+7e7e9011.x86_64
389-ds-base-1.4.3.23-1.module+el8.5.0+11016+7e7e9011.x86_64

Retargetting to ITM 16, the issue needs to be clarified.

Mark,

I tried again, with the same results, so I am unsure now what is failing in current RHEL 8 and therefore needs to be fixed.

Removing ITM until the issue is clarified.

(In reply to Zdenek Pytela from comment #12)
> Mark,
> 
> I've submitted a Fedora PR:
> https://github.com/fedora-selinux/selinux-policy/pull/764
> 
> and made it a draft eventually: The scenario works, but I cannot reproduce
> the failure. Do I need some newer version of the packages to see the service
> failing?
> 
> beaker-rhel8# rpm -qa "389*"
> 389-ds-base-legacy-tools-1.4.3.23-1.module+el8.5.0+11016+7e7e9011.x86_64
> 389-ds-base-libs-1.4.3.23-1.module+el8.5.0+11016+7e7e9011.x86_64
> 389-ds-base-1.4.3.23-1.module+el8.5.0+11016+7e7e9011.x86_64

Can you provide with the updated selinux rpms so I can test it?  Or provide a system where I can test it?  I have a special DS build where the server itself creates these directories and files (this is the RFE that has been on hold forever).  So I could provide a COPR build for you to verify it if you want...

Tested this bug on rhel version RHEL-8.5.0-20210622.n.0 and selinux-policy-3.14.3-71.el8.noarch. 

Also, Verified and automated this bug, here is the output from 1minutetip:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: bz#1843238
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [ 10:56:06 ] :: [ PASS ] :: Command 'cp -vf /etc/dirsrv/slapd-localhost/dse.ldif /etc/dirsrv/slapd-localhost/dse.ldif-bkup' (Expected 0, got 0)
:: [ 10:56:09 ] :: [ PASS ] :: Command 'systemctl stop dirsrv@localhost' (Expected 0, got 0)
:: [ 10:56:09 ] :: [ PASS ] :: Command 'sed -i 's/nsslapd-db-home-directory: \/var\/lib\/dirsrv\/slapd-localhost\/db/nsslapd-db-home-directory: \/dev\/shm\/slapd-localhost/' /etc/dirsrv/slapd-localhost/dse.ldif' (Expected 0, got 0)
:: [ 10:56:11 ] :: [ PASS ] :: Command 'systemctl start dirsrv@localhost' (Expected 0, got 0)
:: [ 10:56:11 ] :: [ PASS ] :: Command 'ls -dZ /dev/shm/slapd-localhost | grep dirsrv_tmpfs_t' (Expected 0, got 0)
:: [ 10:56:11 ] :: [ PASS ] :: Command 'ls -Z /dev/shm/slapd-localhost/__db.001 | grep dirsrv_tmpfs_t' (Expected 0, got 0)
:: [ 10:56:11 ] :: [ PASS ] :: Command 'ls -Z /dev/shm/slapd-localhost/__db.002 | grep dirsrv_tmpfs_t' (Expected 0, got 0)
:: [ 10:56:11 ] :: [ PASS ] :: Command 'ls -Z /dev/shm/slapd-localhost/__db.003 | grep dirsrv_tmpfs_t' (Expected 0, got 0)
:: [ 10:56:14 ] :: [ PASS ] :: Command 'systemctl stop dirsrv@localhost' (Expected 0, got 0)
:: [ 10:56:14 ] :: [ PASS ] :: Command 'cp -vf /etc/dirsrv/slapd-localhost/dse.ldif-bkup /etc/dirsrv/slapd-localhost/dse.ldif' (Expected 0, got 0)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Duration: 8s
:: Assertions: 10 good, 0 bad
:: RESULT: PASS (bz#1843238)

(In reply to mreynolds from comment #17)
> (In reply to Zdenek Pytela from comment #12)
> > Mark,
> > 
> > I've submitted a Fedora PR:
> > https://github.com/fedora-selinux/selinux-policy/pull/764
> > 
> > and made it a draft eventually: The scenario works, but I cannot reproduce
> > the failure. Do I need some newer version of the packages to see the service
> > failing?
> > 
> > beaker-rhel8# rpm -qa "389*"
> > 389-ds-base-legacy-tools-1.4.3.23-1.module+el8.5.0+11016+7e7e9011.x86_64
> > 389-ds-base-libs-1.4.3.23-1.module+el8.5.0+11016+7e7e9011.x86_64
> > 389-ds-base-1.4.3.23-1.module+el8.5.0+11016+7e7e9011.x86_64
> 
> Can you provide with the updated selinux rpms so I can test it?  Or provide
> a system where I can test it?  I have a special DS build where the server
> itself creates these directories and files (this is the RFE that has been on
> hold forever).  So I could provide a COPR build for you to verify it if you
> want...

There are no rpms ready as I was unable to reproduce the failure so I stepped back, now I understand we were trapped, waiting for the other party. 

If you want to check if the permissions are sufficient, please do one of these:
1. create a local module

# cat local_dirsrv_slapd.cil
(allow dirsrv_t slapd_tmpfs_t (dir (getattr search open)))
(allow dirsrv_t slapd_tmpfs_t (file (open getattr read ioctl lock)))
# semodule -i local_dirsrv_slapd.cil

2. Use Fedora 34/35 builds:
https://github.com/fedora-selinux/selinux-policy/pull/764
Show all checks -> build-rpm -> Details -> Artifacts -> rpms

Sorry been on PTO.  I will try this out soon shortly (leaving need-info flag intact)

Mark,

Does the new 389-ds-base package still target RHEL 8.5?
Will you be able to confirm if the Fedora commits or the local policy (#c19) addresses all possible issues with the new 389* build usage?

(In reply to Zdenek Pytela from comment #21)
> Mark,
> 
> Does the new 389-ds-base package still target RHEL 8.5?
> Will you be able to confirm if the Fedora commits or the local policy (#c19)
> addresses all possible issues with the new 389* build usage?

I'm so sorry, I just setup a lab machine and I will be testing it this afternoon.  I'll have an update by the end of the day...

Sorry it is still not working.  During instance creation I get this error and install fails:

# dscreate interactive
...
...

Warning no default label for /dev/shm/slapd-localhost
Error: Command '['systemctl', 'start', 'dirsrv@localhost']' returned non-zero exit status 1.

> I've updated selinux-policy on the beaker box, but I cannot access it now,
> please check if your scenarios still work with any valid configuration
> change.

Yes it works!!!!!

Thanks everyone for all the help and patience with this!

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-2021:4420