Dan Walsh's Blog

Got SELinux?

sandbox -X in Fedora 19 is resizeable, finally!
Thomas Liu worked as an intern for me a few years ago and wrote a patch for Xephyr to allow a Xepher window to be resizeable.

We shipped this patch in RHEL6 and waited for it to get upstream so we could pull it in Fedora.  Well as of today a Xephr
 xorg-x11-server-1.14.1-2.fc19 has been pushed into Fedora 19, and we have support for resizing sandbox in Fedora.

Now rumors have it Labelled NFS may finally reach upstream, that would truly be remarkable...

New Security Feature in Fedora 19 Part 3: Hard Link/Soft Link Protection
It is surprising to most people who understand Linux and Unix that you are allowed to Hard Link to any file on the OS as long as it is on the same file system.
Hard linking means that you can put the same Inode number into two different directories.  Prior to Fedora 19, a normal user would be allowed to do something like:

> ln /etc/shadow ~/shadow

Even though the /etc/shadow is owned by root.  Then if the user tricked an administrator into doing something like

# chown -R  dwalsh:dwalsh ~

This would cause the /etc/shadow file to be owned by dwalsh.

Similarly in the past hackers have tricked privileged applications to follow hard and soft links, created in a user account to compromise the system.

Kees Cook wrote some patches for the linux kernel that allows distributions to disable this behaviour.

Here is Kees Description of the benefits of the patch:

This patch adds symlink and hardlink restrictions to the Linux VFS.


A long-standing class of security issues is the symlink-based time-of-check-time-of-use race, most commonly seen in world-writable
directories like /tmp. The common method of exploitation of this flaw is to cross privilege boundaries when following a given symlink (i.e. a
root process follows a symlink belonging to another user). For a likely incomplete list of hundreds of examples across the years, please see:

The solution is to permit symlinks to only be followed when outside a sticky world-writable directory, or when the uid of the symlink and
follower match, or when the directory owner matches the symlink's owner.



On systems that have user-writable directories on the same partition as system files, a long-standing class of security issues is the
hardlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp. The common method of exploitation
of this flaw is to cross privilege boundaries when following a given hardlink (i.e. a root process follows a hardlink created by another
user). Additionally, an issue exists where users can "pin" a potentially vulnerable setuid/setgid file so that an administrator will not actually
upgrade a system fully.

The solution is to permit hardlinks to only be created when the user is already the existing file's owner, or if they already have read/write
access to the existing file.

Many Linux users are surprised when they learn they can link to files they have no access to, so this change appears to follow the doctrine
of "least surprise". Additionally, this change does not violate POSIX, which states "the implementation may require that the calling process
has permission to access the existing file"[1].

This change is known to break some implementations of the "at" daemon, though the version used by Fedora and Ubuntu has been fixed[2] for
a while. Otherwise, the change has been undisruptive while in use in Ubuntu for the last 1.5 years.


This feature is turned on by default in /usr/lib/sysctl.d/50-default.conf in F19.

grep fs /usr/lib/sysctl.d/50-default.conf 
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

There was some concern that this could cause problems in applications that expect this behaviour, so it can be disabled.
But overall, I think it is a positive feature for Fedora.

SELinux is a labeling system. First thought should be "Is there a label that would make this work?"
On the SELinux mail list today, someone asked:

I want to store the logs from openswan into a different file ( /var/log/ipsec ) than the default. For this purpose I added


to ipsec.conf.
    As long as I keep the server in permissive mode, openswan starts OK. If, however, I switch to enforcing, the daemon refuses to start with the following error message displayed in the console:

ipsec_setup: Starting Openswan IPsec U2.6.32/K3.0.78-1.el6.elrepo.x86_64...
ipsec_setup: Cannot write to "/var/log/ipsec".

   The audit log does not record anything useful so I tried to switch dontaudit to off and see if anything useful comes out. After running audit2allow and a bit of trial and error I came out with the following custom policy :

