RHEL 6.4 SELinux user mapping

Normally, Red Hat does a decent job on their release notes about explaining what a new feature or change brings with each new RHEL minor release, but this time the release notes did not do the full scope of the change justice:

SSSD Fully Supported Features
A number of features introduced in Red Hat Enterprise Linux 6.3 are now fully supported in Red Hat Enterprise Linux 6.4. Specifically:

• support for central management of SSH keys,
• SELinux user mapping,
• and support for automount map caching.

The key line here was "SELinux user mapping".  This played in with IPA to generate some undesirable results, since the installation of IPA that was serving these systems did not have any SELinux user mapping defined, other than the default role.

Prior to the upgrade, mappings were not enforced, so the SELinux context was unconfined:

$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Post upgrade, the IPA default user was enforced.  This was not obvious at first, though.  The symptoms were that things that normally worked, didn't: sudo, su, dmesg, looking at log files.  Standard sysadmin diagnostics stuff suddenly stopped working completely.  

Trying to dig into this lead to very strange results, like not being able to run ls -l /bin/su directly and getting "?" for the su record when running ls -l /bin.  The same kind of strange behavior happened to /var, /root, and a few other key areas.  It behaved a lot like filesystem damage at first, but the fsck came back clean.  Logging in as root on the system console did work though, so that was my first clue.

Because this behavior was so bizarre, I tried a setenforce 0 to rule out SELinux, and all of a sudden things started working for non-root users logged in remotely.  I have been used to beating SELinux into submission a daemon context, but this was the first time I'd run into it as a user.

$id -Z
guest_u:guest_r:guest_t:s0-s0:c0.c1023

Up until now, there were no SELinux User Maps in IPA, so default mapping to the guest role was being used.  Thus, the first step was to define some non-guest roles to use.

There was not a lot of information about this on the IPA wiki, but I did find a decent writeup about configuring SELinux on Gentoo's site.  This gave me the key pieces that I needed to setup a map for the user_u:user_r:user_t and the staff_u:staff_r:staff_t mappings for mere mortals and sysadmins.

Amazing what happens when you have permissions to actually run things!

The next step required was to cleanly handle the staff_t to sysadm_t transition for sudo without requiring a separate newrole command to be run.  Thankfully, sudo is SELinux aware, so adding "role=sysadm_r" to the Sudo Rule in IPA that allows sysadmin commands took care of that part.

Using IPA with EZproxy: Where the Wildcards Aren't

Fedora's FreeIPA project is an interesting piece of software that has pulled together several pieces of open source software and given it a point-and-click interface as something of an answer to Active Directory.

The major pieces are the BIND DNS server from ISC, the 389 Directory Server (which started its life as the Netscape Directory Server so many moons ago), DogTag Certificate Server (also of Netscape lineage), and MIT Kerberos.  Each of those packages can be daunting to setup on their own, but the IPA project has done an admirable job of integrating them and making their setup and use simple.

I have been tracking the evolution of IPA for some time now and have finally decided to take the plunge.  So far things have been fairly smooth, with one exception:

IPA does not currently support wildcard DNS.

For a lot of people this would not matter, but when combined with EZproxy in a proxy-by-hostname configuration, it becomes a major problem, since wildcard support is key to its function.

The root of the problem is that the software that ties the DNS server to the LDAP storage engine -- the creatively named bind-dyndb-ldap -- does not support wildcard DNS entries yet.  Like others, when the UI did not allow me to create the wildcard entries, I opened up my favorite LDAP editor (Apache Directory Studio) and created an entry manually.  Alas, it was not a simple UI issue, but rather non-support in the back-end software.  There are bugs entered for both IPA (3148) and bind-dyndb-ldap (95) to track the issue.

Until that is addressed, sites that adopt IPA and use EZproxy need a work-around for this issue.  All both of us.

Now in a traditional BIND setup, you could of course use wildcard entries directly, or you could just point the NS record at the EZproxy server a documented by OCLC on the DNS configuration page, and enabling the DNS functionality built into EZproxy:

ezproxy.example.edu IN A 192.0.2.1
ezproxy.example.edu IN NS ezproxy.example.edu.

Unfortunately, adding that NS record does not seem to work in IPA.  I have not yet taken time to peel back the layers of the onion to figure out exactly why it does not work and where it fails, but adding a NS record for the EZproxy host to IPA caused the lookups to fail completely when they were added to the host entry.

I tried a few other approaches to get this to work in IPA -- setting up a dummy zone for the proxy server and changing with the zone forwarder settings, putting the host and the service names in different zones -- to no avail.  Some approaches looked more promising than others, but none ultimately worked.

Clearly I was not going to be able to address this in the 2.2.0 release of IPA, and would need to go outside the system until wildcard support is natively supported.

My first instinct was to just setup a traditional BIND zone file for each proxy server.  This certainly worked, but required both a named.conf entry, as well as a separate file for each proxy server "zone".  I wanted a solution that would involve less configuration litter to clean up later.

What I finally settled on was setting up simple static-stub zones in BIND with forwarders set to EZproxy:

zone "ezproxy.example.edu" IN {
  type static-stub;
  server-named { "ezproxy.example.edu"; };
  forwarders { 192.0.2.1; };
};

It feels a little dirty having to resort to that, and I'm reminded of the scene from Star Trek: First Contact where Dr. Crusher mutters "I swore I'd never use one of these things" as she activates the Emergency Medical Hologram to create a diversion as she escapes the Borg, but it does work and will buy time until the bind-dyndb-ldap developers can figure out how they want to support wildcard DNS entries.