#9940 IPA - Not ready for CIS L1 - ipactl/
Opened by christian773. Modified

Outline

Hi there
Our corporate policy is CIS L1 hardening, currently we use rocky/rhel 9 for freeipa.
There are several issues we face so far, most of them are well known in other posts around.
BTW: https://lists.fedorahosted.org/ seems to be broken, is it not used anymore? SSO is not working.

VM Details

  • 4 CPU
  • 8GB Mem
  • Disk: 50g
  • SELinux: Enforced
  • Hardened with Anaconda (openscap profile)
  • Verifed with Ansible Lockdown
  • Packages
[root@replica ~]# rpm -qa | grep ^ipa
ipa-client-common-4.12.2-22.el9_7.1.noarch
ipa-selinux-4.12.2-22.el9_7.1.noarch
ipa-common-4.12.2-22.el9_7.1.noarch
ipa-client-4.12.2-22.el9_7.1.x86_64
ipa-healthcheck-core-0.16-9.el9.noarch
ipa-server-common-4.12.2-22.el9_7.1.noarch
ipa-server-4.12.2-22.el9_7.1.x86_64
ipa-healthcheck-0.16-9.el9.noarch

Setup Steps (for replica server)

# lower CIS L1 restrictions to allow freeipa installation
update-crypto-policies --set DEFAULT
cp -av /etc/crypto-policies/back-ends/opensslcnf.config /etc/crypto-policies/back-ends/opensslcnf.config.orig
sed -i 's/SECLEVEL=./SECLEVEL=1/' /etc/crypto-policies/back-ends/opensslcnf.config
nmtui
# set ipv6 to auto for nic
# ensure /dev/shm is not limited
# if wrong, you will get: "libdb - BDB0137 write: ...: No space left on device"
mount | grep shm
sed -i 's/,size=512m / /' /etc/fstab
systemctl daemon-reload
umount /dev/shm
mount /dev/shm
mount | grep shm
# set firewall rules
firewall-cmd --remove-service={cockpit,dhcpv6-client} --permanent
firewall-cmd --add-port={80/tcp,389/tcp,636/tcp,88/tcp,443/tcp,464/tcp,88/udp,464/udp} --permanent
firewall-cmd --reload
# verify chrony is working properly
chronyc sources
# IdM installation on FreeIPA replica host
grep $HOSTNAME /etc/hosts || echo "$(hostname -I) $(hostname -f) $(hostname -s)" >> /etc/hosts
hostnamectl set-hostname $(hostname -f)
dnf -y install ipa-server
# start with all the settings
reboot
# test connectivity to freeipa masters
ipa-replica-conncheck --replica freeipa-master01.domain.tld
# create snapshot of VM before joining
umask 0022
##### CAUTION ##########################################
# CIS L1 has umask of 027, must not get lowered if you want to keep up security
# we are not in a READ FOR EVERYONE WORLD
# register ongoing replica server to replicate with masters (ca role)
ipa-client-install --no-ntp --hostname=$(hostname -f) --mkhomedir --server=freeipa-master01.domain.tld --domain domain.tld --realm DOMAIN.TLD -p admin@DOMAIN.TLD --fixed-primary --force-join
# add host to freeipa server group
ipa hostgroup-add-member ipaservers --hosts $(hostname -f)

Problem1: healthcheck (on hardened system)

  • I would expect to get that running with umask 027, since this is standard for hardening
    We currently wrap around with shell script, but its soo ugly
[root@replica~]# umask
0027
[root@replica~]# ipa-healthcheck --output-type human | grep -v -i dns
WARNING: ipahealthcheck.ipa.files.IPAFileNSSDBCheck: Unexpected umask 0o027 expected 0o022, skipping file permissions.
WARNING: ipahealthcheck.ipa.files.IPAFileCheck: Unexpected umask 0o027 expected 0o022, skipping file permissions.
WARNING: ipahealthcheck.ipa.files.TomcatFileCheck: Unexpected umask 0o027 expected 0o022, skipping file permissions.