module myipsec 1.0;
require {
        type ipsec_t;
        type var_log_t;
        class file { write ioctl getattr append };
#============= ipsec_mgmt_t ==============
allow ipsec_mgmt_t var_log_t:file write;

   The above policy worked for me but I am wondering if it is OK

The problem is the administrator decided to add policy that allows ipsec_mgmt_t to write any file labeled var_log_t.  A hacked ipsec_mgmt could now overwrite any log file on the system labeled var_log_t, including /var/log/messages.  var_log_t is the default label for ANY file in /var/log directory that does not  have SELinux policy controlling it.  Also remember "write" access is always more dangerous then "append" access, since "write" allows you to truncate a file, destroying evidence, versus append to the end of a file.

In the paper I wrote a few years ago,

What is SELinux trying to tell me?
The 4 key causes of SELinux errors.

I explain that adding policy should be your third option, not your first.  In this case Dominic Grift pointed out the admin, that changing the label of the target would fix the problem and not involve adding custom policy.

semanage fcontext -a -t ipsec_log_t "/var/log/ipsec.*"
restorecon -v /var/log/ipsec

By telling SELinux that the content in the /var/log/ipsec log file was ipsec_log_t, you solve your problem and end up with the same security you had before the change.

Think Labels First...

SELinux & PaaS: Deep Dive on Multi-tenancy, Containers & Security with Dan Walsh, Red Hat

SELinux & PaaS: Deep Dive on Multi-tenancy, Containers & Security with Dan Walsh, Red Hat

Last week I went to Portland, OR for the OpenShift Origin Day.
I gave a talk about SELinux and OpenShift.

The talk covered  the importance of MAC and container/namespaces when using a multi-tenant environment like OpenShift.

The talk also covers enhancements I want to make to OpenShift gears (containers) and additional features that we will be adding.

The video has been posted to youtube.

What is the differences between user_home_dir_t and user_home_t
I just saw this email on the SELinux Fedora Mailing list and figured I would try to answer it here.

Lets look at the labels of content in my  home directory.

> ls -lZd / /home /home/dwalsh /home/dwalsh/.ssh /home/dwalsh/.emacs /home/dwalsh/public_html
dr-xr-xr-x. root   root   system_u:object_r:root_t:s0      /
drwxr-xr-x. root   root   system_u:object_r:home_root_t:s0 /home
drwx------. dwalsh dwalsh unconfined_u:object_r:user_home_dir_t:s0 /home/dwalsh
-rw-r--r--. dwalsh dwalsh unconfined_u:object_r:user_home_t:s0 /home/dwalsh/.emacs
drwxr-xr-x. dwalsh dwalsh unconfined_u:object_r:httpd_user_content_t:s0 /home/dwalsh/public_html
drwx------. dwalsh dwalsh unconfined_u:object_r:ssh_home_t:s0 /home/dwalsh/.ssh

As we go through the different files and directories that make up my home directory we see multiple SELinux labels.  Notice the files that are owned by me have an SELinux user of staff_u.  On most systems these would be labeled unconfined_u.  In SELinux every file that is created by a process running as unconfined_u will get the unconfined_u SELinux user placed on the file label.  Similarly staff_u will get staff_u, ...

This component is ignored on most SELinux systems, system_u on /home here is the default label set by restorecon or at install time.

object_r is just a place holder.  For all SELinux systems other then some experimental systems, every object on the file system gets labeled object_r.

The last field is all s0.  This is the MCS or MLS label depending on your policy.  On most systems this will be s0 (SystemLow)

SELinux is a type enforcement system, and the interesting parts is the types.  Lets look at each directory/file above and the types associated with them.

  • / is labeled with the root_t type.  This should be the only object on the system with the root_t type, if you have other objects on the computer with this label, then you were probably running in permissive mode and a confined process created it, you need to fix the labels.  The main purpose of root_t is for policy writers to define transitions. for system applications that are going to create content in /.  For example boot flags will get created with etc_runtime_t.  Random directories created in / will get labeled default_t.

#  touch /.autorelabel; ls -lZ /.autorelabel
-rw-r--r--. root root unconfined_u:object_r:etc_runtime_t:s0 /.autorelabel
# mkdir /foobar; ls -ldZ /foobar
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /foobar

         One thing to note about default_t is that NO confined apps are allowed to read content labeled default_t, because we have no idea what kind of content would be in this directory.  Invariably when some one creates a new directory in / without setting the labels, SELinux will have issues.  If foobar above contained apache content you would need to execute the following in order to allow apache to read the content.

# semanage fcontext -a -t httpd_sys_content_t '/foobar(/.*)?'
# restorecon -R -v /foobar

  • /home is labeled with the home_root_t type.  home_root_t is basically used for the toplevel or root directory for homedirs.   It's main purpose is to be used by policy for applications that need to create home directories or file system quota files.

# sesearch -T -t home_root_t
Found 10 semantic te rules:
   type_transition quota_t home_root_t : file quota_db_t;
   type_transition sysadm_t home_root_t : dir user_home_dir_t;
   type_transition firstboot_t home_root_t : dir user_home_dir_t;
   type_transition useradd_t home_root_t : dir user_home_dir_t;
   type_transition lsassd_t home_root_t : dir user_home_dir_t; 
   type_transition oddjob_mkhomedir_t home_root_t : dir user_home_dir_t;
   type_transition smbd_t home_root_t : dir user_home_dir_t;
   type_transition automount_t home_root_t : dir automount_tmp_t;

  • /home/dwalsh is labeled with the user_home_dir_t type.    Policy writers use this type to write transition rules to get content labeled correctly within the homedir.  Confined applications that create content in a users home directory need transition rules to create the content with the proper label. For example if you use ssh-copy-id on the remote machine, this triggers sshd to create the /home/dwalsh/.ssh directory, which we want labeled ssh_home_t, to protect the content.

# sesearch -T -s sshd_t -t user_home_dir_t | grep "\.ssh"
type_transition sshd_t user_home_dir_t : dir ssh_home_t ".ssh";

sesearch -T -s staff_t -t user_home_dir_t |wc -l

Note there are over 118 transition rules for a confined user creating content in his home directory.  With the advent of file name transition rules, we have exploded the number of these transitions in order to get proper labeling in the users home dir.

  • /home/dwalsh/.emacs is labeled user_home_t, which is the default label for all content in a users home directory.  This is the label that users are allowed to read/write and manage.  We try to prevent confined applications from being able to read and write this content, since this is where users store private content like credit card data, passwords shared secrets etc.  When we have a confined application that needs to access this content we usually wrap it in a boolean like ftp_home_dir.  Or we create a new type for this content, like mozilla_home_t or ssh_home_t.

  • /home/dwalsh/.ssh is labeled ssh_home_t, and contains content that only user types and sshd is allowed to read. Most other confined domains are not allowed to view content in this directory since it contains content like your secret keys.

  • /home/dwalsh/public_html is labeled httpd_user_content_t , which by default is the only place apache process is allowed to read in the home directory.  Allowing apache to read .ssh or say your .mozilla directory is just asking for trouble.

Note:  In order for apache or sshd to read their content they need to be allowed to search and getattr on every directory in the path.  The httpd would need to search root_t, home_root_t, user_home_dir_t, httpd_user_content_t.  It is not allowed to do this by default and needs the httpd_enable_homedirs boolean turned on.

# sesearch -A -b httpd_enable_homedirs -c dir -C | grep -v nfs | grep -v samba
Found 20 semantic av rules:
DT allow httpd_sys_script_t home_root_t : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_sys_script_t user_home_dir_t : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_user_script_t user_home_type : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_t user_home_type : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_user_script_t home_root_t : dir { ioctl read getattr lock search open } ; [ httpd_enable_homedirs ]
DT allow httpd_t home_root_t : dir { ioctl read getattr lock search open } ; [ httpd_enable_homedirs ]
DT allow httpd_user_script_t user_home_dir_t : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_t user_home_dir_t : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_suexec_t user_home_type : dir { getattr search open } ; [ httpd_enable_homedirs ]
DT allow httpd_suexec_t home_root_t : dir { ioctl read getattr lock search open } ; [ httpd_enable_homedirs ]
DT allow httpd_suexec_t user_home_dir_t : dir { getattr search open } ; [ httpd_enable_homedirs ]

Getting back to the question that drove me to create this blog.

What is the differences between user_home_dir_t  and user_home_t?

user_home_dir_t should only be the label of the users home directory but not of any content in the users home directory.
user_home_t is the label for generic content in a users homedir.

If you want to see all the labels that effect the users homedir, you can look at /etc/selinux/targeted/contexts/files/file_contexts.homedirs.

grep /home /etc/selinux/targeted/contexts/files/file_contexts.homedirs |wc -l

Understanding MCS Separation.
We designed a new way of using MCS, Multi Category Security, when we developed sVirt (Secure Virtualization) a few years ago.

To understand MCS it is helpful to understand something about MLS.

When Red Hat Enterprise Linux 5 came out, we had a done a lot of work adding MLS, Multi Level Security.  MLS requires the Belle & La Padula model of security.  This model takes into account the "Level and Category" of the data, and adds rules like a higher level process (TopSecret) is not allowed to write down (Secret) and a lower level (Secret) process is not allowed to read a higher level data (TopSecret).  The simple description of categories would be in order to read or write your process must have all the categories of the target.    Levels can go from s0 (SystemLow) to s15 (SystemHigh).  Then you can have any combination of 1024 categories.

In MCS we stole the idea of categories and dropped the concept of levels.

As I mentioned above the process category most include ALL of the categories of the target, otherwise MCS separation would block the access.   It is best to see an example of this.

Say I have a process labeled system_u:system_r:svirt_t:s0:c1,c2 from MCS Separation point of view.  This process would be allowed to access any file with any of these 4 MCS labels.

  • s0

  • s0:c1

  • s0:c2

  • s0:c1,c2

Since most files on a targeted system have the MCS label s0.  MCS Labeling does not block much mcs constrained applications.

By convention MCS confinement always uses two categories, and the categories can not be the same.  s0:c1,c1 == s0:c1.  Secondarily tools that launch MCS separate apps like libvirt and sandbox, make sure they never launch two processes with the same MCS label.  Which means we guarantee that two svirt_t always have two MCS labels that no other svirt_t or svirt_image_t would have.  Therefore a process running svirt_t:s0:c1,c2 would not be prevented by  MCS from access to any file with a MCS label of s0 or s0:c1,c2.  It would be denied from reading any file labeled s0:c1,c3 or s0:c2,c4 or s0:c4,c6.

But looking at MCS separation as the only control, misses out on type enforcement controls.

svirt_t access

We define our virtual machines as svirt_t type, and then we define rules about which types an svirt_t type is allowed access to.  If I wanted to see which types svirt_t is allowed to write, I could execute the following command.

# sesearch -A -s svirt_t -c file -p write -C | grep open | grep -v ^D
   allow virt_domain svirt_tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow svirt_t xen_image_t : file { ioctl read write getattr lock append open } ;
   allow virt_domain svirt_image_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow virt_domain svirt_tmpfs_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow virt_domain virt_cache_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow virt_domain qemu_var_run_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow virt_domain anon_inodefs_t : file { ioctl read write getattr lock append open } ;
   allow virt_domain svirt_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow svirt_t svirt_t : file { ioctl read write getattr lock append open } ;
ET allow virt_domain dosfs_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ virt_use_usb ]
ET allow virt_domain usbfs_t : file { ioctl read write getattr lock append open } ; [ virt_use_usb ]

