Bug 1159756

Our test labs don't have support for SELinux so there's no way to test this with any reasonable level of confidence. Re-targeting to 1.3.1 for now.

Since this is targeted for 1.3.1, QE will provide ACK during 1.3.1 time.

We should be able to test selinux in the octo lab on the el7 machines.. unless there is some other issue I'm not aware of?

(In reply to Sage Weil from comment #3)
> We should be able to test selinux in the octo lab on the el7 machines..
> unless there is some other issue I'm not aware of?

I'm sure we could turn it on across the octo lab to find out what breaks. Some potential issues come to mind:

- Ideally Teuthology itself would not set off any AVC denial errors. 
- teuthology-nuke has no ability to reset SELinux settings to a known state. Maybe re-imaging is really our best operation there, since relabling the whole filesystem can also take a while.
- It would also be great to make Teuthology use the packaging init scripts for RGW so that daemon runs in the same SELinux context that a user will use. (I am not sure if Teuthology does this for Ceph, either?)

*** Bug 1127910 has been marked as a duplicate of this bug. ***

(In reply to Ken Dreyer (Red Hat) from comment #4)
> (In reply to Sage Weil from comment #3)
> > We should be able to test selinux in the octo lab on the el7 machines..
> > unless there is some other issue I'm not aware of?
> 
> I'm sure we could turn it on across the octo lab to find out what breaks.
> Some potential issues come to mind:

It's my understanding that setting it to use permissive mode would log would-be denials, while not actually denying anything. I can trivially change our kickstart template to do this for all new reimages. We could also probably modify existing systems to enable selinux, though I'm not sure if that would cause strange behavior.

> - Ideally Teuthology itself would not set off any AVC denial errors. 
> - teuthology-nuke has no ability to reset SELinux settings to a known state.
> Maybe re-imaging is really our best operation there, since relabling the
> whole filesystem can also take a while.

Relabling would almost certainly take far less time than reimaging. A relabel can be accomplished by a simple 'touch /.autorelabel && reboot'.

> - It would also be great to make Teuthology use the packaging init scripts
> for RGW so that daemon runs in the same SELinux context that a user will
> use. (I am not sure if Teuthology does this for Ceph, either?)

Currently we wrap each call to a daemon with three different shell/python scripts. Given that, I don't know how feasible it would be to use the standard init scripts.

(In reply to Zack Cerza from comment #6)
> (In reply to Ken Dreyer (Red Hat) from comment #4)
> > (In reply to Sage Weil from comment #3)
> > > We should be able to test selinux in the octo lab on the el7 machines..
> > > unless there is some other issue I'm not aware of?
> > 
> > I'm sure we could turn it on across the octo lab to find out what breaks.
> > Some potential issues come to mind:
> 
> It's my understanding that setting it to use permissive mode would log
> would-be denials, while not actually denying anything. I can trivially
> change our kickstart template to do this for all new reimages. We could also
> probably modify existing systems to enable selinux, though I'm not sure if
> that would cause strange behavior.

We'd probably want to make this optional.. like maybe an selinux.py task that enables permissive (or another node) during setup and on cleanup checks for errors.

> > - It would also be great to make Teuthology use the packaging init scripts
> > for RGW so that daemon runs in the same SELinux context that a user will
> > use. (I am not sure if Teuthology does this for Ceph, either?)
> 
> Currently we wrap each call to a daemon with three different shell/python
> scripts. Given that, I don't know how feasible it would be to use the
> standard init scripts.

Yeah :(.  The ceph-deploy exercises the normal init scripts though... that might be the way to go for this.

(In reply to Zack Cerza from comment #6)
> Relabling would almost certainly take far less time than reimaging. A
> relabel can be accomplished by a simple 'touch /.autorelabel && reboot'.

Ok, that's fair. The reason I proposed re-imaging is that we'd also want to be sure we reset all selinux booleans to the factory defaults. I don't know a way to do that.

@Ken: 'semanage export' will tell you what all your local SELinux customizations are (not just booleans). You can also check the output of 'semanage boolean -lC' that will show you the locally customized booleans.

Finally, you can even use 'semanage boolean -D' to remove all the local boolean modifications.

*** Bug 1250037 has been marked as a duplicate of this bug. ***

*** Bug 1127910 has been marked as a duplicate of this bug. ***

*** Bug 1217816 has been marked as a duplicate of this bug. ***

Will this fix be part of Ceph only? Or will it become part of RHEL and Atomic?
Do we know which version of OSP (OSP-D) is targeted to integrate this fix?
We can file a separate BZ for tracking OSP integration.

(In reply to arkady kanevsky from comment #18)
> Will this fix be part of Ceph only? Or will it become part of RHEL and
> Atomic?

It will be a part of Ceph only.

> Do we know which version of OSP (OSP-D) is targeted to integrate this fix?

This bug doesn't relate to any OSP code, only Ceph. So as soon as the Ceph product ships a build with a fix, then it's available to all customers, OSP included.

(In reply to Ken Dreyer (Red Hat) from comment #20)
> (In reply to arkady kanevsky from comment #18)
> > Do we know which version of OSP (OSP-D) is targeted to integrate this fix?
> 
> This bug doesn't relate to any OSP code, only Ceph. So as soon as the Ceph
> product ships a build with a fix, then it's available to all customers, OSP
> included.

Sorry, I realized that maybe you meant "when will OSP Director handle the installation of the ceph-selinux package". That I don't know - it would be good to file a BZ against OSP-D for that.

Fixed. Moving to verified state.

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, 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-2016:0313