freeipa is after reboot not in same state as after ipactl stop/start on hardened system

  • If you reboot, services are handled with umask 022 (which is not nice, but we must accept)
  • if you restart services with hardened user (umask 027) services (or sate files) are not in same state as after reboot
# after fresh boot, all services are running as expected on CIS L1 hardened system
[root@replica~]# uptime
 11:12:30 up 0 min,  2 users,  load average: 7.56, 1.71, 0.56
[root@replica~]# umask
0027
[root@replica~]# ll /run/ipa/services.list   ### AFTER REBOOT, SERVICES START WITH UMASK 022
-rw-r--r--. 1 root root 83 Feb  9 11:12 /run/ipa/services.list
[root@replica~]# umask
0027
[root@replica~]# ipactl stop > /dev/null
ipa: INFO: The ipactl command was successful
[root@replica~]# ipactl start > /dev/null
ipa: INFO: The ipactl command was successful
# ONCE YOU RESTARTED WITH HARDENED UMASK (027), PERMS ARE NOT SAME AS AFTER REBOOT
[root@replica~]# ll /run/ipa/services.list
-rw-r-----. 1 root root 83 Feb  9 11:13 /run/ipa/services.list
[root@replica~]# ipa-healthcheck --output-type human | grep -v -i dns
WARNING: ipahealthcheck.ipa.files.IPAFileNSSDBCheck: Unexpected umask 0o027 expected 0o022, skipping file permissions.
WARNING: ipahealthcheck.ipa.files.IPAFileCheck: Unexpected umask 0o027 expected 0o022, skipping file permissions.
WARNING: ipahealthcheck.ipa.files.TomcatFileCheck: Unexpected umask 0o027 expected 0o022, skipping file permissions.
[root@replica~]# umask 022
[root@replica~]# ipa-healthcheck --output-type human | grep -v -i dns
ERROR: ipahealthcheck.ipa.files.IPAFileCheck._run_ipa_services.list_mode: Permissions of /run/ipa/services.list are too restrictive: 0640 and should be 0644
[root@replica~]# ipactl stop > /dev/null
ipa: INFO: The ipactl command was successful
[root@replica ~]# ipactl start > /dev/null
ipa: INFO: The ipactl command was successful
[root@replica ~]# ll /run/ipa/services.list
-rw-r--r--. 1 root root 83 Feb  9 11:16 /run/ipa/services.list
[root@replica~]# ipa-healthcheck --output-type human | grep -v -i dns
# now you see, error is gone
  • I can say, It is possible to do lot of hardening and you can come close to CIS L1, but I guess its not a standard in public
  • It would be nice to have a place for documentation and proper bug reporting, like github issues.

Thanks Chris


For our OPS Team, we created workaround/wrapper its some way nice and some way ugly
* /etc/profile.d/ipactl.sh

#!/bin/bash
ipactl() {
    D_UMASK=`umask`
    if [ "$D_UMASK" != '022' ] ; then
      echo "DEBUG: enforcing umask 022 for ipactl via /etc/profile.d/ipactl.sh"
      echo "DEBUG: see https://pagure.io/freeipa/issue/9940"
      umask 022
    fi
    /usr/sbin/ipactl "$@"
    umask $D_UMASK
}
ipa-healthcheck() {
    D_UMASK=`umask`
    if [ "$D_UMASK" != '022' ] ; then
      echo "DEBUG: enforcing umask 022 for ipa-healthcheck via /etc/profile.d/ipactl.sh"
      echo "DEBUG: see https://pagure.io/freeipa/issue/9940"
      umask 022
    fi
    /usr/bin/ipa-healthcheck "$@"
    umask $D_UMASK
}

IPA explicitly does not support a umask other than 022. It can be forced to work, as you've seen, but there are warts.

Newer ipa-healthcheck will skip reporting when umask is not 022.

Metadata