This means a confined virtual machine running as svirt_t:s0:c1,c2 would ONLY allowed to write to the following file types IFF they are MCS labeled s0 or s0:c1,c2

svirt_tmp_t, svirt_image_t, svirt_tmpfs_t, virt_cache_t, qemu_var_run_t, svirt_home_t,

dosfs_t and usbfs_t iff the virt_use_usb boolean is turned on, perhaps we should turn this off by default.

anon_inodefs_t and svirt_t are not file types, svirt_t is a process types which would be in /proc.

libvirt and the kernel need to ensure that non of these files get labeled with s0.

Openshift domains are allowed to write/open

Kernel file systems anon_inodefs_t, openshift_t,hugetlbfs_t,  security_t

openshift_tmp_t, openshift_rw_file_t, openshift_tmpfs_t

MCS Constrained Types

Thee following types are MCS Constrained.

seinfo  -amcs_constrained_type -x

Audit2allow should be your third option not the first.
Whenever I talk about SELinux lately, I make everyone stand up and say.

SELinux is a labeling system.
Every process has a label every object on the system has a label.  Files, Directories, network ports ...
The SELinux policy controls how process labels interact with other labels on the system.
The kernel enforces the policy rules.

The follow up to this is, if you get a denial the First thing you should think is, perhaps one of the labels is WRONG.

