A page from Fedora docs describes a SELinux context problem with the example:

"...instead of using /var/www/html/ for a website, an administrator wants to use /srv/myweb/. ... [However] SELinux prevents the Apache HTTP Server (httpd) from accessing [the mislabeled files and directories]"

As as anyone who has trouble with SELinux knows, SELinux is not helpful with error messages. One way to discover the correct context is using matchpathcon (from further down the page)

The matchpathcon command checks the context of a file path and compares it to the default label for that path. The following example demonstrates using matchpathcon on a directory that contains incorrectly labeled files:

$ /usr/sbin/matchpathcon -V /var/www/html/*

/**EDIT: As requested, using the example context of httpd, matchpathcon reports the user, role and type of the public www directory contents as:

[root@mrwizard ~]# /usr/sbin/matchpathcon /var/www/html/*
/var/www/html/info.php  system_u:object_r:httpd_sys_content_t:s0

If --and this is just an illustration and not correct use of this command-- you perform the same command on the binary for httpd, you'll find the type is not the httpd content type, but the httpd execution type, I guess, SysV (on CentOS6) uses to start httpd:

[root@mrwizard ~]# /usr/sbin/matchpathcon /usr/sbin/httpd /usr/sbin/httpd system_u:object_r:httpd_exec_t:s0

The matchpathcon output is asymmetric; it doesn't help the admin troubleshoot SELinux user, role and type with the service as input to get the SELinux default context as output. **/

If matchpathcon checks the SELinux context of a properly configured directory, what is the converse procedure to use on the service? In other words is there a reverse check for /usr/sbin/httpd?

I'm asking this out of surplus of caution. It seems this step useful when the server was working and now is broken. However, if you're installing the system and made some decision to put something in the wrong place early in an install, then the correct SELinux context directory may not exist. Right? So what would you check to discover the correct SELinux context except for the service?

  • I don't think I understand what you are asking. Can you illustrate with an example what you would like to see? Oct 16, 2013 at 19:38
  • @MIfe, see the edit above for more information...
    – xtian
    Oct 16, 2013 at 22:04
  • It's still not clear exactly what you're looking for. What is it you want to know? Oct 16, 2013 at 22:05
  • I think you want sesearch. Try sesearch -T -t httpd_sys_content_t and see if that gives you more-or-less what you are looking for. Oct 16, 2013 at 22:14
  • I didn't know this command and its not in my base install. I see its in the CentOS package setroubleshoot-server. I've just installed it, and there seems to be more to do, because that command is not found yet... So I'll just respond to the input. I see on the man page you can add expressions, -s NAME, Find rules with type/attribute NAME as their source. -t NAME, --target=NAME Find rules with type/attribute NAME as their target. If you can put httpd in to get httpd_sys_content_t out then that's the answer.
    – xtian
    Oct 16, 2013 at 22:59

1 Answer 1


I'll be using the passwd program to explain a lot of this.

To definitely answer this question in the context of DAC (standard unix access control model):

How do you work out from the file what subject I might end up running a binary in?

The answer is you run ls -l /bin/passwd, check if the setuid bit is set. If it is you'll run the program as the files owner, if not you'll run the program as you're own user.

To definitely answer this question in the context of SELinux:

How do you work out from the file what subject I might end up running a binary in?

Well, its not quite that simple, because it depends who you are when you try to run the binary! Fortunately, the sesearch utility is incredibly handy for inspecting what the policy might be in this case. We can ask it to tell us what all the transitions are that might occur when running the object labeled httpd_exec_t.

Which yields

$ sesearch -T -c process -t httpd_exec_t
Found 14 semantic te rules:
    type_transition system_cronjob_t httpd_exec_t : process httpd_t; 
    type_transition crond_t httpd_exec_t : process httpd_t; 
    type_transition certwatch_t httpd_exec_t : process httpd_t; 
    type_transition initrc_t httpd_exec_t : process httpd_t; 
    type_transition dirsrvadmin_t httpd_exec_t : process httpd_t; 
    type_transition kdumpctl_t httpd_exec_t : process httpd_t; 
    type_transition cluster_t httpd_exec_t : process httpd_t; 
    type_transition logrotate_t httpd_exec_t : process httpd_t; 
    type_transition condor_startd_t httpd_exec_t : process httpd_t; 
    type_transition cobblerd_t httpd_exec_t : process httpd_t; 
    type_transition openshift_initrc_t httpd_exec_t : process httpd_t; 
    type_transition piranha_pulse_t httpd_exec_t : process httpd_t; 
    type_transition init_t httpd_exec_t : process httpd_t; 
    type_transition svc_run_t httpd_exec_t : process httpd_t;

So it turns out, in you're case, there is actually a whole bunch of different subjects that can do this, they all end up in the httpd_t domain.

Thats now always the case though:-

$ sesearch -T -c process -t ssh_exec_t
Found 8 semantic te rules:
   type_transition virsh_t ssh_exec_t : process virsh_ssh_t; 
   type_transition sge_job_t ssh_exec_t : process sge_job_ssh_t; 
   type_transition ajaxterm_t ssh_exec_t : process ajaxterm_ssh_t; 
   type_transition nx_server_t ssh_exec_t : process nx_server_ssh_t; 
   type_transition sysadm_t ssh_exec_t : process ssh_t; 
   type_transition staff_t ssh_exec_t : process ssh_t; 
   type_transition condor_startd_t ssh_exec_t : process condor_startd_ssh_t; 
   type_transition user_t ssh_exec_t : process ssh_t; 

