TableOfContents

Overall Status

general

• main targets: cleanup, progress

  • user level compatibility with SL3 & Solaris is NOT

• for file distribution, prefer rpm over cfengine-copy-by-checksum
• clean up profiles! do NOT copy from SL3!
• no more hepixdm - replacement needed?

open questions

support only bash as the login shell?

• zsh has UTF-8 issues
• can we stop supporting tcsh as a login shell?
  • much effort especially since we have to change the profiles
  • not recommended anyway
• mapping of users' shells in local /etc/passwd is implemented

replace NIS/LDAP with local files?

Why not finally rid ourselves of all NIS/LDAP/nsswicth(compat...) problems?

• distribute /etc/groups (like we already do with netgroups)
• create /etc/passwd from a distributed master file (taking into account who gets a shell on the system)
  • this is available now, but needs some more testing and refinement
  • this would also make it easy to change all users' shells to bash

if yes: how to handle nscd?

• turn it off completely?
• or have different configurations (like: use for DNS only) ?
• need to adapt all features touching it
  • ldap
  • nagios
  • netgroup
  • nsswitch
• have a variable CF_nscd ?
  • values could be (off, on, dns_only, ...), feture would copy right config
  • which feature? nsswitch? or have a new one?

done

• CKS3.pl works (same script, input, location etc. as SL3)
• SL3U.pl works (same script as SL3, but need /opt/products/perl/5.8.2 - link to SL3 products is ok)
• AI client works
• aaru scripts work (same as on SL3)
• remapgroups works and is installed
• ppm, prpm, products feature
• staged errata, aaru feature
• KUSL3.pl, kernel feature
• automount feature
• postinstallation

roadmap

1. other priority1 features (sue) (?profiles?)
2. Milestone: Regular test systems
3. priority2 features
4. Milestone: Ready for special purposes
5. priority3 features
6. Milestone: public preview

little todos

• check: remapgroups in default.ys ?

features

SELinux and cfengine

the problem

Any files read by daemons covered by the targeted policy must have the correct type. The file /etc/passwd, for example, is read by nscd:

[root@satyr2 ~]# ls -Z /etc/passwd
-rw-r--r--  root     root     system_u:object_r:etc_t          /etc/passwd

Unfortuantely, cfengine is not aware of security contexts. Hence files it modifies may end up with the wrong context, and daemons may no longer be able to access them:

[root@satyr2 ~]# ls -Z /etc/passwd
-rw-r--r--  root     root     system_u:object_r:etc_runtime_t  /etc/passwd

These actions are known to have this problem:

• editfiles
• copy
• link

Even more unfortunately, many files (but not all) will still have the right context if a feature is run interactively, or even by cron, since in this case they run in the unconfined_t domain. This may change in the future, but so far the problem only affects features run from /etc/init.d/sue_boot The reason is that then processes run in domain initrc_t, with the result that newly created files may get a different context.

Hence to test the effect of a feature, run sue.update like this:

[root@satyr2 ~]# runcon -t initrc_t /products/sue/etc/sue.update ...

the solution(s)

modify the sue_boot init script

One step is obviously to run sue_boot in a different context, by adding this to /etc/init.d/sue_boot

RUNCON=""
if [ -x /usr/sbin/selinuxenabled ]; then
    /usr/sbin/selinuxenabled && RUNCON="/usr/bin/runcon -t unconfined_t --"
fi

and then changing the sue.update command to this:

$RUNCON /products/sue/etc/sue.update -v 2>&1 | cat

This seems to work the way it does normally (which is less than perfect since all output ends up in the sue update logs even if nothing was done), and it indeed solves most problems. Hence this should probably be implemented.

However, if the default type created in a directory is not the desired one, action must be taken in the features. Example:

• /etc/dhcpd.conf should be dhcp_etc_t, not etc_t

  • even if in this case dhcpd is still allowed to read the file, this may change eventually

  • and the file is not protected from other daemons allowed to read files of type etc_t but have no business with dhcp

use restorecon in features where appropriate

The restorecon command looks up the right file context(s) in /etc/selinux/targeted/contexts/files/file_contexts and sets the context accordingly for all files passed as arguments. It only works if SELinux is available in the kernel and enabled. If it is available but disabled, the command will complete successfully but the contexts will not be changed, hence no point in running it.

These are the ingredients for (cfengine2 only) feature to correct the filetypes:

•   control:
  
    actionsequence =
      (
        shellcommands.PASS1
        copy
        editfiles
        shellcommands.PASS2
      )
  
      AddInstallable = ( RESTORECON )

  It will often be necessary to introduce several shellcomands passes, since restorecon should obviously run after the files are modified, but before any daemons that need them are (re)started.

    groups:
  
      HAS_SEL = ( FileExists(/usr/sbin/selinuxenabled) )
      HAS_SEL::
        SELINUX = ( ReturnsZero(/usr/sbin/selinuxenabled) )

  This should work silently and with minimal overhead on any system. If the SELINUX class is set, restorecon should work.

    editfiles:
      { /some/file.1
        ...
        DefineClasses "RESTORECON"
      }
  
    copy:
      /repository/some/file.2
      dest=/some/file.2 type=checksum define=RESTORECON
  
  
    links:
      CLASS1::
        /some/file ->! ./some/file.1  type=relative define=RESTORECON
      CLASS2::
        /some/file ->! ./some/file.2  type=relative define=RESTORECON

  Here we make sure the RESTORECON class gets set if there is something to do for restorecon.

  At least in some cases, this only works if RESTORECON is declared AddInstallable, as shown above.

    shellcommands:
      PASS1::
        "/some/other command ..."
  
      PASS2::
        "/sbin/restorecon /some/file /some/file.1 /some/file.2"

  One could do this more fine grained, but it's probably not worth it.

Bugs in the distribution we need to fix

• SL 4.2: service dhcpd status buggy, always returns 0