I wrote a paper  a while ago called the SELinux Four Things. In which I point out the four causes of SELinux denials.

  1. You have a labeling problem.

  2. You have changed a process configuration, and you forgot to tell SELinux about it.

  3. You have a bug in either an application or SELinux policy.  Either SELinux policy did not know an application could do something, or the application is broken.

  4. You have been hacked.

The solution to #3 is to report a bug and use audit2allow to generate a local policy module and install it until either the application is fixed or SELinux policy adds rules to allow it.

The problem i see is that administrators seem to go to this option when ever they see a denial.   Lets look at a recent example from email.

In a recent email on selinux@lists.fedoraproject.org, Richard reported:

I have a CGI application named "mapserv" that needs to write to a specific location: "/rwg/mapserver/tmp"

He figured out that Apache content was usually labeled httpd_sys_content_t, which was a step in the right direction, so I guess he labeled this rectory tree as

Then he asked about writing policy that looked like.

module test 1.0;

require {
        type httpd_sys_content_t;
        type httpd_sys_script_t;
        class dir add_name;
        class file { write create };

#============= httpd_sys_script_t ==============
allow httpd_sys_script_t httpd_sys_content_t:dir add_name;
allow httpd_sys_script_t httpd_sys_content_t:file { write create };

This policy obviously came from audit2allow, and would work, except for a couple of problems, the biggest being that all CGI Scripts would be able to read write all Apache content.  The policy is also fragile since you might get an AVC like httpd_sys_script_t is not allowed to append to httpd_sys_content_t.

manage_files_pattern(httpd_sys_script_t, httpd_sys_content_t, httpd_sys_content_t) Would have been better.

Is there a better label I could have used?

But the main point of this blog would be that Richard should not have used a audit2allow module.  He could have used httpd_sys_rw_content_t for the tmp directory.

# semanage fcontext -a -t httpd_sys_rw_content_t "/rwg/mapserver/tmp(/.*?)"
# restorecon -R -v /rwg/mapserver/tmp

This would have been choice "1" above, one of the labels is wrong.

Could I change the process label?

Dominic Grift pointed out, in a mail reply, another solution.

cat > mywebapp.te << EOF
policy_module(mywebappp, 1.0.0)

make -f /usr/share/selinux/devel/Makefile mywebapp.pp
sudo semodule -i mywebapp

Now you can use the following new types:

httpd_mywebapp_script_t (mywebapp process type)
httpd_mywebapp_script_exec_t (mywebapp cgi executable file type)
httpd_mywebapp_content_t (mywebapp readonly file type)
httpd_mywebapp_content_rw_t (mywebapp read/write file type)
httpd_mywebapp_content_ra_t (mywebapp read/append file type)
httpd_mywebapp_htaccess_t (mywebapp htaccess file types)

Basically you can just label the cgi script with the mywebapp script executable file type and then the mywebapp process will run with the mywebapp process type creating files with the mywebapp content file types.

This solution satisfies "1", changing both the process label and the target label.  This is probably the best solution, since if Richard used other CGI scripts on his machine, only the mapserver cgi script would be able to write the mapserver cgi content, and he would have better separation.

Note:  I would have used sepolicy generate --cgi PATHTO/mapserver.cgi to generate the policy.

Could I modify the SELinux configuration to allow this access?

A third option would be to turn on the httpd_unified boolean.  (This would an option of type "2").  Although not the best solution for the problem.

httpd_unified is described as "Unify HTTPD handling of all content files."

# setsebool -P httpd_unified 1

This means it will allow the apache process and default apache scripts to read/write/execute all default labeled apache content.

Bottom line, when you see an SELinux AVC, the way your decision tree should go something like the following.

  1. Is the process that is being denied running with the correct label?  Could I make it run with a better label?

  2. Does the target object have the correct label or could I assign it a label that would allow the access from the process label?

  3. Is their an SELinux Boolean that would allow the access?

  4. If this is a network port being denied, did I modify the default settings and could I modify the labels on network packets using semanage port.

  5. Do I believe this is a bug in an application?  If yes, I need to report a bug?

  6. Is this a bug in SELinux policy and the access should be allowed by default?  I should install a local modification and report this as a bug.

  7. Am I being hacked?

setroubleshoot attempts to help you walk through this process, and newer versions of audit2allow show you booleans and potential labels you can use.

New Security Feature in Fedora 19 Part 2: Shared System Certificates
One of the cool things about writing this series of blogs for each Fedora Release is finding out about the changes is different parts of the OS outside of SELinux.  I love getting suggestions of security topics to blog on.  If you know of security topics I should cover send them to me at dwalsh@redhat.com or tweet @rhatdan

Shared System Certificates

Currently Tools like NSS (Mozilla products like Firefox/Thunderbird), GnuTLS, OpenSSL and Java on a Fedora box ship their own public key certificates and their own trust relationships. This means if an administrator wants to add/modify/delete trust to certain Certificates, he might have to modify several different stores in order to get the correct security.

A new feature in Fedora 19 is a system wide trust store of static data to be used by crypto toolkits as input for certificate trust decisions.

This feature the tools listed above a default source for retrieving system certificate anchors and black list information.  Fedora 19 will be the first step toward development of a comprehensive solution.

Look at the feature for more information on the changes, but the following two sections explain the key benefits to this feature and how users will use it.

Benefit to Fedora

The goal is to empower administrators to configure additional trusted CAs, or to override the trust settings of CAs, on a system wide level, as required by local system environments or corporate deployments. Although this is theoretically possible today, it's extremely hard to get right.

Fedora will immediately gain a unified approach to system anchor certificates and black lists. This is then built on in the future to be a comprehensive solution.

User Experience

Administrators will be able to use a tool to add a certificate authority file to the system trust store and have it recognized by all relevant applications.

Users will stop being surprised by incoherent and unpredictable trust decisions when using different applications with websites/services which require custom trust policy.

New Security Feature in Fedora 19 Part 1: New Confined/Permissive Process Domains
Each Fedora we release a bunch of new domains that will run in permissive mode for the release.  When the next release is released, the permissive domains are made enforcing.

In my blog,10 things you probably did not know about SELinux.. #4, I describe how you can interact with permissive domains.

In Fedora 18, we added 8 new permissive domains, all of  which are now enforcing in Fedora 19.

Fedora 18 Permissive Domains/ Now Confined in Fedora 19
  pkcsslotd_t (daemon manages PKCS#11 objects between PKCS#11-enabled applications)
   slpd_t  (Server Location Protocol Daemon)
   sensord_t (Sensor information logging daemon)
   mandb_t  (Cron job used to create /var/cache/man content)
   glusterd_t (policy for glusterd service)
   stapserver_t (Instrumentation System Server) Note: This was back ported to Fedora 17.
   realmd_t (dbus system service which manages discovery and enrollment in realms and domains like Active Directory or IPA)
   phpfpm_t (FastCGI Process Manager)

Fedora 19 Permissive Domains

       systemd-localed is a system service that may be used as mechanism to
       change the system locale settings, as well as the console key mapping
       and default X11 key mapping.  systemd-localed is automatically
       activated on request and terminates itself when it is unused.

       systemd-hostnamed is a system service that may be used as mechanism to
       change the system hostname.  systemd-hostnamed is automatically
       activated on request and terminates itself when it is unused.

       systemd-sysctl.service is an early-boot service that configures
       sysctl(8) kernel parameters.

       mythtv cgi scripts used for managing mythtv scheduling and content.

        OpenShift System Cron jobs run as openshift_cron_t, not gear cron jobs.

        OpenStack Object Storage (swift) aggregates commodity servers to work together
         in clusters for reliable, redundant, and large-scale storage of static objects.

Fedora 19 Modules Removed
shutdown.pp (Command no longer supported, functions suplanted by systemd)
consoletype.pp(Command should no longer be used, suplanted by systemd-logind)

Fedora 19 Modules Renamed or Consolodated
amavis.pp clamav.pp - These have been consolodated into a unified view of antivirus.pp, All aliased o antivirus_t.
    typealias antivirus_t alias { amavis_t clamd_t clamscan_t freshclam_t } ;

ctdbd.pp changed name upstream to ctdb.pp
isnsd.pp changed name upstream to isnd.pp
pacemaker.pp and corosync.pp rgmanager.pp aisexec.pp - These have been consolodated into a unified view of rhcs.pp, all aliased to the new type cluster_t.
     typealias cluster_t alias { aisexec_t corosync_t pacemaker_t rgmanager_t }

Security Vs Usability
One of the interesting things about working in the security field, is walking the balance between security and usability.  

On one of the many mailing lists I read, an admin as complaining about his Apache server being hacked.  Some application had been hacked in a way that it got apache to write to a particular directory and then executed the code it has written.

I decided to look at how SELinux Policy controlled httpd_t.  I wanted to know what file types was httpd_t allowed to write and execute.

In Fedora 19, I executed the following command.

> sesearch -A -C -s httpd_t -p execute -c file | grep write
DT allow httpd_t httpdcontent : file { ioctl read write create getattr setattr lock append unlink link rename execute open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]

This indicates that the apache deamon (httpd_t) is allowed to write and execute files that have a label that has the attribute httpdcontent.  But they would have to have the httpd_enable_cgi, httpd_unified, and httpd_builtin_scripting booleans turned on.

#semanage boolean -l | grep httpd_enable_cgi
httpd_enable_cgi               (on   ,   on)  Allow httpd cgi support
# semanage boolean -l | grep httpd_unified
httpd_unified                  (off  ,  off)  Unify HTTPD handling of all content files.
# semanage boolean -l | grep httpd_builtin_scripting
httpd_builtin_scripting        (on   ,   on)  Allow httpd to use built in scripting (usually php)

Out of the box we enable httpd_enable_cgi, so cgi scripts will run with your apache server.  We also enable httpd_builtin_scripting, which allows you to run php scripts within the same processes as apache, this also enabled other builtin scripting tools like mod_python and mod_perl.

We disable httpd_unified, which basically says httpd_t has full access to all httpdcontent files.

# seinfo -ahttpdcontent -x

So rather then treating each type differently we combine all access.  We used to have this turned on by default for people who did not understand SELinux, probably still is in RHEL5 and maybe RHEL6.  But in latest Fedora and RHEL7 we will turn it off by default.

If you are running a web site that does not do any scripting, it would probably be advisable to turn off the other two booleans.

You are viewing danwalsh