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.
- Is the subject in a role which includes the target to transition into?
- Is the subject allowed to actually execute the
passwd_exec_t file with an intent to transition?
- Is it permitted that anyone can transition into
passwd_t by executing a file object labeled passwd_exec_t?
- 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.
sesearch. Trysesearch -T -t httpd_sys_content_tand see if that gives you more-or-less what you are looking for.-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 gethttpd_sys_content_tout then that's the answer.