EL7 Selinux issues still

Sean · July 19, 2016, 2:47pm

Hi,

I have just upgraded from 1.10.4 to 1.11.3 on Scientific Linux 7.2 x86_64.
The upgrade seems to have gone smoothly, but after updating the rest of
the OS and rebooting #14811 <Bug #14811: Passenger paths changed once again (RHEL7) - SELinux - Foreman> still
seems to be in play for me with Selinux set to enforcing. The server is
set to enforcing, but after this issue came up in 1.10.x, I manually
switched to permissive, so today after rebooting, I forgot to manually set
it to permissive. Here's what happens:

After restarting the httpd service (Enforcing) and visiting foreman in the
browser we get a nice big ruby on rails dump with a permission denied
making a directory. In the audit log there are about 14 AVC denials
related to foreman/passenger (I can provide if desired, but didn't want to
put garbage on the list). Switching to Permissive, and reloading the page
from the browser works fine (with or without restarting httpd), so I
conclude there no actual file permission issue. Any ideas? I'd really
like to get back to running enforcing mode.

Thanks!

lzap · July 20, 2016, 7:47am

> After restarting the httpd service (Enforcing) and visiting foreman in the
> browser we get a nice big ruby on rails dump with a permission denied
> making a directory. In the audit log there are about 14 AVC denials
> related to foreman/passenger (I can provide if desired, but didn't want to
> put garbage on the list). Switching to Permissive, and reloading the page
> from the browser works fine (with or without restarting httpd), so I
> conclude there no actual file permission issue. Any ideas? I'd really
> like to get back to running enforcing mode.

Hi,

http://projects.theforeman.org/projects/foreman/wiki/Troubleshooting#SELinux-denials

···

-- Later, Lukas #lzap Zapletal

Sean · July 20, 2016, 5:19pm

Unfortunately, the both foreman-selinux commands and the autorelabel did
not help. Also, our policy would prevent me from using foreman-debug -u.
I count over 10000 lines of data I'd have to clean information out of in
order to do the upload. If I take the manual data collection approach, is
there a way I can send it privately to the foreman core developers? I will
have to scrub data information from the manual collection as well, but
there is less information there.

Thanks!

···

On Wednesday, July 20, 2016 at 3:47:30 AM UTC-4, Lukas Zapletal wrote: > > > After restarting the httpd service (Enforcing) and visiting foreman in > the > > browser we get a nice big ruby on rails dump with a permission denied > > making a directory. In the audit log there are about 14 AVC denials > > related to foreman/passenger (I can provide if desired, but didn't want > to > > put garbage on the list). Switching to Permissive, and reloading the > page > > from the browser works fine (with or without restarting httpd), so I > > conclude there no actual file permission issue. Any ideas? I'd really > > like to get back to running enforcing mode. > > Hi, > > > http://projects.theforeman.org/projects/foreman/wiki/Troubleshooting#SELinux-denials > > -- > Later, > Lukas #lzap Zapletal >

lzap · July 21, 2016, 8:01am

> not help. Also, our policy would prevent me from using foreman-debug -u.

If you are running your own policies, then we are unlikely able to help
you. Our users usually run default Red Hat policy and Foreman policy was
built against the unchanged one.

My wild guess is bad labelling of passenger. It uses several binaries
which must be properly labeled:

github.com

theforeman/foreman-selinux/blob/develop/foreman.fc

# vim: sw=4:ts=4:et
#
# Copyright 2013 Red Hat, Inc.
#
# This program and entire repository is free software: you can redistribute it
# and/or modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation, either version 3 of the License,
# or any later version.
#
# This program is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
# FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
# details.
#
# You should have received a copy of the GNU General Public License along with
# this program. If not, see http://www.gnu.org/licenses/.
#

# Foreman file contexts

This file has been truncated. show original

But I can't tell. It works under normal circumstances.

···

-- Later, Lukas #lzap Zapletal

lzap · July 21, 2016, 8:02am

> Thanks!

One more thing, we only support Targeted mode, MLS or Strict is not
tested at all.

···

-- Later, Lukas #lzap Zapletal

Sean · July 21, 2016, 3:31pm

Ok, so I think we had a communication disconnect. When I said, "our
policy" I didn't mean selinux policy, I mean organizational policy. I
can't run foreman-debug -u and upload the information because it would the
limited amount of information that is scrubbed by the collection process
isn't thorough enough to allow me to send the debug data to you.

As far as I recall, we have no custom selinux policies on our foreman
server, and our organizational policy requires selinux in targeted mode.

So, if I run the manual data collection mentioned in the Wiki and scrub it,
can I send it to the core development group privately somehow - as is
stated to be done with the foreman-debug -u command?

···

On Thursday, July 21, 2016 at 4:02:21 AM UTC-4, Lukas Zapletal wrote: > > > Thanks! > > One more thing, we only support Targeted mode, MLS or Strict is not > tested at all. > > -- > Later, > Lukas #lzap Zapletal >

lzap · July 22, 2016, 8:05am

> So, if I run the manual data collection mentioned in the Wiki and scrub it,
> can I send it to the core development group privately somehow - as is
> stated to be done with the foreman-debug -u command?

Send it to me, I will take a look.

···

-- Later, Lukas #lzap Zapletal