KRB5 Credential Cache Move

The default location of a user's Kerberos Credential Cache (CC) has moved from /tmp to user directory under /run/user.

Back in the 1980's, when Kerberos was first developed, various login programs were enhanced to talk to the Kerberos servers to authenticate users, and to store credentials (tickets and session keys) that they obtained while doing so in a file, sometimes called a ticket file, but now more commonly called a credential cache (ccache for short), for the user to use during their session.

The cache had to be owned by the user, so that additional tickets obtained by the user could be added to the cache, and so that it could be cleared or just destroyed.

For the sake of users whose credentials were needed for accessing a remote home directory, login programs could not store the credentials in the user's home directory.  Since the only other location where a user could write to was the /tmp directory, the cache file was stored there by default.

Security Problems with the Credential Cache file in /tmp.

There were a couple of problems with storing the cache file in /tmp:

1. All users of the system can write to /tmp.  To sidestep the possibility that a rogue user could trick the system into writing a user's credentials to an incorrect location, many login facilities would generate uniquely-named credential caches for users.  Others used predictable but different names for various other reasons.
2. But when the name of a user's credential cache isn't predictable, it can cause problems for services which don't run as part of the user's session, and which therefore can't consult the $KRB5CCNAME environment variable to discover which cache to use.  Services like these, for example rpc.gssd (the daemon which handles the client parts of Kerberized NFS), have historically had to make a best-guess as to what the Kerberos credential cache file's name was, and they had to do that by trawling through /tmp, looking for potential matches.
3. /tmp can be setup using pam_namespace such that processes running in the "root" namespace will see a different /tmp then the user sees when he logs in.  This can prevent services from even being able to find the Credential Cache.
4. The /tmp directory is often not a temporary file system.   Logging out of the system or rebooting the system would not guarantee the Credential Cache would be removed/destroyed.

SSSD to the rescue in Fedora 18

In Fedora 18 the Credential Cache file was moved by SSSD, System Security Services Daemon, to /run/user/UID/krb5cc_XXXXXX/tkt.
Where XXXXXX is a random number. 

For example on my box when I execute klist i see the following:

> klist
Ticket cache: DIR::/run/user/3267/krb5cc_ca3a4331e17e8e80cb0c46ea507840bc/tkt
Default principal: dwalsh@REDHAT.COM

Valid starting     Expires            Service principal
10/12/12 12:48:17  10/12/12 22:48:17  krbtgt/REDHAT.COM@REDHAT.COM
    renew until 10/12/12 12:48:17

Note: There are two colons between "DIR" and the path part of the ccache name gives away that the parent of the named path is the directory that's being used to hold the cache file (or possibly more than one cache file).

The main benefit here is that /run/user/3267 and all its sub-directories have a mask of 700 and are owned by dwalsh:dwalsh. No other users know that the cache is there, and they can't tell how big it is or when it was last touched.  This means we don't have to deal with other users trying to mess around in /tmp.

 Secondarily /run is always tmpfs,  if the user logs out cache gets destroyed and if the system crashes the cache file is also gone.

Since the tickets are stored in a predictable path, privileged processes like rpc.gssd have an easy time finding the correct tickets.   And since they are off of /tmp, pam_namespace will not hide the credential cache from the system services.

Finally now SSSD can actually get multiple tickets from different domains and easily store them in the /run directory, allowing a user
to login into multiple kerberos domains at the same time.

• people.redhat,com and people.fedoraproject.com: I should login as guest_u:guest_r:guest_t:s0.  These machines are used to share content via the Web Servers.  I should be only allowed to modify my home directory.  I should not have access to the network, setuid applications like su and sudo, or be able to build and execute code in the home directory.
• shell.devel.redhat.com.  This machine is a shared developer shell machine, to be used by all developers.  I should be allowed to execute content in the home directory and maybe setup and test networking applications, since this is a development machine.  But I am not an administrator, I should not be allowed to execute su or sudo.  user_u:user_r:user_t:s0-s0:c0.c1023  would be a good SELinux user label for this machine.
• My Laptop and test machines, (holycross and redsox), should either be setup to use unconfined_t or staff_t.  In my case I run them with staff_u:staff_r:staff_t:s0-s0:c0.c1023, and administrator processes as staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023.

Note: In FreeIPA you can set up a set of the Host Based Access Control rules. These rules define which users (and groups of users) have access to which machines (and groups of machines) via which login services (like ssh, ftp, sudo, su etc.) The administrator can reuse the user-host associations defined in the HBAC rules to define SELinux user mapping rules. This helps to avoid duplicate management and express a notion: user set X can access set of hosts Y and would get SELinux user Z.

FreeIPA has a couple of new features that are showing up in Fedora 18.  Support for SELinux Confined User labelling will be covered in a future blog...  In this blog I will be talking about better integration with Windows environments.

I am saddened to realize that there are still people out there using Microsoft Windows!  

My house has been Windows free for a number of years now.  It is a lot darker, but much more secure! :^)

I also have heard that those Windows environments are using Active Directory. 

Well Fedora 18 will make these environments a little more secure.

FreeIPA and Active Directory can be setup with mutual trust.

In Fedora 18 it is possible to create a trust relationship between an FreeIPA and an Active Directory domain.  This means users defined in Active Directory can access resources defined in FreeIPA.  In a future release,  users defined in FreeIPA will be able to access resources defined in Active Directory.  You can manage all of your user accounts in a single place.  If you are using Active Directory to manage your users, you can now use the same user accounts on your Linux boxes.

