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

• 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.

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

• 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.

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.

Secure Linux Containers

In Fedora 18 we have enhanced the virt-sandbox package to allow for easy creation of Secure Containers.

Containers are a form of isolating one or more processes from the rest of the system.  Some times containers are described as lightweight virtualization.  Containers are really just a userspace concept.  The Linux kernel has no concept of a container.  The kernel implements namespaces and cgroups.  Userspace tools can combine these kernel services into a "container".

Namespaces

Namespaces are a way of changing a processes view of its environment from its parents processes.  For example the file system namespace allows me to change a processes view of the file system hierarchy.  pam_namespace introduced way back in Fedora 6/RHEL5, allowed a login program to create a namespace and mount file systems that would not be seen by the ancestor processes.  Meaning I could have multiple processes with different /tmp directories and multiple home directories mounted on /home/dwalsh.

The kernel currently implements 5 name spaces.

1. mount - mounting  and unmounting filesystems will not affect rest of the system 
2. UTS - setting hostname, domainname will not affect rest of the system
3. IPC - process will have independent namespace for System V message queues, semaphore sets and shared memory segments
4. network - process will have independent IPv4 and IPv6 stacks, IP routing tables, firewall rules, the /proc/net  and  /sys/class/net  directory trees, sockets etc.
5. pid - processes have an independent pids from the rest of the system.  Each namespace can have its own pid 1. 

CGROUPS

Wikipedia describes cgroups as:

  cgroups (control groups) is a Linux kernel feature to limit, account and isolate resource usage (CPU, memory, disk I/O, etc.) of process groups.

Basically you can use cgroups to control the amount of resources a process or groups of processes can get on a system. 
I put together a little screen-cast of cgroups to demonstrate their power.

LXC
Tools like LXC have existed for a while to allow users to create containers but the tool set is at a very low level. 

Libvirt-lxc

"Libvirt is a C toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes). The main package includes the libvirtd server exporting the virtualization support."

libvirt-lxc was introduced in Fedora 16. It enhanced the libvirt API to allow users to build containers using libvirt.  This allows you to manage your kvm/qemu virtualization along with your linux containers, all within the same framework.  The only problem, is setting up a linux container using the libvirt api is fairly difficult.

virt-sandbox

Dan Berrange created a new package called virt-sandbox in Fedora 17.  The virt-sandbox package provides an application development library (libvirt-sandbox) to facilitate the embedding of virtualization into applications.  One of the main advantages of this new tool set, was that it greatly simplified the API for creating virtual machines and containers.

SELinux

Using containers by itself does not give you good security separation.  The reason for this is kernel file systems like /proc, /sys, cgroupsfs and selinuxfs are not containerized.  A privileged process running within a container can affect other processes running outside of the container or processes running in other containers.  In virt-sandbox and libvirt-lxc you can use SELinux Labelling to further lock down privileged processes, for example preventing mounting of random file systems or stopping processes from disabling SELinux. 

virt-sandbox-service

Dan Berrange and I have been working to enhance virt-sandbox.  We have added a command line tool called virt-sandbox-service which allows a user to easily create an application sandbox.  virt-sandbox-service allows an administrator to run multiple services on the same machine each service in a secure Linux Container.   Some major features of virt-sandbox-service containers.

• Use systemd within the container as the init processes.
• Uses standard unit files for starting and stopping containerized applications.
• Shares the /usr partition, meaning if you are running hundreds of Apache containers, and update Apache code, each container will instantly use the new version of Apache.
• Uses SELinux MCS Labelling to separate each container, preventing even root processes from interfering with the host or other containers.

Use the virt-sandbox-service command to create a container.

virt-sandbox-service create -C -l s0:c1,c2 -u httpd.service container1
Created sandbox container dir /var/lib/libvirt/filesystems/container1
Created sandbox config /etc/libvirt-sandbox/services/container1.sandbox
Created unit file /etc/systemd/system/container1_sandbox.service

Manipulate the data within the container while running outside of the container.

cd /var/lib/libvirt/filesystems/container1/var/log
touch content
ls -lZ content
# Make sure the content gets created with the correct MCS label.
# Content should be labeled with s0:c1,c2 : Not s0

Now create a file with a bad label for the container.
cat "Secret" > badcontent
chcon -l s0:c3,c4 badcontent
 

Start the container:

virt-sandbox-service start container1

In another window

Make sure the processes are running with the proper SELinux label. ps -eZ | grep svirt_lxc You should see processes like systemd, systemd-journal, dhclient and httpd running within the container with the MCS label of s0:c1,c2

Connect to the container

virt-sandbox-service connect container1
id 
getenforce   # Should tell you SELinux is disabled.
setenforce 1 # Should be denied
touch /file  # Should deny you creating this file
touch /var/www/html/content  # Should be allowed
cat /var/www/html/badcontent # Should be denied
Configure the apache server any way you would like, and manipulate html pages
ifconfig eth0  # Grap IP Address for use on next test
# Use the shell running with in the container to attempt to break out of the container. 
^] 

On your hosts Firefox use the IP within the container

firefox $IP # Using IP address from container, make sure you see the content.

Shut down the container

virt-sandbox-service stop container1

Now lets try to do the same but starting and stopping the container using systemctl commands

systemctl start container1_sandbox.service
systemctl enable container1_sandbox.service # Check on reboot if the container is running

Make sure the container is running.

virt-sandbox-service connect container1
ps -eZ
^]

I would like to hear what you think?  What enhancements you would like to see?  What 
applications would you like to see run within the containers.  

Since this is a first version, we think there could be some growing pains, so use at your own 
risk, but we would love to work with the community to improve this tool set.

