Final Report : Review Security of LCFG Profile Access (402)

This project was split into two main areas of work - support for secure fetching of the LCFG XML profiles and tightening up of access to the LCFG client-side files.

Profile Fetching

The code in the LCFG client for fetching profiles has been completely replaced with a new LCFG::Client::ProfileFetcher module. This provides full support for https with certificate validation. This new module has the ability to use authentication helper modules, by default Basic and GSSAPI authentication mechanisms are supported, others can be added as required in the future. Other improvements include full support for IPv6 and better handling of DNS changes for LCFG servers.

The LCFG server support for generating Apache .htaccess files was completely overhauled. It is now possible to control which template is used on a site-wide or per-profile basis. This means that if the standard templates are not sufficient for a site's needs they can provide their own. The access files are now removed when no longer required to avoid the possibility of leaving configuration in place which might override the currently managed files.

The LCFG installer needed modifications to overcome bootstrapping issues related to the GSSAPI authentication requirement. Immediately after starting the install the user is now prompted to authenticate with their admin principal. The tokens acquired are used for both the initial profile fetch and the kdcregister process which adds the hostclient principal to the host keytab. This means we have to allow access to the /admin principals where ideally we would only use /root principals but we don't really want to force the user to authenticate twice during the install process. Could we provide a way for users with /root principals to run kdcregister and thus avoid the need for /admin principals during the install?

Traditionally we have limited access to the XML profiles only by IP address, this made examining alternative profiles very easy for the Informatics Computing Team. The change to GSSAPI means that access is much more secure but it clearly makes the process of manually fetching profiles using rdxprof a bit more awkward.

The switch to requiring GSSAPI authentication for profile access meant that some of the LCFG nagios monitoring code also had to be modified. As the new LCFG::Client::ProfileFetcher module was designed for it to be possible to use separately from the rdxprof daemon this was a relatively straightforward change to the LCFG::Monitoring::Client module. Beyond that it was mostly a case of adding some new resources to the nagios_server component and then passing through the settings to the profile fetcher.

We took a fairly cautious approach to deployment of these changes so moving machines over to using GSSAPI authentication was something of a long process. Firstly they were moved over to using https, secondly they were configured to support GSSAPI and finally the authentication requirement was enabled on the LCFG servers. Between each stage we had a long period of watching to ensure that no problems had been introduced. This meant that the final switch over to GSSAPI authentication went very smoothly. We left http access untouched during this process so that it would be easy to fall back if necessary. Regular checking of the apache access logs revealed a few machines in unusual states which didn't initially make the change. Rather than immediately disabling http support the access will be restricted to localhost only for several more months so that any access failures will be logged.

LCFG client file permissions

Several different approaches were considered for controlling access to the client side files. One idea that was considered was to add support for PAM authorisation to the relevant scripts (e.g. qxprof and sxprof). This was rejected due to the high level of complexity involved and the need for new setuid wrapper scripts. It also didn't fit well with the need to be able to query the resources using the various LCFG Perl libraries.

The decision was made to use Unix file permissions to control access. This has the benefit of being simple, understandable and easy to manage. A new lcfg unix group was introduced to which users can be added when they require read access for LCFG resources. By default the group is empty, it is now just a matter of local policy as to whether non-root users can read LCFG resources.

In Informatics all members of the Computing Team have been added to this group to retain read access. In the future we may wish to reconsider this in the light of plans to minimise adminstrator rights for our personal accounts.

One issue with this new approach is that it is very much "all or nothing". There is no way to limit read access to the resources of individual components. These changes have revealed a number of situations where scripts run as non-root system users use qxprof to query resources. The quick solution has been to add the user to the new group. The downside is that this gives, for example, the apache user, complete read access to all components which is what we were trying to remove. The ideal solution in most cases is for the relevant LCFG component configure method to write out the required resources to a configuration file (it could also be done simply enough with the file component) which the script can then load. Where necessary the permissions on the generated configuration file can be restricted to the specific user. As well as being more secure this is generally a better way of working as it introduces a degree of separation between the scripts and the LCFG framework.

One possible solution for allowing real users to read certain resources might be to add a query method to the ngeneric framework which would provide an interface to qxprof. Access to this method could then be controlled in the standard way using the om utility.

Related to these changes the Perl LCFG::Component framework gained support for a new ng_umask resource. This can be used to set the default umask before the actual work of any methods is done. This helps avoid inadvertently creating insecure files. Currently this has to be enabled on a per-component basis and it is not widely used (only auditd and sudo components). We should consider switching to a standard secure default umask (e.g. 077), this would require some changes to many components though where specific file permissions would then need to be opened up again.

Additional Benefits

  • The LCFG client component was rewritten into Perl so that the settings for all options can be easily written into a YAML configuration file rather than a subset being controllable via the command-line.

  • The management of the rdxprof daemon was moved over to systemd which has massively simplified the component code.

  • The om utility gained support for preserving the values of environment variables. This is inspired by the sudo env_keep option, the names for environment variables which must be preserved for calls to a component should be added to the om_env_keep resource.

  • The apacheconf component gained support for managing simple groups of users which can be used for authorisation with the apache Require group directive.

Future Work

The original plan for this project had included improvements to the LCFG logserver. This turned out to require a lot more work, probably a complete replacement, so it has been split off into a separate project (#545)

Total Effort

Period Effort
2018 T1 113
2018 T2 47
2018 T3 38
2019 T1 48
2019 T2 17
2019 T3 16

Total: 279 hours ( 40 days / 8 weeks )

-- StephenQuinney - 16 Dec 2019

Topic attachments
I Attachment Action Size Date Who Comment
pdfpdf profsec_project_blogging.pdf manage 112.9 K 16 Dec 2019 - 13:02 StephenQuinney blog articles from project
Topic revision: r3 - 01 Jun 2020 - 13:27:38 - StephenQuinney
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies