Proposed additions to the SELinux FAQ.
If you have a question and/or answer you would like to appear in the FAQ. Please put it here. We will try to answer it and will migrate the question and answer to the formal SELinux FAQ
In Red Hat Enterprise Linux 4, how do I write policy to allow a domain to use pam_unix.so?
Very few domains in the SELinux world are allowed to read the /etc/shadow file. There are constraint rules that prevent policy writers from writing code like.
allow mydomain_t shadow_t:file read;
In RHEL4 you can setup your domain to use the unix_chkpwd command. The easiest way is to use the unix_chkpwd attribute. So if you were writing policy for an ftpd daemon you would write something like daemon_domain(vsftpd, auth_chkpwd'). This would create a context where vsftpd_t -> chkpwd_exec_t -> system_chkpwd_t which can read /etc/shadow, while vsftpd_t is not able to read it.
In FC5/RHEL5 you will add the rule
auth_domtrans_chk_passwd(vsftpd_t)
What is SELinux policy?
The SELinux policy describes the access permissions for all subjects and objects, i.e., the entire system of users, programs, and processes and the files and devices they act upon. Fedora Core policy is delivered in a package, with an associated source package. Current shipping policy packages are:
- selinux-policy-<version>.noarch.rpm
This package is common to all types of policy and contains config files/man pages. This includes the interface files for the development environment. This replaces the -sources package from the past. This package contains the interface files used in reference policy along with a Makefile and a small tool used to generate a policy template file. The interface files reside in /usr/share/selinux/devel/headers directory. If you want to see all of the policy files used to build the reference policy you need to install the src.rpm.
- selinux-policy-mls-<version>.noarch.rpm
- selinux-policy-strict-<version>.noarch.rpm
- selinux-policy-targeted-<version>.noarch.rpm
Binary policy files are in /etc/selinux/POLICYNAME. The policy for the types and domains is configured separately from security context for the subjects and objects.
What is the SELinux targeted policy? What daemons are protected by the targeted policy?
I have a process running as unconfined_t, and SELinux is still preventing my application from running
We have begun to confine the unconfined daemon, somewhat.
SELinux restricts certain memory protection operation.
- execmod
This is usually based on a library, you can change the context on the library with the chcon -t textrel_shlib_t LIBRARY. Now your application can run. Please report this as a bugzilla.
- execstack
Attempt to execstack -c LIBRARY; Now try your application again. If the application now works, the library was mistakenly marked as requiring execstack. Please report this as a bugzilla.
- execmem
- execheap
A boolean for each one of these memory check errors have been provided. So if you need to run this application with, you can set the boolean allow_exec* to fix the problem. For instance if you try to run an application and you get an AVC message containing execstack failure. You can set the boolean
setsebool -P allow_execstack=1
What do the following warnings reported by rpm mean?
genhomedircon: Warning! No support yet for expanding ROLE macros in the /etc/selinux/mls/contexts/files/homedir_template file when using libsemanage.
genhomedircon: You must manually update file_contexts.homedirs for any non-user_r users (including root).
Some of the interfaces are not complete yet for selinux. Most users should not care about this warning. It will only affect you if you are running the policy package that is reporting the problem and have non standard role/user combinations. IE You are using some custom policy.
restorecon reset /etc/modprobe.conf context
system_u:object_r:etc_runtime_t->system_u:object_r:modules_conf_t
restorecon reset /etc/cups/ppd/homehp.ppd context user_u:object_r:cupsd_etc_t->system_u:object_r:cupsd_rw_etc_t
During the update process, the selinux package runs restorecon on the difference between the previously install policy file_context and the newly install policy context. This maintains the correct file context on disk.
libsepol.sepol_genbools_array: boolean hidd_disable_trans no longer in policy
This indicates that the updated policy has removed the boolean from policy.
After relabeling my /home using setfiles or fixfiles, will I still be able to read /home with a non-SELinux-enabled system?
A:
You can read the files from a non-SELinux distribution, or one with SELinux disabled. However, files created by the non-SELinux using systems will not have a security context, nor will any files you remove and recreate. This could be a challenge with files such as ~/.bashrc. You may have to relabel your /home when you return to Fedora Core.
All of the other SELinux documentation states that the su command will only change Linux identity not security role.
su/sudo only change the Linux identy. You will need to use newrole to change the selinux identity or level.
I get a specific permission denial only when SELinux is in enforcing mode, but I don't see any audit messages in /var/log/messages. How can I identify the cause of these silent denials?
The most common reason for a silent denial is when the policy contains an explicit dontaudit rule to suppress audit messages. The dontaudit rule is often used this way when a benign denial is filling the audit logs.
To look for your particular denial, you will need to enable auditing of all dontaudit rules:
In FC5/RHEL 5 we ship two binary policies, and potentially some loadable modules. These policy files are stored on /usr/share/selinux/POLICYTYPE.
base.pp is the standard base policy. enabledaudit.pp is the same base policy, with the dontaudit rules removed. You need to load the dontaudit.pp file in order to turn on all the AVC messages.
semodule -b /usr/share/selinux/targeted/enableaudit.pp
Once you have found your problem you can reset to the default mode by executing.
semodule -b /usr/share/selinux/targeted/base.pp
How can I help write policy?
Your help is definitely appreciated.
- You can start by joining the SELinux mailing list, fedora-selinux-list@redhat.com; you can subscribe and read the archives at http://www.redhat.com/mailman/listinfo/fedora-selinux-list.
- The UnOfficial FAQ has some generic policy writing HOWTO information (http://sourceforge.net/docman/display_doc.php?docid=14882&group_id=21266#BSP.1).
- Another new resource is the Writing SE Linux policy HOWTO (https://sourceforge.net/docman/display_doc.php?docid=21959&group_id=21266).
Your best bet is to look at the policy files in /usr/share/doc/selinux-policy-<version> which show examples of policy.
If you want to create a new policy domain, you can look at the interface files in the /usr/share/selinux/devel sub-directories.
There is also a tool there to help you get started. You can use the tool policygentool to generate your own te, fc and if file. This tool takes two parameters the Name of the policy module (mydaemon) and the full path to the executable (/usr/sbin/mydaemon).
It will prompt you for a few common domain characteristics and will create a three files mydaemon.te, mydaemon.fc and mydaemon.if. After you generate the policy files, use the supplied Makefile, /usr/share/selinux/devel/Makefile, build a policy package (mydaemon.pp). Now you can load the policy module, using semodule, and relabel the executable using restorecon. Since you have very limited policy for your executeable, SELinux will prevent it from doing much. So you need to turn on permissive mode and then use the init script to start your daemon. Now you can start collect avc messages. You can use audit2allow to translate the avc messages to allow rules and begin updating you mydaemon.te file. You should search for interface macros in the /etc/selinux/devel/include directory and use these instead of using the allow rules directly, whenever possible. audit2allow -R will attempt to find interfaces that match the allow rule. If you want more examples of polcy, you could always install the selinux-policy src rpm, which contains all of the policy te files for the reference policy.
m4 /usr/share/selinux/devel/include/all_perms.spt /usr/share/selinux/devel/include/loadable_module.spt /usr/share/selinux/devel/include/misc_macros.spt
...
/usr/share/selinux/devel/include/obj_perm_sets.spt mydaemon.fc > tmp/mydaemon.mod.fc
Creating targeted mydaemon.pp policy package
/usr/bin/semodule_package -o mydaemon.pp -m tmp/mydaemon.mod -f tmp/mydaemon.mod.fc
rm tmp/mydaemon.mod.fc tmp/mydaemon.mod
restorecon reset /usr/sbin/mydaemon context user_u:object_r:sbin_t->system_u:object_r:mydaemon_exec_t
In the past I have written local.te file in policy sources for my own local customization to policy, how do I do this with reference policy?
If you have specific AVC messages you can use audit2allow to generate a Type Enforcement file that is ready to load as a policy module.
audit2allow -M local < /tmp/avcs
This will create a local.pp file which you can then load into the kernel using
semodule -i local.pp
You can edit the local.te file to make additional customizations.
audit2allow -M local -l -i /var/log/audit/audit.log
Generating type enforcment file: local.te
Compiling policy
checkmodule -M -m -o local.mod local.te
semodule_package -o local.pp -m local.mod
******************** IMPORTANT ***********************
In order to load this newly created policy package into the kernel,
you are required to execute
semodule -i local.pp
This will generate a local.te file, that looks something like the following:
module local 1.0;
require {
class file { append execute execute_no_trans getattr ioctl read write };
type httpd_t;
type httpd_w3c_script_exec_t;
};
allow httpd_t httpd_w3c_script_exec_t:file { execute execute_no_trans getattr ioctl read };
You can hand edit this file and then recompile and reload it using
- checkmodule to compile the te file.
- semodule_package to create a policy package
- semodule to add it to the current machines running policy
- IMPORTANT ***********************
In order to load this newly created policy package into the kernel,
you are required to execute
semodule -i local.pp
I created a new Policy Package where do I put it to make sure that it gets loaded into the kernel
All you need to do is the semodule -i myapp.pp command.
semodule -i myapp.pp
This modifies the policy that is stored on the machine. Everytime for now on your policy module will get loaded with the rest of the policy. You can even remove the pp file from the system.
semodule -l will list the currently loaded modules
myapp 1.2.1
If you later would like to remove the policy package, you can execute
semodule -r myapp
I want to run a daemon on a non standard port but SELinux will not allow me. How do get this to work?
You can use the semanage command to define addtional ports. So say you want httpd to be able to listen on port 8082, you could enter the command.
semanage port -a -p tcp -t http_port_t 8082
Dan Berrange has a nice talk on this:
http://berrange.com/personal/diary/2006/03/good-times-for-developers
How do I add additional translations files to my MCS/MLS System?
Translations are stored in the /etc/selinux/POLICYTYPE/setrans.conf file. You can edit this file or use semanage to manipulate the setrans.conf file used by SELinux.
Use semanage translations -l to list all current translations. Now pick an unused category. Say you wanted to add Payroll as a translation.
semanage translations -a -T Payroll s0:c6
I have setup my MCS/MLS Translations, now I want to designate which users can read payroll data?
You can modify the range of categories a user can login with by using semanage.
semanage login -a -r s0-Payroll Username
I am writing an php script that needs to create temporary files in /tmp and then execute them, SELinux policy is preventing this. What should I do?
You should avoid having system applications writing to the /tmp directory, since users tend to use the /tmp directory also. It would be better to create a directory elsewhere which could be owned by the apache process and allow your script to write to it. You should label the directory httpd_sys_script_rw_t.
I am setting up swapping to a file, but I am seeing AVC messages in my log files?
You need to identify the swapfile to SELinux by setting its file context to swapfile_t.
chcon -t swapfile_t SWAPFILE
Please explain the relabelto/relabelfrom permissions?
For files, relabelfrom means "Can domain D
relabel a file from (i.e. currently in) type T1?" and relabelto means
"Can domain D relabel a file to type T2?", so both checks are applied
upon a file relabeling, where T1 is the original type of the type and T2
is the new type specified by the program.
Useful documents to look at:
- Object class and permission summary by Tresys http://tresys.com/selinux/obj_perms_help.shtml
- Implementing SELinux as a LSM tech report (describes permission checks on a per-hook basis) http://www.nsa.gov/selinux/papers/module-abs.cfm Also available in the selinux-doc package (and more up-to-date there).
- Integrating Flexible Support... tech report (describes original design and implementation, including summary tables of classes, permissions, and what permission checks are applied to what system calls - not entirely up-to-date with current implementation, but a good resource nonetheless) http://www.nsa.gov/selinux/papers/slinux-abs.cfm