• Process types associated with the domain, the tool attempts to associate all process types that begin with the same prefix as the target domain.
• File Types associated with the domain.   This will list all file types that are included in this policy.  (Using the prefix to gather the information)  The man page describes what the type is used for, along with the default path labelling on the system.
• Booleans associated with the domain.  The manpage lists all booleans matching the prefix and then describes what the boolean is used for. 
• Port Types associated with the domain.  The manpage lists the port types matching the prefix and describes the default port numbers assigned to these port types.
• Sharing Types associated with the domain.  If the domain uses "Sharing Types"  like public_content_t, the man page will have a section explaining how to use them.
• Managed Files section describes the types that the domain is allowed to write and the default paths associated with these types.

• What process domains can one process domain transition too?
• Can one process domain transition to another?

I orginally created a tool called setrans but now we are shipping it as part of the sepolicy suite.

> man sepolicy-transition
sepolicy-transition(8)                                  sepolicy-transition(8)

NAME
       sepolicy-transition - Examine the SELinux Policy and generate a process transition report

SYNOPSIS
       sepolicy transition [-h] -s SOURCE

       sepolicy transition [-h] -s SOURCE -t TARGET

DESCRIPTION
       sepolicy transition will show all domains that a  give  SELinux  source domain can transition to, including the entrypoint.

       If  a  target  domain is given, sepolicy transition will examine policy for all transition paths from the source domain to the  target  domain,  and  will  list the paths.  If a transition is possible, this tool will print out all transition paths from the source  domain  to  the  target domain

OPTIONS
       -h, --help
              Display help message

       -s, --source
              Specify the source SELinux domain type.

       -t, --target
              Specify the target SELinux domain type.


If I want to see what process domains guest_t can transition too, I can execute the following:

# sepolicy transition -s guest_t
guest_t @ abrt_helper_exec_t --> abrt_helper_t
guest_t @ loadkeys_exec_t --> loadkeys_t
guest_t @ chkpwd_exec_t --> chkpwd_t
guest_t @ passwd_exec_t --> passwd_t
guest_t @ updpwd_exec_t --> updpwd_t
guest_t @ chfn_exec_t --> chfn_t
guest_t @ oddjob_mkhomedir_exec_t --> oddjob_mkhomedir_t
guest_t @ shell_exec_t --> httpd_user_script_t

If I wanted to see how httpd_t can read system_mail_t

# sepolicy transition -s httpd_t -t system_mail_t
httpd_t --> httpd_suexec_t --> httpd_mojomojo_script_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> postfix_showq_t --> spamc_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> dovecot_deliver_t --> uux_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> dovecot_deliver_t --> sendmail_t --> uux_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> dovecot_deliver_t --> sendmail_t --> procmail_t --> clamscan_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> dovecot_deliver_t --> sendmail_t --> postfix_master_t --> postfix_local_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> dovecot_deliver_t --> sendmail_t --> postfix_master_t --> postfix_pipe_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> uux_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_openshift_script_t --> openshift_initrc_t --> openshift_domain --> openshift_t --> openshift_mail_t --> exim_t --> clamscan_t --> system_mail_t
httpd_t --> httpd_suexec_t --> httpd_bugzilla_script_t --> system_mail_t
httpd_t --> abrt_retrace_worker_t --> mock_t --> mount_t --> lvm_t --> insmod_t --> initrc_t --> daemon --> system_mail_t
httpd_t --> abrt_retrace_worker_t --> mock_t --> mount_t --> lvm_t --> insmod_t --> initrc_t --> systemprocess --> system_mail_t
httpd_t --> abrt_retrace_worker_t --> mock_t --> mount_t --> lvm_t --> insmod_t --> initrc_t --> sulogin_t --> unconfined_t --> dhcpc_t --> NetworkManager_t --> pppd_t --> system_mail_t
httpd_t --> abrt_retrace_worker_t --> mock_t --> mount_t --> lvm_t --> insmod_t --> initrc_t --> sulogin_t --> unconfined_t --> rpm_t --> rpm_script_t --> system_mail_t
httpd_t --> abrt_retrace_worker_t --> mock_t --> mount_t --> lvm_t --> insmod_t --> initrc_t --> sulogin_t --> unconfined_t --> rpm_script_t --> system_mail_t
httpd_t --> passenger_t --> system_mail_t
httpd_t --> httpd_bugzilla_script_t --> system_mail_t
httpd_t --> httpd_mojomojo_script_t --> system_mail_t

Note currently this command does not take into account boolean settings, it is just showing you that it is possible.  Future enhancements would be to list the booleans required to allow the access.

1. sepolicy generate does not to be run as root.
2. sepolicy generate now generates a RPM spec file. This spec file can be used to build and RPM package that will install the policy package file (pp) and interface file (if) in the correct location, install it into the kernel and fix the labelling.
3. The sepolicy generated setup script continues to install the policy and setup the labelling, and also generates a man page based on the installed policy using sepolicy manpage, finally it build and compiles the policy and man page into an rpm ready to be installed on other machines.

• Best would be to write policy for the init service that is currently running without confinement.   I realize  that most users will not do this, but you could contact us for help.
• In RHEL5 you could turn on the rsync_disable_trans boolean.  Which will stop the transition from initrc_t to rsync_t, and rsync_t would just tun in  initrc_t domain, which by default is an unconfined domain.
• You could use audit2allow to add all of the rules to rsync_t to allow it to run as a client.
• You could change the label of /usr/bin/rsync to bin_t using semanage fcontext -m -t bin_t /usr/bin/rsync which would also stop the transition.
• You could make rsync_t an unconfined domain.