LCFG ngeneric kinit plugin

April 26, 2018

I’ve recently put a bit of work into making the LCFG ngeneric kinit environment initialisation plugin more generally useful. Prior to Kenny’s helpful tip on getting the gssapi library to do most of the work I had planned to use this plugin within the LCFG client for Kerberos authentication when fetching profiles. It can now manage the credentials cache in a similar way to k5start with renewing the credentials whenever they expire or are within a certain time before expiry. So, it’s now possible to do this from any Perl code:

use LCFG::Component::Plugin::Kinit;

my $plugin = LCFG::Component::Plugin::Kinit->new(
    params    => {
        keytab    => "/etc/lcfg/client.keytab",
        principal => 'lcfg/test.example.org@EXAMPLE.ORG',
        group     => 'lcfg',
        mode      => '0640',
    },
);
$plugin->run();

I’ve also added support for specifying the owner, group and mode of the credentials cache file (bug#1061) and improved support for controlling whether the cache file is removed automatically when the calling process ends. At the same time I have resolved a longstanding issue with calling the run method multiple times (bug#1060) which is hit for, at least, when an LCFG component restart method is used.


LCFG Profile Security Project

April 25, 2018

Having added support to the LCFG installer for prompting the user for a Kerberos principal at the very beginning of the process it would be nice to be able to use that for all other steps which need authentication. In particular, the call to kdcregister to create the host keytab file should not need to also prompt the user for the principal and password. I quickly discovered this is a slightly awkward problem because the kdcregister command is issued via the baseinstall component which is called using the om command. When calling any component method om will firstly clear the environment to make it safe. This means that the path to the credentials cache, which is usually found from the KRB5CCNAME environment variable, is not available to kdcregister. I considered various approaches to solving this problem and eventually concluded that om needed a new feature which would be similar to the env_keep option support by sudo. This can then be used to specify a list of environment variables which will not be cleared. Using this feature is straightforward, the LCFG schema for om, which is inherited by most components, now includes an om_env_keep resource. The feature is supported in version 0.13.1 of the lcfg-om package which will be in the next weekly stable release.


Hiding process listings

April 20, 2018

We have recently been considering what might need to be done to ensure we meet the requirements of the new GDPR legislation. One question raised was whether we should be hiding process listings, whilst we don’t feel that’s going to be necessary it did get me investigating how it could be done. It turns out that this is actually very straightforward with pretty much any modern Linux kernel (probably not SL6 but certainly EL7 onwards). There is a hidepid mount option for the /proc filesystem with two possible levels of hardening, I found this article on the Linux Audit site gives a reasonable summary. Having worked out what I wanted it to do it then took me a while to work out how it could be achieved. On EL7 the /proc filesystem is mounted automatically and by default does not appear in the /etc/fstab file so I was unsure as to where the mount options could be configured. Eventually I was pointed at this helpful Redhat bug which explains that any filesystem listed in /etc/fstab which is already mounted just gets remounted with the correct options. I’ve now tried it on a couple of test machines and it seems to work as required, ps and top will only list those processes owned by the user. This would probably be a good idea on multi-user graphical login machines (e.g. our NX and RDP hosts) to protect users against leakage of personal information via process command lines so we’re going to apply the changes to those services and see how the users get on. For any other LCFG users who would like to try it out there is an lcfg/options/privacy/procfs.h header which will appear in the stable release next week.


LCFG Profile Security Project

April 18, 2018

Having completed the work to add support for GSSAPI auth to the client for fetching profiles I’ve now moved on to the LCFG installer. Currently the installer attempts to fetch the LCFG profile for the machine just prior to the (I)nstall, (D)ebug, (S)hell, (P)atchup, (R)eboot prompt. That fetching is done by calling the client component install method which in turn calls rdxprof in one shot mode. Having previously ported the client component to the Perl LCFG::Component framework I had hoped this would “just work” but it turned out that a number of bootstrapping issues were only being avoided previously due to many hardwired paths in the shell ngeneric code. The Perl framework takes a different approach and prefers to use the LCFG sysinfo resources wherever possible, this improves platform independence and maintainability but presents a bootstrapping problem at the first stage of the install when we have not yet downloaded any profile and thus have no sysinfo resources… I wasn’t keen on performing major surgery on the Perl component framework so I decided that the simplest solution to this problem was to get the installer to call rdxprof directly. With this change the installer worked again but still required support for Kerberos authentication.

Adding support for Kerberos authentication has been done in a fairly simple way. I’ve added support for two new install kernel command line options: lcfg.kauth and lcfg.realm. When the lcfg.kauth option is specified the user is prompted to enter their principal name and the kinit program is run to do the authentication. The user may specify the full principal name, if the realm is not specified then either the lcfg.realm option or the upper-cased domain name is used (e.g. @LCFG.ORG). If the authentication fails then the user is prompted to re-enter the principal name (which defaults to the previously entered string) and password. Once the Kerberos authentication has succeeded the credentials will be automatically used by rdxprof when required for fetching the LCFG profile.