LCFG Profile Security Project

June 12, 2018

The various changes necessary to add support for GSSAPI authenticated profile fetching have now been moved from our local dice configuration into the general lcfg area. The new support can be enabled by specifying the LCFG_AUTH_GSSAPI macro at the start of an LCFG source profile. Most of the resources necessary are configured in the lcfg/options/lcfg-client-gssapi.h header file but sites wanting to use this will still need a little additional configuration.

For the installer, support is enabled by setting the lcfg.kauth=1 option on the kernel command line. Those sites using the ed/options/pxeserver.h header will automatically get a menu option which supports this mode. The installer can be be enabled for a client with something like this:

#ifdef LINUX_EL7
#ifdef LCFG_AUTH_GSSAPI
!pxeclient.platforms            mREPLACE(sl7,sl7kauth)
!pxeclient.default_label        mSUBST(sl7,sl7kauth)
#endif /* GSSAPI support enabled */
#endif /* LINUX_EL7 */

It is important to note that the lcfg-client-gssapi.h header does not remove http access for the XML profile. That could either be turned off completely for the apache virtual host or a per-client deny all rule could be put into the associated .htaccess file. Also, the default access control for the XML profiles is based on an apache group named lcfgadmins which must be populated on the LCFG servers, for example:

!apacheconf.groups   mADD(lcfgadmins)
!apacheconf.members_lcfgadmins mSET( 
  alice/admin@EXAMPLE.ORG
  bob/admin@EXAMPLE.ORG
  carol/admin@EXAMPLE.ORG
)

Note that this is a list of admin principals, this is done so the credentials can also be used to register machines in the KDC using the kdcregister tool.

As part of this work I’ve also added the necessary methods to support using kdcregister in the LCFG installer. Most sites use this and have up to now been duplicating the configuration. It can be enabled by specifying the LCFG_OPTIONS_KERBEROS_CLIENT_REGISTER macro prior to including the lcfg/options/kerberos-client.h header file.


LCFG apacheconf improvements

June 1, 2018

I know that the LCFG apacheconf component is one of the more widely used of the non-default components so I thought it worth summarising some recent changes.

  1. Groups support

    It’s now possible to manage simple apache groups through apacheconf resources like this:

    !apacheconf.groups mADD(admins)
    !apacheconf.members_admins mSET(user1 user2 user3)
    

    By default these are stored in the file /etc/httpd/lcfg.groups.d/general but that can be changed on a per-group basis. Within your apache configuration this can then be used like this:

    AuthGroupFile "/etc/httpd/lcfg.groups.d/general"
    Require group "admins"
    

    Of course, the authz_groupfile module needs to be enabled, that’s the default on EL7.

  2. sysconfig support

    Occasionally it is necessary to set extra environment variables before starting apache. This is best done through the /etc/sysconfig/httpd file. Previously the name of the template for this file was hardwired in the component code so that it was not possible to generate truly site-local config. There is now an apacheconf.sysconfig_tmpl resource which can be used to switch the template name.

  3. virtualhosts with multiple addresses

    The support for virtualhosts which listen on multiple explicit addresses has been improved. This is where the virtualhost block
    starts like:

    <VirtualHost 192.168.1.1:443 192.168.1.2:443>
      ...
    </VirtualHost>
    

    Previously, due to a bug in the template, the default port (from the apacheconf.vhostaddr_tag resource) was only applied to the final address in the list. Further to this, if any of the addresses have an explicit port which differs from the default for the vhost it will now be honoured.

  4. template paths

    For convenience, all template paths specified through resources may now be expressed as relative paths (e.g. sysconfig.tmpl), there’s no need to know where they are stored in the local filesystem.

  5. nagios translator

    I believe this is only used by Informatics. I’ve improved the way the IP address for monitoring each vhost is selected. This fixes a couple of peculiar problems we’ve been seeing with nagios that meant the host problems were permanently acked. I’ve also added IPv6 support although it’s not clear what the nagios checks would do with such addresses. There’s still room for improvement here but that will require a more extensive refactoring of the code.