lorax - selinux limitation

[Dominique Martinet]

Hi,

in el7, in /usr/lib/python2.7/site-packages/pylorax/__init__.py we have
this comment/code:
# is selinux disabled?
# With selinux in enforcing mode the rpcbind package required for
# dracut nfs module, which is in turn required by anaconda module,
# will not get installed, because it's preinstall scriptlet fails,
# resulting in an incomplete initial ramdisk image.
# The reason is that the scriptlet runs tools from the shadow-utils
# package in chroot, particularly groupadd and useradd to add the
# required rpc group and rpc user. This operation fails, because
# the selinux context on files in the chroot, that the shadow-utils
# tools need to access (/etc/group, /etc/passwd, /etc/shadow etc.),
# is wrong and selinux therefore disallows access to these files.
logger.info("checking the selinux mode")
if selinux.is_selinux_enabled() and selinux.security_getenforce():
logger.critical("selinux must be disabled or in Permissive mode")
sys.exit(1)


I've just generated new images on a centos7.1 box with selinux enabled
and it didn't seem to run into any selinux-related trouble after
disabling this check - in particular, /etc/passwd in the LiveOS image
does contain rpcuser and there wasn't any obvious error message in the
whole lorax process.

Would it be possible to remove this now?
(do you want me to send a trivial patch that just removes this bunch of
lines so my name is on it for future complains?)

[Brian C. Lane]

Post by Dominique Martinet
Hi,
in el7, in /usr/lib/python2.7/site-packages/pylorax/__init__.py we have
# is selinux disabled?
# With selinux in enforcing mode the rpcbind package required for
# dracut nfs module, which is in turn required by anaconda module,
# will not get installed, because it's preinstall scriptlet fails,
# resulting in an incomplete initial ramdisk image.
# The reason is that the scriptlet runs tools from the shadow-utils
# package in chroot, particularly groupadd and useradd to add the
# required rpc group and rpc user. This operation fails, because
# the selinux context on files in the chroot, that the shadow-utils
# tools need to access (/etc/group, /etc/passwd, /etc/shadow etc.),
# is wrong and selinux therefore disallows access to these files.
logger.info("checking the selinux mode")
logger.critical("selinux must be disabled or in Permissive mode")
sys.exit(1)
I've just generated new images on a centos7.1 box with selinux enabled
and it didn't seem to run into any selinux-related trouble after
disabling this check - in particular, /etc/passwd in the LiveOS image
does contain rpcuser and there wasn't any obvious error message in the
whole lorax process.
Would it be possible to remove this now?
(do you want me to send a trivial patch that just removes this bunch of
lines so my name is on it for future complains?)

I think it's better to leave it and run it in permissive mode. The
results always get labeled properly, the problems you hit while leaving
it enabled is selinux blocking the package installation in the
installroot. Depending on the host version and selinux rules this may
work for you, but not for others.

[Dominique Martinet]

Post by Brian C. Lane
I think it's better to leave it and run it in permissive mode. The
results always get labeled properly, the problems you hit while leaving
it enabled is selinux blocking the package installation in the
installroot. Depending on the host version and selinux rules this may
work for you, but not for others.

Well, all my systems here (in the cluster I'm rebuilding the image for)
have selinux enforced, so I basically either have to maintain a local
patch to skip the check or to spawn a VM just for the job - both of
which I can do right now, but would rather avoid in the long term.

Would it be possible to add a switch like --yes-selinux-is-enforced-do-it-anyway
or something ugly to bypass the check then?


FWIW selinux policies are rather centralised and updated everywhere so
it should be ok for anyone in el7/recent-ish fedora (would need to test
el6) that runs root as unconstrained, may be worth checking for id -Z
instead even if it's a bit more work?


(I'm actually not sure if the preferred way to change which kernel to
use in the pxe images is to go through lorax or just to fix the kernel
modules in the initrd by hand.. I find lorax "cleaner", but if I have to
kludge around it may be easier to go back to scripting around the initrd
modification)

Thanks,

[Vit Ry]

Keep in mind - it may be fine still you are using SELinux targeted policy, which is kiddy mode :D
Some users (I am, for example) can use SELinux MLS policy, where you should write a lot of rules for every apps, so one part of lorax would works fine, another - do not at all, and third one - looks like work fine, but SELinux blocked something unusual inside lorax/installroot.

Post by Dominique Martinet
Well, all my systems here (in the cluster I'm rebuilding the image for)
have selinux enforced, so I basically either have to maintain a local
patch to skip the check or to spawn a VM just for the job - both of
which I can do right now, but would rather avoid in the long term.
Would it be possible to add a switch like
--yes-selinux-is-enforced-do-it-anyway
or something ugly to bypass the check then?
FWIW selinux policies are rather centralised and updated everywhere so
it should be ok for anyone in el7/recent-ish fedora (would need to test
el6) that runs root as unconstrained, may be worth checking for id -Z
instead even if it's a bit more work?
(I'm actually not sure if the preferred way to change which kernel to
use in the pxe images is to go through lorax or just to fix the kernel
modules in the initrd by hand.. I find lorax "cleaner", but if I have to
kludge around it may be easier to go back to scripting around the initrd
modification)
Thanks,

---
Regards,
Vit Ry.

[Dominique Martinet]

Post by Vit Ry
Keep in mind - it may be fine still you are using SELinux targeted
policy, which is kiddy mode :D

Yes, we have some nodes in targeted mode, some nodes with MLS - I only
tried on a system with mostly-default selinux configuration, so
targeted.

Post by Vit Ry
Some users (I am, for example) can use SELinux MLS policy, where you
should write a lot of rules for every apps, so one part of lorax would
works fine, another - do not at all, and third one - looks like work
fine, but SELinux blocked something unusual inside lorax/installroot.

Sure, but shouldn't you be able to check and/or tell yourself?

As long as it works for default 'kiddy mode' setup then I see no problem
in enabling it by default -- even if you want to play safe, adding a
run-anyway switch doesn't cost much and probably won't bring many
bugreports asking about X fails with selinux enabled.

If you're running MLS or whatever else then you're what I would consider
and advanced user and certainly ought to be able to do whatever you want
as well.

I just don't want tools to tell me they won't even try because they
think it might possibly not work - let me please decide if it works or
not for myself!


For example, I'd be happy with a patch similar to this (+setting default
to false earlier in the file, not tested):

diff --git a/src/pylorax/__init__.py b/src/pylorax/__init__.py
index 4a41d95..60fc738 100644
--- a/src/pylorax/__init__.py
+++ b/src/pylorax/__init__.py
@@ -219,8 +219,9 @@ class Lorax(BaseLoraxClass):
# tools need to access (/etc/group, /etc/passwd, /etc/shadow
etc.),
# is wrong and selinux therefore disallows access to these
files.
logger.info("checking the selinux mode")
- if selinux.is_selinux_enabled() and selinux.security_getenforce():
- logger.critical("selinux must be disabled or in Permissive mode")
+ if selinux.is_selinux_enabled() and selinux.security_getenforce() and self.conf.getboolean("lorax", "run-with-selinux"):
+ logger.critical("selinux is in enforced mode. This is known to cause bugs.")
+ logger.critical("If you are sure you want to try and know how to check AVCs please run again with run-with-selinux=true in the lorax section of the config file")
sys.exit(1)