Fedora 17 FreeIPA used winsync to allow users from an Active Directory domain to access resources in the IPA domain. To achieve this winsync had to replicate the user and password data from an Active Directory server to FreeIPA server and attempt to keep them in sync.  Causing potential race conditions.

In Fedora 18,  SSSD, System Security Services Daemon, has been enhanced to work with AD.  SSSD understands some of the native AD controls and features that it did not understand in the previous Fedoras. 

You can set this up without using FreeIPA at all!

In addition SSSD can work in the environment where it is connected to FreeIPA that is in trust relationships with AD. In this case, SSSD not only recognises users defined in FreeIPA but also recognizes users coming from the trusted AD domains.  SSSD can read user and group directory data directly from the Active Directory server.  

Additionally if you do use FreeIPA you can setup Kerberos cross realm trust.  This allows Single-Sign-On between the Active Directory and the IPA domain.

• A user from the Active Directory Domain can access kerberized resources from the FreeIPA domain without being asked for a password.
• If you choose to setup users in the FreeIPA Domain, they will be able to access resources from the Active Directory domain. No need to set POSIX attributes in the Active Directory Domain
• Single sign-on for all kerberized services is possible

• If a hacked process can write ~/.bashrc in a users home directory; the next time the user logs in, the hacker gets control of a process running as unconfined_t.
• If a hacked process can write to /etc/httpd/config, the hacker gets control of the Apache process.

For Fedora 17 I did a series of blogs on new security features. I guess it is time to start it for Fedora 18.
If you want me to talk about a new security feature,  email dwalsh@redhat.com, or comment on this blog.

New Feature in Fedora 18 SELinux Systemd Access Control.

In previous versions of Fedora/RHEL SELinux could control which processes were able to start/stop services based on the label of the process and the label on the Init Script.

For example NetworkManager (NetworkManager_t) was allowed to execute /etc/init.d/ntp (ntp_initrc_exec_t) but not allowed to access /etc/init.d/httpd (httpd_initrc_exec_t).

With the advent of systemd we lost this ability since systemd starts and stops all services.

We had to allow NetworkManager (NetworkManager_t) to execute systemctl which would send a dbus message to systemd, and systemd would start/stop whatever service NetworkManager requested. Actually we ended up allowing NetworkManager to do everything systemctl could do.   We also wanted to setup confined administrators, but we ended up having to allow them to either start/stop all services or no services.  We could no longer allow the webadm_t to only start/stop httpd_t.

In Fedora 18, we have fixed this by making systemd an SELinux Access Manager.  Now systemd will retrieve the label of the process running systemctl or the process that sent systemd a dbus message.  systemd will then look up the label of the unit file that the process wanted to configure.  Finally systemd will ask the kernel if SELinux policy allows the specific access between the process label and the unit file label.  This means a hacked NetworkManager or any other application that needs to interact with systemd for a specific service can now be confined via SELinux.  Policy writers can use these fined grained controls to confine administrators.

Policy changes.

We have added a new class to SELinux Policy called "service".  The service class has the following permissions defined:

start stop status reload kill load enable disable

This means a policy writer can allow a domain to get the status on a service or start and stop a service, but not enable or disable a service.  This gives us better control then we have ever had in the past.

To demonstrate this, I setup webadm_t as my root process:
Note: For more information on setting up confined users see my other blogs.

# id -Z
staff_u:webadm_r:webadm_t:s0-s0:c0.c1023
# /bin/systemctl status httpd.service
httpd.service - The Apache HTTP Server
      Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
      Active: inactive (dead)
      CGroup: name=systemd:/system/httpd.service

# /bin/systemctl status NetworkManager.service
Failed to issue method call: SELinux policy denies access.

In a separate window running as unconfined_t, I can look at the AVC message created.

# id -Z
staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# ausearch -m user_avc
time->Thu Sep 27 08:54:10 2012
type=USER_AVC msg=audit(1348750450.105:135): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } for auid=3267 uid=0 gid=0 path="/usr/lib/systemd/system/NetworkManager.service" cmdline="/bin/systemctl status NetworkManager.service" scontext=staff_u:webadm_r:webadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:NetworkManager_unit_file_t:s0 tclass=service  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

And of course you could use audit2allow to write policy to allow this access.

audit2allow -la
#============= webadm_t ==============
allow webadm_t NetworkManager_unit_file_t:service status;

# audit2allow -laR
#============= webadm_t ==============
networkmanager_systemctl(webadm_t)

Make sure you have the latest systemd and selinux-policy to try this out.  These are my current versions:

rpm -q selinux-policy systemd
selinux-policy-3.11.1-26.fc18.noarch
systemd-191-2.fc18.x86_64

1. Add the allow rules to allow udev to have all the access required to run his application
2. Write policy for his application and transition from udev and unconfined_t to this new domain.
3. Write policy to allow udev_t to transition to unconfined_t when running only his application.

• Try to connect to a few network ports like the mail port  - Out of the box we should not allow Apache to connect to many network ports.
• Read /secrets/mysecrets  - Random content on the file system should not be readable by Apache
• Read /home/dwalsh/creditcard.txt - Random content in a users home dir should not be readable by apace
• Read /var/lib/mysql/mysqld.data. - Database data should not be readable by Apache except if allowed through a constricted path like a unix domain socket.
• Try to run su or sudo, or strace, or network sniffer.