This executable does different transitions for different subjects. Because we know that virsh_t should only be doing a very specific set of things in SSH, it moves into virsh_ssh_t for a transition, which has more restrictions imposed upon it than someone who would transition into ssh_t.

I have added quite a long answer on the subject of transitions below so that people can appreciate what problems SELinux is trying to solve and how it tries to solve them.

Moving Between Users in DAC (Unix) and MAC/TE (SELinux)

Lets define some terms for this to make sense.

  • Subject: An actor which manipulates items in the system. This is typically a user or process.
  • Object: An item which is being acted upon. Can be many things (file, directory, port)
  • Transition: The act of transforming from one subject into another.

Before we answer how this is done in SELinux type enforcement, consider how you would do this in DAC (discretionary access control; the standard UNIX security model).

How this works in the Unix Security Model

In DAC, the subject is primarily the UID, but the GID and supplementary GIDs also define a subject. Objects are files, directories, unix sockets and are mostly referred to by their paths (although some exceptions exist, like IPC shared memory).

Normally, when you run a program - there is no transition. User jim wants to run /bin/cat. When he does so, the process is instantiated and inherits the subject of jim along with any other properties of his subject (GID, supplementary groups etc).

However, there are some programs that when ran do transition. When user jim runs the passwd command, jim transitions into root, which is of course necessary to make changes to the shadow file.

This automatic transitioning behaviour is controlled by flipping the SUID bit in the filesystem permissions, its defined who you transition into by setting the owner of the executable file on disk to the target subject you want to transition into.

So for clarity in the passwd example jim becomes root because the permission mode is 4755 and the owner is root.

So, setuid performs transitioning in the standard unix access control model.

Unfortunately setuid programs have a horrendous history of security problems. This is due to the limitations in the DAC security model when it comes to how transitions are evaluated.

The setuid transition process performs no check on the subject (user) invoking the program. Both jim and betty will transition to root along with apache, mysql and nobody if they invoke passwd.

It is not possible (without having the program itself check and we all know how reliable that has been) to make it so that when jim calls passwd he transitions to root but if betty calls passwd for it not to transition to root. The only thing you could do is outright deny betty from ever calling passwd in the first place using POSIX ACLs but that is not granular.

It is also not possible (without the application doing it and having privileges to do it) to have the owner of the file be someone else other than the person you want to transition into. So betty cannot run passwd and become the user bin instead of root.

How this works in the SELinux Security Model

The subject in selinux is referred by the label type that the user or process is running in. This might be user_t, unconfined_t or httpd_t for example.

Objects are files, directories, sockets etc just like in DAC and are referred to also by their type and also have labels. httpd_exec_t, user_home_t and mysql_port_t are examples of different object labels SELinux uses.

Under normal circumstances, just like in DAC, no transition occurs. If user_t executes /bin/cat (or the way SELinux sees it, if user_t executes a bin_t object), it is instantiated and inherits the subject of user_t from the caller.

However, some programs will transition when called. If user_t executes the object labeled passwd_exec_t (which is /bin/passwd unsurprisingly) he transitions to passwd_t.

This is defined in a type transition rule that in policy looks like this:

type_transition user_t passwd_exec_t:process passwd_t;

In SELinux, for a transition to occur the following evaluation occurs.

  • Who is the subject wanting to transition (user_t)?
  • Which object is being referred to (passwd_exec_t)?
  • What new subject does the old subject want to become (passwd_t)?

Because we consider who is performing the request before allowing it, we can perform more intelligent decisions of who gets to do what.

  • httpd_t can never become passwd_t and subsequently never can get access to the shadow file.
  • We can give betty a guest_t subject in SELinux and she can also never become passwd_t.

As a matter of fact, that is not all which is evaluated. Even more questions are asked before we allow a transition.

  1. Is the subject in a role which includes the target to transition into?
  2. Is the subject allowed to actually execute the passwd_exec_t file with an intent to transition?
  3. Is it permitted that anyone can transition into passwd_t by executing a file object labeled passwd_exec_t?
  4. Should we even do this automatically for user_t or should user_t have to ask explicitly to transition?

The SELinux transition model is way stronger, makes better evaluations and far more granular than the DAC model.

Much of the power of SELinux is in the strong transitioning model you have. Because you can be very specific about the conditions of who gets to be who -- then you can make whatever you are transitioning into have very specific permissions depending upon what the function of the subject might be.

So, to answer your original question -- the answer is it depends what you want to do and who you want to do it.

  • 1
    – MDMarra
    Oct 17, 2013 at 0:19
  • 1
    If this kind of explanation was included with the standard texts on SELInux it would be so much easier to get to grips with.
    – user9517
    Oct 17, 2013 at 21:14
  • +100 if I could. I want to respond, but there's so much here I'll have to read it again, so I can recognize if my questions are about my config issues or my fascination with your very detailed explanation.
    – xtian
    Oct 17, 2013 at 22:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .