search

LINBIT / drbd-utils

DRBD userspace utilities (for 9.x, 8.4, 8.3)
GNU General Public License v2.0
78 stars 46 forks source link

DRBD selinux policy doesn't work when attempting to create the metadata storage #42

Closed daniel-walder closed 8 months ago

daniel-walder commented 8 months ago

With Selinux enabled on my systems I load the drbd-selinux rpm. But when i attempt to create the metadata file using drbdadm create-md it runs into selinux permission denies for accessing the disk where the metadata storage is written to. This issue also happens when you try to delete the metadata storage. I am unsure if this is an oversight in the selinux policy or if there is something else that I am missing with the drbd-utils.

lge commented 8 months ago

What is your

I'd expect create-md to typically happen from an unconfined root login session. Which context are you in when attempting to create-md? (id) What exactly are the steps to reproduce the "does not work" case?

What is actually logged to audit.log? Are you familiar with "audit2why" and "audit2allow", what do they tell you what they think is "missing"?

daniel-walder commented 8 months ago

Sorry for not giving more context in the original post:

The context that I am in when attempting to bring up the metadata storage is sysadm_t. I assume this is because of the unconfined root login session i am in.

Steps to reproduce:

  1. Sign in and swich to an unconfined root login session.
  2. run drbdadm create-md (id)

From looking at the audit logs for the denies it was trying to execute drdbadm with the sysadm_t context. More specifically when executing the create-md argument. It looks like sysadm_t doesn't have the permissions to open read write ioctl on fixed_disk_devices:blk_file. Now i created a policy to allow sysadm_t fixed_disk_device_t:blk_file { open read write ioctl }; and it appears to be working. But I am thinking that is it best practice to allow for sysadm_t to have this permission on a fixed_disk_device? I would assume no.

lge commented 8 months ago
  1. Sign in and swich to an unconfined root login session.

well, no, if you where "unconfined" you'd be context=unconfined_u:unconfined_r:unconfined_t ;-) looks like to reproduce, need to

  1. Sign in and switch to a confined root session.

So, there's the "problem": our selinux policy ignores that you can confine root.

All our selinux policy aims to do is: allow pacemaker to run the DRBD resource agent and all the tools it needs -- drbdmeta is not one of them.

To use drbdmeta, for now you have to transition to unconfined first.

lge commented 8 months ago

All our selinux policy aims to do is: allow pacemaker to run the DRBD resource agent and all the tools it needs -- drbdmeta is not one of them.

Uh. That's incorrect, though ;-) indirectly, via drbdadm, it is used when bringing up a DRBD resource, the repair-md and apply-al sub-commands are used while "attaching" the backend device.

To use drbdmeta, for now you have to transition to unconfined first.

I guess changing the context to cluster-something or whatever is used for Pacemaker would work as well.

Anyways... to make it work for "sysadm", we'll have to convince the system to treat drbdmeta similar to mkfs or pvcreate, to just name some "administratively equivalent" commands, but with our own label possibly with a drbdmeta specific drbdmeta_exec_t, or if we are lazy, with drbd_exec_t. We'll think of something, but ... that's not a priority, really.

Workarounds for now: allow sysadm_t fixed_disk_device_t:blk_file as you did, or change to unconfined or fsadm (or cluster?) first.