# do we have a proper dnf base object?

[Vit Ry]

And, do you have "dracut nfs module' installed inside?

Post by Dominique Martinet
Hi,
in el7, in /usr/lib/python2.7/site-packages/pylorax/__init__.py we have
# is selinux disabled?
# With selinux in enforcing mode the rpcbind package required for
# dracut nfs module, which is in turn required by anaconda module,
# will not get installed, because it's preinstall scriptlet fails,
# resulting in an incomplete initial ramdisk image.
# The reason is that the scriptlet runs tools from the shadow-utils
# package in chroot, particularly groupadd and useradd to add the
# required rpc group and rpc user. This operation fails, because
# the selinux context on files in the chroot, that the shadow-utils
# tools need to access (/etc/group, /etc/passwd, /etc/shadow etc.),
# is wrong and selinux therefore disallows access to these files.
logger.info("checking the selinux mode")
logger.critical("selinux must be disabled or in Permissive mode")
sys.exit(1)

[Dominique Martinet]

Post by Vit Ry
And, do you have "dracut nfs module' installed inside?

Not quite sure how to check, but it looks like there are nfs-related
scripts installed:
xz -d -c images/pxeboot/initrd.img | cpio -t 2>&1 | grep nfs
usr/sbin/mount.nfs
usr/sbin/mount.nfs4
usr/sbin/nfsroot
usr/lib/dracut/hooks/cmdline/90-parse-nfsroot.sh
usr/lib/dracut/hooks/pre-udev/99-nfs-start-rpc.sh
usr/lib/dracut/hooks/cleanup/99-nfsroot-cleanup.sh
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs/blocklayout
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs/blocklayout/blocklayoutdriver.ko
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs/filelayout
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs/filelayout/nfs_layout_nfsv41_files.ko
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs/nfs.ko
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs/nfsv3.ko
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs/nfsv4.ko
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs/objlayout
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs/objlayout/objlayoutdriver.ko
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs_common
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfs_common/nfs_acl.ko
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfsd
usr/lib/modules/3.10.0-229.11.1.ocean1.el7.centos.x86_64/kernel/fs/nfsd/nfsd.ko
usr/lib/python2.7/site-packages/pykickstart/commands/nfs.py
usr/lib/nfs-lib.sh
usr/lib64/libnfsidmap
usr/lib64/libnfsidmap/nsswitch.so
usr/lib64/libnfsidmap/static.so
usr/lib64/libnfsidmap/umich_ldap.so
usr/lib64/libnfsidmap.so.0.3.0
usr/lib64/libnfsidmap.so.0
etc/modprobe.d/nfs.conf
var/lib/nfs
var/lib/nfs/rpc_pipefs
var/lib/nfs/statd
var/lib/nfs/statd/sm

Also, as said previously, the common rpc users are present in etc/passwd
in both the initrd and the LiveOS .img base system:
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin

Is there anything specific I could check? I'm just runing lorax with a
few repos and no specific options/template for the moment.
(will be wanting to purge a few modules and add extra packages
ultimately, but not removing nfs)

Post by Vit Ry
From a selinux point of view, anyone running it as permissive can check

if there is any AVC related to a run in /var/log/audit/audit.log
(Obviously isn't anything for me or I wouldn't have asked)

This file lists both what does get blocked in enforcing and what would
get blocked in permissive, so anyone on the list using permissive can
check they could actually switch to enforcing and not break things.
It will list things like ADD_USER, ADD_GROUP, FS_RELABEL, etc but as
long as there is no "AVC" it should be considered fine.


I really think the change should be fine for most people suceptible to
upgrade to a new version from now, I just don't like tools to tell me
XYZ won't work so I won't even try when it does work... I can understand
the community does not want to try to debug problems related to selinux
so feel free to replace it with a big warning or require an extra switch
for the user to say they're sure they want to run anyway, but this
should not (in my opinion) require modifying the code as a user.