Bug 816309

Created attachment 580247 [details]
Cobbler log

Created attachment 580248 [details]
Combined output from setroubleshoot for all 7 incidents

Did it happen by default, or did you change labeling using public_content_t?

(In reply to comment #4)
> Did it happen by default, or did you change labeling using public_content_t?

As per cobbler instructions, I changed the label to public_content_t.

These instructions should be fixed. I am also adding fixes from Fedora cobbler policy to RHEL6.3 policy.

Could you try to run the restorecon command on directories from these instructions.

$ restorecon -R -v $DIRECTORY

Thank you.

I executed the above instruction with no apparent effect.  No value had been assigned to $DIRECTORY.

Is there a way to get a copy of the fixes and installation instructions so I can test them?

Try to execute

$ restorecon -R -v /var/lib/tftpboot
$ restorecon -R -v /var/www/cobbler

Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

This is still a bug and needs to be fixed.  I understand that it will not be in 6.3, but it should not be closed.

Isn't the best course of action downgrading cobbler in EPEL and staying on the 2.0 version there (bump of epoch would of course be needed)?

As I said, regardless of when this is fixed or whether there is a workaround, it is still a bug that should be fixed.  This is not the only issue that cobbler 2.2.2 has with selinux in RHEL 6.2.

(In reply to comment #15)
> As I said, regardless of when this is fixed or whether there is a workaround,
> it is still a bug that should be fixed.  This is not the only issue that
> cobbler 2.2.2 has with selinux in RHEL 6.2.

I did not mean downgrade as a workaround. I meant pushing the cobbler maintainer to do the downgrade in EPEL as a proper fix, going back to 2.0, rather than hunting the SELinux issues ex post.

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

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

Why has this been closed as WONTFIX?

Actually, this bug is a clear duplicate of bug 816835 -- wrong packaging leading to wrong labelling.

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

I would like to clean all these cobbler bugs. 

We have issues which are caused by a new cobbler. Most of these issues we are not able to fix properly without filne name transitions. The fix for this is have cobblerd as unconfined domain because cobbler wants to do a lot of stuff => unconfined domain.

But 2.0 version is going to be used and this version does not cause any issues, right?

Downgrading to cobbler 2 in EPEL is a definite no-go - it will break all setups that have cobbler 2.2 presently installed.

Adding policy to allow (2.2) cobbler to run unconfined seems acceptable to me in the short term. Longer term, though, if SElinux policy can't be written for such an application, then I'd question the utility of SElinux.

(In reply to comment #28)
> I would like to clean all these cobbler bugs. 
> 
> We have issues which are caused by a new cobbler. Most of these issues we
> are not able to fix properly without filne name transitions.

I don't agree. This particular issue is quite easily fixed by packaging /var/www/cobbler/images as I've described in bug 816835 comment 0. Unfortunately, instead of small patch in the .spec, cobbler maintainer decided to rebase to the next upstream release without proper testing, bringing new bugs with it.

> The fix for
> this is have cobblerd as unconfined domain because cobbler wants to do a lot
> of stuff => unconfined domain.

This fix for this bugzilla is to package /var/www/cobbler/images in cobbler just like cobbler-2.0 packages did for ages.

> But 2.0 version is going to be used and this version does not cause any
> issues, right?

We would very much like to be able to use cobbler 2.0 confined. If you plan to have a boolean to unconfine cobbler, fine.

(In reply to comment #29)
> Downgrading to cobbler 2 in EPEL is a definite no-go - it will break all
> setups that have cobbler 2.2 presently installed.

But those setups are immediatelly broken if you want to run then with SELinux enforcing, aren't they?

> Adding policy to allow (2.2) cobbler to run unconfined seems acceptable to
> me in the short term.

Right.

>                     Longer term, though, if SElinux policy can't be
> written for such an application, then I'd question the utility of SElinux.

The problem is not SELinux. The problem is that if you rebase to new upstream without proper testing, things are bound to break.

(In reply to comment #31)
> (In reply to comment #29)
> > Downgrading to cobbler 2 in EPEL is a definite no-go - it will break all
> > setups that have cobbler 2.2 presently installed.
> 
> But those setups are immediatelly broken if you want to run then with
> SELinux enforcing, aren't they?

Not if the SElinux policy is patched to run cobblerd unconfined. This fixes all situations. Reverting to 2.0 irreversibly breaks setups which have moved to 2.2 irreprably. This is not acceptable. 

> 
> > Adding policy to allow (2.2) cobbler to run unconfined seems acceptable to
> > me in the short term.
> 
> Right.
> 
> >                     Longer term, though, if SElinux policy can't be
> > written for such an application, then I'd question the utility of SElinux.
> 
> The problem is not SELinux. The problem is that if you rebase to new
> upstream without proper testing, things are bound to break.

True - the failure here is no coordination with SELinux policy maintainers.

(In reply to comment #32)
> (In reply to comment #31)
> > 
> > But those setups are immediatelly broken if you want to run then with
> > SELinux enforcing, aren't they?
> 
> Not if the SElinux policy is patched to run cobblerd unconfined. This fixes
> all situations.

Which is hardly setup you want to run in production.

> Reverting to 2.0 irreversibly breaks setups which have moved
> to 2.2 irreprably.

What exactly will break?

> This is not acceptable. 

I'm partially playing devil's advocate here and partially I'm pretty serious about the question, so if you could enlighten me on the incompatibilities,
I'd appreciate it.

Jan

(In reply to comment #33)
> (In reply to comment #32)
> > (In reply to comment #31)
> > > 
> > > But those setups are immediatelly broken if you want to run then with
> > > SELinux enforcing, aren't they?
> > 
> > Not if the SElinux policy is patched to run cobblerd unconfined. This fixes
> > all situations.
> 
> Which is hardly setup you want to run in production.
> 

Here are your choices:
1) Run cobbler 2.2 unconfined. Get work done.

2) Downgrade to 2.0. Hose your database. Lose support for Debian/UbuntuFreeBSD. Get no work done. Spend hours working around the features which are now missing and which you'd come to rely on.


> > Reverting to 2.0 irreversibly breaks setups which have moved
> > to 2.2 irreprably.
> 
> What exactly will break?
> 

Ubuntu/Debian support. FreeBSD support. Worse, I found system entries missing when I downgraded to 2.0 on a test instance - something has proven backwards incompatible regarding the database. I don't know what exactly. RHEL6 importing has also changed (for the better) when using the available-as directive..

> > This is not acceptable. 
> 
> I'm partially playing devil's advocate here and partially I'm pretty serious
> about the question, so if you could enlighten me on the incompatibilities,
> I'd appreciate it.

See above. Downgrading to 2.0 would require an extensive period of testing to patch things to do minimal damage. By which time you've got a heavily patched 2.0/2.2 hybrid.

Upgrading to 2.2 was perhaps a bad engineering decision for EPEL. To now introduce vastly more breakage by reverting JUST to re-enable SELinux confinement is beyond terrible engineering.

Just take a look at the changelog for 2.2 - this was a major rebase of code.

Well this late in the ball game, I would say we go unconfined for now, and back port the policy fixes and test it in 6.5.  File labeling is probably my biggest concern.  IE Is there some files that cobbler is going to create which end up with the wrong label, and cause other confined apps to break.

Yes, the problem with new cobbler is mainly related to labeling.

Well we could have the cobbler guys add a small module

cobbler_unconfined.pp which they can install with the upgrade

policy_module(cobbler_unconfined, 1.0)
gen_require(`
type cobbler_t;
')
unconfined_domain(cobbler_t)

Then we can talk to Eric about seeing if filename_transitions could be back ported to rhel6.

Any progress here?

I'm not having any luck using the above module:

# semodule -i cobbler_unconfined.pp
libsepol.print_missing_requirements: cobbler_unconfined's global requirements were not met: type/attribute cobbler_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory).
semodule:  Failed!

Looks like it is "cobblerd_t" instead.  That works.

unconfined_u:system_r:cobblerd_t:s0 root  1776     1  0 10:06 ?        00:00:00 /usr/bin/python /usr/bin/cobblerd --daemonize

Orion, 
there is a typo. It should be

# cat cobbler_unconfined.te
policy_module(cobbler_unconfined, 1.0)
gen_require(`
type cobblerd_t;
')
unconfined_domain(cobblerd_t)

I have no idea how you get that policy file working:

I get this:
====================================================================
[root@geppetto ~]# semodule -i cobbler_unconfined.te
libsepol.module_package_read_offsets: wrong magic number for module package:  expected 0xf97cff8f, got 0x696c6f70
libsemanage.parse_module_headers: Could not parse module data.
semodule:  Failed on cobbler_unconfined.te!
[root@geppetto ~]# cat cobbler_unconfined.te
policy_module(cobbler_unconfined, 1.0)
gen_require(`
type cobblerd_t;
')
unconfined_domain(cobblerd_t)
[root@geppetto ~]# 
====================================================================

The following might be less clean but at least it works:
========================================================================
[root@geppetto audit]# cobbler check
httpd does not appear to be running and proxying cobbler, or SELinux is in the way. Original traceback:
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/cobbler/cli.py", line 252, in check_setup
    s.ping()
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1243, in request
    headers
ProtocolError: <ProtocolError for geppetto.oma.be:80/cobbler_api: 503 Service Temporarily Unavailable>
[root@geppetto audit]#
[root@geppetto audit]# getsebool -a | grep cobbler
cobbler_anon_write --> off
cobbler_can_network_connect --> off
cobbler_use_cifs --> off
cobbler_use_nfs --> off
httpd_can_network_connect_cobbler --> off
[root@geppetto audit]# setsebool cobbler_anon_write=on cobbler_can_network_connect=on cobbler_use_cifs=on cobbler_use_nfs=on httpd_can_network_connect_cobbler=on
[root@geppetto audit]# cobbler checkThe following are potential configuration items that you may want to fix:

1 : SELinux is enabled. Please review the following wiki page for details on ensuring cobbler works correctly in your SELinux environment:
    https://github.com/cobbler/cobbler/wiki/Selinux
2 : dhcpd is not installed
3 : some network boot-loaders are missing from /var/lib/cobbler/loaders, you may run 'cobbler get-loaders' to download them, or, if you only want to handle x86/x86_64 netbooting, you may ensure that you have installed a *recent* version of the syslinux package installed and can ignore this message entirely.  Files in this directory, should you want to support all architectures, should include pxelinux.0, menu.c32, elilo.efi, and yaboot. The 'cobbler get-loaders' command is the easiest way to resolve these requirements.
4 : change 'disable' to 'no' in /etc/xinetd.d/rsync
5 : Apache (httpd) is not installed and/or in path
6 : debmirror package is not installed, it will be required to manage debian deployments and repositories
7 : ksvalidator was not found, install pykickstart
8 : fencing tools were not found, and are required to use the (optional) power management features. install cman or fence-agents to use them

Restart cobblerd and then run 'cobbler sync' to apply changes.
[root@geppetto audit]#
========================================================================

Comments are welcome.

(In reply to Joost Ringoot from comment #43)
> I have no idea how you get that policy file working:
> 
Given the .te file 

# cat -e cobbler_unconfined.te 
policy_module(cobbler_unconfined, 1.0)$
$
gen_require(`$
type cobblerd_t;$
')$
unconfined_domain(cobblerd_t)	$

Make and then install the policy (.pp) file

# make -f /usr/share/selinux/devel/Makefile 
Compiling targeted cobbler_unconfined module
/usr/bin/checkmodule:  loading policy configuration from tmp/cobbler_unconfined.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 10) to tmp/cobbler_unconfined.mod
Creating targeted cobbler_unconfined.pp policy package
rm tmp/cobbler_unconfined.mod.fc tmp/cobbler_unconfined.mod

# semodule -i cobbler_unconfined.pp

I believe we will need to have a workaround using cobbler_unconfined.pp how Simon wrote above for RHEL6.

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

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

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