Review Security of LCFG Profile Access

This is the home page for project #402. See also the project blog for progress reports.

Limiting access to LCFG profiles needs to be done on both the server and the client.

Server Side

Currently LCFG profiles are accessible from the server via both http and https protocols with access restricted using IP address

We would like to drop http access so that data is only transferred to the client in an encrypted form. Switching to SSL also allows verification of the certificates and thus the client can trust the profile sources.

Furthermore we would like to switch from IP based restrictions to using GSSAPI authentication. This would limit access to LCFG clients with a host/ principal (or possibly lcfg/) and a list of admin user principals.

Several things need to be done on the server side:

  • Subject Alternate Name support for locally generated certificates in sixkts/x509 - This is needed by the LCFG servers as they have both specific and generic names (e.g. lcfg1, lcfg2 and also lcfg, lcfghost). This was added in sixkts version 0.0.40. DONE
  • Generate Apache .htaccess files for each profile which use mod_auth_gssapi. Support for this was improved in LCFG-Compiler version 3.6.2, all profiles need to move from profile schema 3 to 4. DONE
  • We will probably need a local template for .htaccess to make it easy to do the admin group authorisation.
  • Drop http support (close port 80 or redirect?)
  • installbase profiles would probably need to be accessible from all hosts, possibly with IP limits, this would mean ensuring that those profiles do not contain any sensitive information such as passwords. This shouldn't be a problem as the main purpose of those profiles is for specifying an initial set of packages.

Client Side

There are several separate areas which need attention on the client side. Changes are required to the lcfg client itself to mirror those made on the server. Further to that the profile is stored in various file formats which are accessed using tools such as qxprof and sxprof, access to that data is controlled via Unix file permissions. Reducing the access to these files will stop qxprof working for normal users and also admins unless they become root, would we want to provide a mechanism for overcoming that issue? Could it be solved as simply as putting admins in the lcfg group or maybe something PAM based?

XML Profile Fetching

  • Currently the LCFG client only has support for username/password authentication. This needs to be extended in such a way that other approaches can be used including, but not limited to, GSSAPI. DONE
  • The configuration of the LWP for SSL needs improvement. In particular the ability to configure either of the SSL_ca_path or SSL_ca_file options for the LWP::Protocol::https module is required. See also IO::Socket::SSL for details of SSL options. If nothing specified, the default comes from Mozilla::CA. DONE
  • For GSSAPI authentication the LCFG client needs some way to effectively do a kinit with a keytab. Alternatively k5start could be started in the background and the client could use the credentials cache managed by that tool. GSSAPI authentication with LWP is simply a matter of having the LWP::Authen::Negotiate perl module available. On dice this is already provided by the perl-LWP-Authen-Negotiate package. DONE
  • There are bootstrapping problems at install time which need to be overcome, possibly by changing the lcfginstall script in the lcfg-installroot package. Currently the host/ principal is fetched using kdcregister at the end of the first stage of the install after the first set of installbase packages are installed. If the client needs to authenticate using GSSAPI then that kdcregister step needs to be moved much earlier in the process. Alternatively the admin could be prompted immediately after starting the install to enter Kerberos credentials (e.g. foo/admin) which are used to fetch the profile and then later used again for the kdcregister step once the system is partitioned and the first set of packages are installed.
  • It would be easy enough to add new resources to support the auth modules but to be able to pass arbitrary parameters to the fetch routine in rdxprof will probably require use of a config file rather than command line arguments. There is already support for a YAML configfile in rdxprof but the client component would need updating to generate that file, most likely that means rewriting the client component in Perl. DONE

Although not related to this project, while the profile fetching code is being improved it probably makes sense to also add support for IPv6 DONE

Profile DBM

The current state of the LCFG profile is stored in the Berkeley DB file in /var/lcfg/conf/profile/dbm/. Access to the DBM file is limited by Unix file permissions, currently the mode is 0444 with owner root and group lcfg. Could the read access for other just be dropped?

Profile Status Files

The state of the resources for each component are also stored as status files in /run/lcfg/status/. Access to the status files is limited by Unix file permissions, currently the mode is 0644 with owner root and group lcfg. Could the read access for other just be dropped?

Component directories

We should decide what permissions are required for all the various client directories:

  • /run/lcfg
  • /run/lcfg/status
  • /var/lcfg/log
  • /var/lcfg/tmp
  • /var/lcfg/conf

LCFG logserver

The logserver provides access to the LCFG resources for a machine. Currently logserver does not have any authentication/authorization support. Need to think about how to limit access here...

-- StephenQuinney - 13 Mar 2018

Topic revision: r5 - 29 Mar 2018 - 15:12:20 - 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