selinux-faq/en selinux-faq-en.xml,NONE,1.1
Paul W. Frields (pfrields)
fedora-docs-commits at redhat.com
Sat Feb 4 14:45:44 UTC 2006
Author: pfrields
Update of /cvs/docs/selinux-faq/en
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv3796/en
Added Files:
selinux-faq-en.xml
Log Message:
Reorganized with 'migrate-lang' script
--- NEW FILE selinux-faq-en.xml ---
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!-- *************** Bring in Fedora entities *************** -->
<!ENTITY % FEDORA-ENTITIES-EN SYSTEM "../docs-common/common/fedora-entities-en.ent">
%FEDORA-ENTITIES-EN;
<!ENTITY DOCBASE "selinux-faq">
<!ENTITY DOCVERSION "1.5">
<!ENTITY DOCDATE "2005-12-30-T12:21-0500">
<!ENTITY DOCID "&DOCBASE;-&DOCVERSION; (&DOCDATE;)"> <!-- version of manual and date -->
<!ENTITY FDP-INFO SYSTEM "fdp-info-en.xml">
<!-- ************** local entities *********** -->
<!ENTITY APACHE "Apache HTTP">
<!ENTITY LOCALVER "5"> <!-- Set value to your choice, when guide version is out -->
<!-- of sync with FC release, use instead of FEDVER or FEDTESTVER -->
<!ENTITY BUG-URL
"https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Core&op_sys=Linux&version=fc3&component=fedora-docs&component_text=&rep_platform=All&priority=normal&bug_severity=normal&bug_status=NEW&assigned_to=kwade%40redhat.com&cc=&estimated_time=0.0&bug_file_loc=http%3A%2F%2Ffedora.redhat.com%2Fdocs%2Fselinux-faq-fc3%2F&short_desc=SELinux%20FAQ%20-%20%5Bsummarize%20FAQ%20change%20or%20addition%5D&comment=Description%20of%20change%2FFAQ%20addition.%20%20If%20a%20change%2C%20include%20the%20original%0D%0Atext%20first%2C%20then%20the%20changed%20text%3A%0D%0A%0D%0A%0D%0A%0D%0AVersion-Release&percnt!
;20of%20FAQ%20%28found%20on%0D%0Ahttp%3A%2F%2Ffedora.redhat.com%2Fdocs%2Fselinux-faq-fc3%2Fln-legalnotice.html%29%2C%0D%0Afor%20example%3A%0D%0A%0D%0A%20%20selinux-faq-1.3-8%20%282005-01-20-T16%3A20-0800%29%0D%0A%0D%0A%0D%0A%0D%0A%0D%0A%0D%0A%0D%0A%0D%0A&keywords=&dependson=&blocked=118757%20%20&maketemplate=Remember%20values%20as%20bookmarkable%20template&form_name=enter_bug">
]>
<article id="selinux-faq" lang="en">
&FDP-INFO;
<section id="s-selinux-faq">
<title>&SEL; Notes and FAQ</title>
<para>
The information in this FAQ is valuable for those who are new to &SEL;. It
is also valuable if you are new to the latest &SEL; implementation in
&FC;, since some of the behavior may be different than you have
experienced.
</para>
<note>
<title>This FAQ is specific to &FC; &LOCALVER;</title>
<para>
If you are looking for the FAQ for &FC; 2 or &FC; 3, refer to <ulink
url="http://fedora.redhat.com/docs/selinux-faq-fc2/" /> or <ulink
url="http://fedora.redhat.com/docs/selinux-faq-fc3/" />, respectively.
</para>
</note>
<para>
For more information about how &SEL; works, how to use &SEL; for general
and specific Linux distributions, and how to write policy, these resources
are useful:
</para>
<itemizedlist id="external-link-list">
<title>External Link List</title>
<listitem>
<para>
NSA &SEL; main website — <ulink
url="http://www.nsa.gov/selinux/" />
</para>
</listitem>
<listitem>
<para>
NSA &SEL; FAQ — <ulink
url="http://www.nsa.gov/selinux/info/faq.cfm" />
</para>
</listitem>
<listitem>
<para>
&SEL; community page — <ulink
url="http://selinux.sourceforge.net" />
</para>
</listitem>
<listitem>
<para>
UnOfficial FAQ — <ulink
url="http://www.crypt.gen.nz/selinux/faq.html" />
</para>
</listitem>
<listitem>
<para>
Writing traditional SE Linux policy HOWTO — <ulink
url="https://sourceforge.net/docman/display_doc.php?docid=21959&group_id=21266"
/>
</para>
</listitem>
<listitem>
<para>
Reference Policy (the new policy found in &FC; 5) — <ulink
url="http://serefpolicy.sourceforge.net/"
/>
</para>
</listitem>
<listitem>
<para>
SELinux policy development training courses — <ulink
url="http://tresys.com/services/training.shtml"
/> and <ulink
url="https://www.redhat.com/training/security/courses/rhs429.html"
/>
</para>
</listitem>
<listitem>
<para>
Getting Started with SE Linux HOWTO: the new SE Linux (Debian) —
<ulink
url="https://sourceforge.net/docman/display_doc.php?docid=20372&group_id=21266" />
</para>
</listitem>
<listitem>
<para>
List of SELinux object classes and permissions —
<ulink
url="http://tresys.com/selinux/obj_perms_help.shtml" />
</para>
</listitem>
<listitem>
<para>
On IRC — irc.freenode.net, #fedora-selinux
</para>
</listitem>
<listitem>
<para>
&FED; mailing list — <ulink
url="mailto:fedora-selinux-list at redhat.com" />;
read the archives or subscribe at <ulink
url="http://www.redhat.com/mailman/listinfo/fedora-selinux-list" />
</para>
</listitem>
</itemizedlist>
<tip>
<title>Making changes/additions to the &FED; &SEL; FAQ</title>
<para>
This FAQ is available at <ulink
url="http://fedora.redhat.com/docs/selinux-faq-fc5/">http://fedora.redhat.com/docs/selinux-faq-fc5/</ulink>.
</para>
<para>
For changes or additions to the &FED; &SEL; FAQ, use this <ulink
url="&BUG-URL;">bugzilla template</ulink>, which pre-fills most of the
bug report. Patches should be a <command>diff -u</command> against the
XML, which is available from CVS (refer to <ulink
url="http://fedora.redhat.com/projects/docs/" /> for details on
obtaining the fedora-docs/selinux-faq module from anonymous CVS; you can
get just the <filename>fedors-docs/selinux-faq</filename> module if you
don't want the entire <filename>fedora-dcs</filename> tree.) Otherwise,
plain text showing before and after is sufficient.
</para>
<para>
For a list of all bug reports filed against this FAQ, refer to <ulink
url="https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=118757">https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=118757</ulink>.
</para>
</tip>
<qandaset defaultlabel="qanda" id="selinux-faq-list">
<?dbhtml toc="1"?>
<qandadiv id="faq-div-understanding-selinux">
<title>Understanding &SEL;</title>
<qandaentry>
<question>
<para>
What is &SEL;?
</para>
</question>
<answer>
<para>
&SEL; (<firstterm>Security-Enhanced Linux</firstterm>) in &FC; is
an implementation of <firstterm>mandatory access
control</firstterm> in the Linux kernel using the
<firstterm>Linux Security Modules</firstterm>
(<abbrev>LSM</abbrev>) framework. Standard Linux security is a
<firstterm>discretionary access control</firstterm> model.
</para>
<itemizedlist>
<listitem>
<para>
Discretionary access control (<abbrev>DAC</abbrev>) —
this is standard Linux security, and it provides no protection
from broken software or malware running as a normal user or
root. Users can grant risky levels of access to files they
own.
</para>
</listitem>
<listitem>
<para>
Mandatory access control (<abbrev>MAC</abbrev>) — full
control over all interactions of software. Administratively
defined policy closely controls user and process interactions
with the system, and can provide protection from broken
software or malware running as any user.
</para>
</listitem>
</itemizedlist>
<para>
In a DAC model, file and resource decisions are based solely on
user identity and ownership of the objects. Each user and program
run by that user has complete discretion over the user's objects.
Malicious or flawed software can do anything with the files and
resources it controls through the user that started the process.
If the user is the super-user or the application is
<command>setuid</command> or <command>setgid</command> to root,
the process can have root level control over the entire file
system.
</para>
<para>
A MAC system does not suffer from these problems. First, you can
administratively-define a security policy over all processes and
objects. Second, you control all processes and objects, in the
case of &SEL; through the kernel. Third, decisions are based on
all the security relevant information available, and not just
authenticated user identity.
</para>
<para>
MAC under &SEL; allows you to provide granular permissions for all
<firstterm>subjects</firstterm> (users, programs, processes) and
<firstterm>objects</firstterm> (files, devices). In practice,
think of subjects as processes, and objects as the target of a
process operation. You can safely grant a process just the
permissions it needs to do its function, and no more.
</para>
<para>
The &SEL; implementation uses <firstterm>role-based access
control</firstterm> (<abbrev>RBAC</abbrev>), which provides
abstracted user-level control based on roles, and
<firstterm><trademark class="registered">Type
Enforcement</trademark></firstterm> (<abbrev>TE</abbrev>). TE
uses a table (matrix) to handle access controls, enforcing policy
rules based on the types of processes and objects. Process types
are called domains, and a cross-reference on the matrix of the
process's domain and the object's type defines their interaction.
This can provide extremely granular control for actors in a Linux
system.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
What is &SEL; policy?
</para>
</question>
<answer>
<para>
The &SEL; 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. &FC; policy is
delivered in a package, with an associated source package. Current
shipping policy packages are:
</para>
<itemizedlist>
<listitem>
<para><filename>selinux-policy-<replaceable><version></replaceable>.noarch.rpm</filename>
</para>
</listitem>
</itemizedlist>
<para>
This package is common to all types of policy and contains config
files/man pages.
</para>
<itemizedlist>
<listitem>
<para><filename>selinux-policy-devel-<replaceable><version></replaceable>.noarch.rpm</filename>
</para>
</listitem>
</itemizedlist>
<para>
This is 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/refpolicy/headers directory.
</para>
<itemizedlist>
<listitem>
<para><filename>selinux-policy-strict-<replaceable><version></replaceable>.noarch.rpm</filename>
</para>
</listitem>
<listitem>
<para>
<filename>selinux-policy-targeted-<replaceable><version></replaceable>.noarch.rpm</filename>
</para>
</listitem>
<listitem>
<para>
<filename>selinux-policy-mls-<replaceable><version></replaceable>.noarch.rpm</filename>
</para>
</listitem>
</itemizedlist>
<para>
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.
</para>
</answer>
</qandaentry>
<qandaentry>
<!-- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133403 thanks to -->
<!-- dwalsh for supplying the source FAQs -->
<question>
<para>
What is the &SEL; targeted policy?
</para>
</question>
<answer>
<para>
Initially, when &SEL; was included in Fedora Core, the NSA strict
policy was enforced. For testing purposes, this helped to find
hundreds of problems in the strict policy. In addition, it became
obvious that applying a single strict policy to the many
environments of &FED; users was not feasible. Managing a single
strict policy for anything other than default installation was
going to require local expertise.
</para>
<para>
At this point, the &SEL; developers reviewed their choices, and
decided to try a different strategy. It was decided to create a
policy that focuses on locking down specific daemons, especially
ones vulnerable to attack or to devastating a system if broken or
compromised. The rest of the system is allowed to run as if under
standard Linux security, i.e., run the same if &SEL; is enabled or
not.
</para>
<para>
Under targeted policy, most processes run in the
<computeroutput>unconfined_t</computeroutput> domain. As the name
implies, these processes are mostly not being confined by the
&SEL; policy. They are still governed by standard Linux/UNIX
security, however.
</para>
<para>
Specific network daemons have policy written for them, and the
<computeroutput>unconfined_t</computeroutput> policy transitions
to those policies when the application starts. For example, on
system boot, <command>init</command> runs under the
<computeroutput>unconfined_t</computeroutput> policy, but when
<command>named</command> starts, it is transitioned to the
<computeroutput>named_t</computeroutput> domain and is locked down
by the appropriate policy.
</para>
<para>
For more information on enabling or disabling targeted policy on each
of the specific daemons, refer to <xref
linkend="using-s-c-securitylevel"/>.
</para>
</answer>
</qandaentry>
<qandaentry>
<!-- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133403 thanks to -->
<!-- dwalsh for supplying the source FAQs -->
<question>
<para>
What daemons are protected by the targeted policy?
</para>
</question>
<answer>
<para>
Currently, the list of daemons is <command>dhcpd</command>,
<command>httpd</command> (<filename>apache.te</filename>),
<command>named</command>, <command>nscd</command>,
<command>ntpd</command>, <command>portmap</command>,
<command>snmpd</command>, <command>squid</command>, and
<command>syslogd</command>. The policy files for these daemons are
found in
<filename>/etc/selinux/targeted/src/policy/domains/program</filename>.
</para>
<para>
In the future, more daemons will be added to the targeted policy
protection.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Which daemons will you add to the targeted policy? How about
Sendmail, Postfix, MySQL, or PostgreSQL?
</para>
</question>
<answer>
<para>
&SEL; developers would like to add ftp and mail agents to targeted
policy eventually. For example, <command>vsftpd</command> could
work similar to <command>login</command>: after log-in, a new
process is executed under the user's context (real user or an
anonymous context).
</para>
<para>
One problem with mail agents is that they often need to manipulate
files in user home directories. One objective of the targeted
policy is to avoid labeling problems in the user home directories.
This is still being worked on.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
What about the strict policy? Does it even work?
</para>
</question>
<answer>
<para>
The strict policy <emphasis>does</emphasis> work on &FC;. It is
challenged by the unique environments of different users. For it
to work in your environment, you may need to tweak both the policy
and your systems.
</para>
<para>
To help make it easier to use the strict policy, &SEL; developers
have worked on making the change from one policy to the other
easier. For example,
<command>system-config-securitylevel</command> builds a relabel
into the startup scripts.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
What is the mls policy? Who is it for?
</para>
</question>
<answer>
<para>
The mls policy is similar to the strict policy, but adds an additional
field to security contexts for separating levels. These levels can be
used to separate data in an environment that calls for strict
hierarchical separation. The most common example of this is a military
setting where data is classified at a certain level. This policy is
geared toward these sorts of users, and is probably not useful to
you unless you fall into this category.
</para>
</answer>
</qandaentry>
<qandaentry id="faq-entry-whatis-refpolicy" xreflabel="Reference Policy">
<question>
<para>
What is the Reference Policy?
</para>
</question>
<answer>
<para>
The Reference Policy
is a new project designed to rewrite the entire SELinux policy in a
way that is easier to use and understand. To do this, it uses
the concepts of modularity, abstraction, and well-defined interfaces.
See <ulink
url="http://serefpolicy.sourceforge.net/">it's project page</ulink>
for more information on it.
</para>
<para>
Fedora policies at version 1.x are based on the traditional example
policy. Policies version 2.x (as used in &FC; &LOCALVER;) are based
on the Reference Policy.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
What are file contexts?
</para>
</question>
<answer>
<para>
File contexts are used by the <command>setfiles</command> command
to make the persistent labels which describe the security context
for a file or directory.
</para>
<para>
&FC; ships with the script <command>fixfiles</command> which
supports three options: <option>check</option>,
<option>restore</option>, and <option>relabel</option>. This
allows users to relabel the file system without having the
<filename>selinux-policy-targeted-sources</filename> package installed. The
command line usage is more friendly than the standard
<command>setfiles</command> command.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I view the security context of a file, user, or process?
</para>
</question>
<answer>
<para>
The new option <option>-Z</option> is the short method for
displaying the context of a subject or object:
</para>
<screen>
<command>ls -alZ <replaceable>file.foo</replaceable>
id -Z
ps -eZ</command>
</screen>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
What is the difference between a <firstterm>domain</firstterm> and
a <firstterm>type</firstterm>?
</para>
</question>
<answer>
<para>
There is no difference between a domain and a type, although
domain is sometimes used to refer to the type of a process. The
use of domain in this way stems from Domain and Type Enforcement (DTE)
models, where domains and types are separate.
</para>
</answer>
</qandaentry>
</qandadiv>
<qandadiv id="faq-div-controlling-selinux">
<title>Controlling &SEL;</title>
<qandaentry>
<question>
<para>
How do I install/not install &SEL;?
</para>
</question>
<answer>
<para>
The installer handles this based on the choice you make in the
<guilabel>Firewall Configuration</guilabel> screen. The default
running policy is the targeted policy, and it is on by default.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I switch the policy I'm currently using?
</para>
</question>
<answer>
<caution>
<title>Switching policy is not an act to be taken lightly.</title>
<para>
Other than trying out a new policy on a test machine for
research purposes, you should seriously consider your situation
before switching to a different policy on a production system.
</para>
<para>
The act of switching is straightforward. This is a fairly safe
method, but should be tried first on a test system.
</para>
</caution>
<para>
One method is to use
<command>system-config-securitylevel</command> to change the
policy and set the file system to relabel.
</para>
<para>
Following is the manual procedure:
</para>
<procedure>
<step>
<para>
Edit <filename>/etc/selinux/config</filename> and change the
type of policy to
<computeroutput>SELINUXTYPE=<replaceable>policyname</replaceable></computeroutput>.
</para>
</step>
<step>
<para>
To ensure that you can return from a reboot, set the mode to
<computeroutput>SELINUX=permissive</computeroutput>. This way
SELinux will be running under the correct policy, but will let
you login if there is a problem such as incorrect file context
labeling.
</para>
</step>
<step>
<para>
Tell the init scripts to relabel the system on reboot with the
command <command>touch /.autorelabel</command>.
</para>
</step>
<step>
<para>
Reboot the system. A clean restart under the new policy
allows all system processes to be started in the proper
context, and reveals any problems in the policy change.
</para>
</step>
<step>
<para>
Confirm your changes took effect with the command
<command>sestatus -v</command>. With the new system running
in <computeroutput>permissive</computeroutput> mode, check
<filename>/var/log/messages</filename> for
<computeroutput>avc: denied</computeroutput> messages. These
may indicate a problem that needs to be solved for the system
to run without trouble under the new policy.
</para>
</step>
<step>
<para>
When you are satisfied that the system runs stable under the
new policy, enable enforcing by changing
<computeroutput>SELINUX=enforcing</computeroutput>. You can
either reboot or run <command>setenforce 1</command> to turn
enforcing on in real time.
</para>
</step>
</procedure>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How can I back up files from an &SEL; file system?
</para>
</question>
<answer>
<para>
You can use the <command>star</command> utility, which supports
the extended attributes that store the security context labels.
Specify the <option>-xattr</option> and <option>exustar</option>
format when creating archives.
</para>
<screen>
<command>ls -Z /var/log/maillog</command>
-rw------- root root system_u:object_r:var_log_t /var/log/maillog
<command>cd /var/log
star -xattr -H=exustar -c -f maillog.star ./maillog*</command>
</screen>
<caution>
<title>Absolute paths can overwrite existing data</title>
<para>
If you use an absolute path, such as
<filename>/var/log/maillog</filename>, when you unpack the
archive with <command>star -c
-f</command>, the files will be restored on the same path they
were archived with. The <filename>maillog</filename> file will
attempt to write to <filename>/var/log/maillog</filename>. You
should received a warning from <command>star</command> if the
files about to be overwritten have a later date, but you cannot
count on this behavior.
</para>
<para>
Consider carefully how you construct your archiving argument.
</para>
</caution>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How can I install the strict policy by default with kickstart?
</para>
</question>
<answer>
<procedure>
<step>
<para>
Under the <computeroutput>%packages</computeroutput> section,
add <filename>selinux-policy-strict</filename>.
</para>
</step>
<step>
<para>
Under the <computeroutput>%post</computeroutput> section,
add the following:
</para>
<screen>
<computeroutput>lokkit -q --selinuxtype=strict
touch /.autorelabel</computeroutput>
</screen>
</step>
</procedure>
</answer>
</qandaentry>
<qandaentry id="using-s-c-securitylevel" xreflabel="How to use system-config-securitylevel">
<question>
<para>
How do I enable/disable &SEL; protection on specific daemons under
the targeted policy?
</para>
</question>
<answer>
<para>
Use <command>system-config-securitylevel</command> to control the
Boolean values of specific daemons. For example, if you find that
you need to disable &SEL; for Apache to run correctly in your
environment, you can disable the value in
<command>system-config-securitylevel</command>. This turns off the
transition to the policy defined in
<filename>apache.te</filename>, letting <command>httpd</command>
remain under regular Linux security.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I make a user <filename>public_html</filename> directory
work under &SEL;?
</para>
</question>
<answer>
<para>
This process presumes that you have enabled user public HTML
directories in Apache HTTP configuration
(<filename>/etc/httpd/conf/httpd.conf</filename>). This process
only covers serving static Web content. For more information
about &APACHE; and &SEL;, refer to <ulink
url="http://fedora.redhat.com/docs/selinux-apache-fc3/" />.
</para>
<procedure>
<step>
<para>
If you do not already have one, you will need to create the
<filename>public_html</filename> directory and populate it
with the files and folders to be served.
</para>
<screen>
<command>cd ~
mkdir public_html
cp /path/to/content ~/public_html</command>
</screen>
</step>
<step>
<para>
At this point, <command>httpd</command> is configured to serve
the contents, but you will still receive a <computeroutput>403
forbidden</computeroutput> error. This is because
<command>httpd</command> is not allowed to read the security
type for the directory and files as they are created in the
user's home directory. To solve this, change the security
context of the folder and its contents recursively using the
<option>-R</option> option:
</para>
<screen>
<command>ls -Z -d public_html/</command>
<computeroutput>drwxrwxr-x auser auser user_u:object_r:user_home_t public_html</computeroutput>
<command>chcon -R -t httpd_user_content_t public_html/
ls -Z -d public_html/</command>
<computeroutput>drwxrwxr-x auser auser user_u:object_r:httpd_user_content_t public_html/</computeroutput>
<command>ls -Z public_html/</command>
<computeroutput>-rw-rw-r-- auser auser user_u:object_r:httpd_user_content_t bar.html
-rw-rw-r-- auser auser user_u:object_r:httpd_user_content_t baz.html
-rw-rw-r-- auser auser user_u:object_r:httpd_user_content_t foo.html</computeroutput>
</screen>
<para>
You may notice at a later date that the user field, set here
to <computeroutput>user_u</computeroutput>, is changed to
<computeroutput>system_u</computeroutput>. This does not
affect how the targeted policy works; the field that matters
is the type field.
</para>
</step>
<step>
<para>
You should now be able to serve the static webpages. If you
continue to have errors, check to see that the Boolean that
enables user home directories is enabled. This can be set
using <application>system-config-securitylevel</application>,
under the <guilabel>&SEL;</guilabel> tab within the <guilabel>Modify
&SEL; Policy</guilabel> area, enabling <computeroutput>Allow
HTTPD to read home directories</computeroutput>. The changes
take effect immediately.
</para>
</step>
</procedure>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I turn &SEL; off at boot?
</para>
</question>
<answer>
<para>
Add <option>selinux=0</option> to your kernel command line.
</para>
<caution>
<title>Be careful when disabling &SEL;</title>
<para>
Be very careful using this option. If you boot with
<option>selinux=0</option>, any files you create while &SEL; is
disabled will not have &SEL; context information. At the least
you may need to relabel the file system, and it's possible you
will be unable to boot with <option>selinux=1</option>,
requiring a boot to single-user mode for recovery.
</para>
<para>
As an alternative to <option>selinux=0</option>, try using
<computeroutput>SELINUX=disabled</computeroutput> in
<filename>/etc/selinux/config</filename>.
</para>
</caution>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I turn enforcing on/off at boot?
</para>
</question>
<answer>
<para>
You can specify the &SEL; mode using the configuration file
<filename>/etc/sysconfig/selinux</filename>.
</para>
<screen>
<computeroutput># This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=<replaceable>enforcing</replaceable>
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=<replaceable>targeted</replaceable>
</computeroutput>
</screen>
<para>
Setting the value to <computeroutput>enforcing</computeroutput> is
the same as adding <option>enforcing=1</option> to your command
line when booting the kernel to turn enforcing on, while setting
the value to <computeroutput>permissive</computeroutput> is the
same as adding <option>enforcing=0</option> to turn enforcing off.
Note that the <emphasis role="bold">command line kernel parameter
overrides the configuration file</emphasis>.
</para>
<para>
However, setting the value to
<computeroutput>disabled</computeroutput> is not the same as the
<option>selinux=0</option> kernel boot parameter. Rather than
fully disabling &SEL; in the kernel, the
<computeroutput>disabled</computeroutput> setting instead turns
enforcing off and skips loading a policy.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I temporarily turn off enforcing mode without having to
reboot?
</para>
</question>
<answer>
<para>
This situation usually arises when you can't perform an action
that is being prevented by policy. Run the command
<command>setenforce 0</command> to turn off enforcing mode in real
time. When you are finished, run <command>setenforce 1</command>
to turn enforcing back on.
</para>
<note>
<title><computeroutput>sysadm_r</computeroutput> role
required</title>
<para>
You must issue the <command>setenforce</command> command with
the <computeroutput>sysadm_r</computeroutput> role; to do so,
use the <command>newrole</command> command. Alternately, if you
switch to root using <command>su -</command>, you gain the
<computeroutput>sysadm_r</computeroutput> role automatically.
</para>
</note>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I turn system-call auditing on/off at boot?
</para>
</question>
<answer>
<para>
Add <option>audit=1</option> to your kernel command line to turn
system-call auditing on. Add <option>audit=0</option> to your
kernel command line to turn system-call auditing off.
</para>
<para>
System-call auditing is on by default. When on, it provides
information about the system-call that was executing when SELinux
generated a <computeroutput>denied</computeroutput> message. This
may be helpful when debugging policy.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I temporarily turn off system-call auditing without having
to reboot?
</para>
</question>
<answer>
<para>
To do this, run <command>auditctl -e 0</command>. Note that this
will not affect auditing of SELinux AVC denials.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I get status info about my &SEL; installation?
</para>
</question>
<answer>
<para>
As root, execute the command <command>/usr/sbin/sestatus
-v</command>. For more information, refer to the
<filename>sestatus(8)</filename> manual page.
</para>
</answer>
</qandaentry>
</qandadiv>
<qandadiv id="faq-div-resolving-problems">
<title>Resolving Problems</title>
<qandaentry>
<question>
<para>
My application isn't working as expected and I am seeing
<computeroutput>avc: denied</computeroutput> messages, how do I
fix this?
</para>
</question>
<answer>
<para>
This message means that the current SELinux policy is not allowing
the application to do something. There are a number of reasons
this could happen.
</para>
<para>
First, one of the files the application is trying to access could
be mislabeled. If the AVC message refers to a specific file,
inspect its current label with <command>ls -alZ
<replaceable>/path/to/file</replaceable></command>. If it seems
wrong, you could try using <command>restorecon -v
<replaceable>/path/to/file</replaceable></command>. If you have
a large number of denials related to files, you may want to use
<command>fixfiles relabel</command>, or run
<command>restorecon</command> with the <option>-R</option> option
to recursively relabel a directory path.
</para>
<para>
Other times, denials may be due to a configuration change in the
program not being allowed by the policy. For example, if you
change Apache to also listen on port 8800, this will require a
change in the security policy, <filename>apache.te</filename>. See
<xref linkend="external-link-list"/> for more information about
writing policy.
</para>
<para>
If you are having trouble getting a specific application like Apache
to work, see <xref linkend="using-s-c-securitylevel"/> for
how to disable enforcement just for that application.
</para>
</answer>
</qandaentry>
<!-- <qandaentry>
<question>
<para>
I'm trying to upgrade from &FC; &FCVER; to &FC; &LOCALVER;, and
the installer keeps crashing with an &SEL; error.
</para>
</question>
<answer>
<para>
This occurs because Anaconda finds an existing
<filename>/selinux</filename> directory. This problem has been
fixed in the latest version of the installer.
</para>
<para>
To work around this bug, either remove the directory just prior to
upgrading, <command>rm -rf /selinux</command>, or during an
install, switch to tty2 before packages start being upgraded, and
do <command>rm -rf /mnt/sysimage/selinux</command>.
</para>
</answer>
</qandaentry>
-->
<qandaentry>
<question>
<para>
I installed &FC; on a system with an existing
<filename>/home</filename> partition, and now I can't log in.
</para>
</question>
<answer>
<para>
Your <filename>/home</filename> partition is not labeled
correctly. You can easily fix this two different ways.
</para>
<para>
If you just want to relabel <filename>/home</filename>
recursively:
</para>
<screen>
<command>/sbin/restorecon -v -R /home</command>
</screen>
<para>
If you want to be sure there are no other files incorrectly
labeled, you can relabel the entire file system:
</para>
<screen>
<command>/sbin/fixfiles relabel</command>
</screen>
<para>
You will need to have the <filename>policycoreutils</filename>
package installed to use <command>fixfiles</command>.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
After relabeling my <filename>/home</filename> using
<command>setfiles</command> or <command>fixfiles</command>, will I
still be able to read <filename>/home</filename> with a
non-&SEL;-enabled system?
</para>
</question>
<answer>
<para>
You can read the files from a non-&SEL; distribution, or one with
&SEL; disabled. However, files created by the non-&SEL; 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
<filename>~/.bashrc</filename>. You may have to relabel your
<filename>/home</filename> when you return to &FC;.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I share directories using NFS between &FC; and non-&SEL;
systems?
</para>
</question>
<answer>
<para>
Just as NFS transparently supports many file system types, it can
be used to share directories between &SEL; and non-&SEL; systems.
</para>
<para>
When mounting a non-&SEL; file system via NFS, by default &SEL;
will treat all the files in the share as having a context of
<computeroutput>nfs_t</computeroutput>. You can override the
default context by setting it manually using the
<option>context=</option> option. For example, this would make
the files in the NFS mounted directory appear to have a context of
<computeroutput>system_u:object_r:tmp_t</computeroutput> to &SEL;:
</para>
<screen>
<command>mount -t nfs -o context=system_u:object_r:tmp_t server:/shared/foo /mnt/foo</command>
</screen>
<para>
When &SEL; exports a file system via NFS, files created will have
the context of the directory they were created in. In other
words, the presence of &SEL; on the remote mounting system has no
effect on the local security contexts.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How can I create a new Linux user account with the user's home
directory having the proper context?
</para>
</question>
<answer>
<!-- wtf was I trying to say here?
<para>
This depends on the policy you are running. A very restrictive
policy requires you to change
</para>
-->
<para>
You can create your new user with the standard
<command>useradd</command> command. First you must become root;
under the strict policy you will need to change role to
<computeroutput>sysadm_r</computeroutput> using
<computeroutput>newrole -r sysadm_r</computeroutput>
For the targeted policy, you will not need
to switch roles, staying in
<computeroutput>unconfined_t</computeroutput>:
</para>
<screen>
<command>su - root
id -Z
root:system_r:unconfined_t
useradd auser
ls -Z /home
drwx------ auser auser root:object_r:user_home_dir_t /home/auser</command>
</screen>
<para>
The initial context for a new user directory has an identity of
<computeroutput>root</computeroutput>. Subsequent relabeling of
the file system will change the identity to
<computeroutput>system_u</computeroutput>. These are functionally
the same since the role and type are identical
(<computeroutput>object_r:user_home_dir_t</computeroutput>.)
</para>
</answer>
</qandaentry>
<!-- <qandaentry>
<question>
<para>
All of the other &SEL; documentation states that the
<command>su</command> command will only change Linux identity
<emphasis>not</emphasis> security role.
</para>
</question>
<answer>
<para>
The &FC; development team has taken a slightly different direction
than existing &SEL; practice. Security context transitions are
now integrated into <command>su</command> via
<computeroutput>pam_selinux</computeroutput>. This greatly
simplifies using the system.
</para>
<para>
In practice, this is like combining the traditional
<command>su</command> with the &SEL; <command>newrole</command>,
as one step instead of two.
</para>
<para>
Other forms of Linux/<trademark
class="registered">UNIX</trademark> identity change, for example
<command>setuid(2)</command>, do not cause an &SEL; identity
change.
</para>
</answer>
</qandaentry> -->
<qandaentry>
<question>
<para>
I'm having troubles with <command>avc</command> errors filling my
logs for a particular program. How do I choose not to audit the
access for it?
</para>
</question>
<answer>
<para>
For example, if you wanted to not audit <command>dmesg</command>,
you would put this in your
<filename>/etc/selinux/targeted/src/policy/dmesg.te</filename>
file:
</para>
<screen>
<computeroutput>dontaudit dmesg_t userdomain:fd { use };</computeroutput>
</screen>
<para>
This eliminates the error output to the terminal for all
userdomains (<varname>user</varname>, <varname>staff</varname> and
<varname>sysadm</varname>).
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Even running in permissive mode, I'm getting a large number of
<computeroutput>avc denied</computeroutput> messages.
</para>
</question>
<answer>
<para>
In a non-enforcing mode, you should actually get
<emphasis>more</emphasis> messages than in enforcing mode. This
occurs because the kernel is logging each access denial as if you
were in an enforcing mode. Since you are not being restricted, you
can perform more actions, which results in more denials being
logged.
</para>
<para>
For example, if an application running under an enforcing mode was
denied trying to read a number of files in a directory, it would
be stopped once at the beginning of the action. In a
non-enforcing mode, the application is not stopped from traversing
the directory tree, and would receive a denial message for each
file read in the directory.
</para>
</answer>
</qandaentry>
<!-- Need to modify this to work with new policy sources, or find
a better method than modifying all source
<qandaentry>
<question>
<para>
I get a specific permission denial only when &SEL; is in enforcing
mode, but I don't see any audit messages in
<filename>/var/log/audit/audit.log</filename>. How can I identify the
cause of these silent denials?
</para>
</question>
<answer>
<para>
The most common reason for a silent denial is when the policy
contains an explicit <computeroutput>dontaudit</computeroutput>
rule to suppress audit messages. The
<computeroutput>dontaudit</computeroutput> rule is often used this
way when a benign denial is filling the audit logs.
</para>
<para>
To look for your particular denial, you will need to enable
auditing of all <computeroutput>dontaudit</computeroutput> rules:
</para>
<screen>
<command>cd /etc/selinux/targeted/src/policy
make enableaudit
make load</command>
</screen>
<caution>
<title>Enabled <computeroutput>dontaudit</computeroutput> output
is verbose</title>
<para>
Enabling auditing of all
<computeroutput>dontaudit</computeroutput> rules will likely
produce a large amount of audit information, most of which is
irrelevant to your denial.
</para>
<para>
Use this technique only if you are specifically looking for an
audit message for a denial that seems to occur silently. You
will likely want to re-enable
<computeroutput>dontaudit</computeroutput> rules as soon as
possible.
</para>
</caution>
<para>
To re-enable <computeroutput>dontaudit</computeroutput> rules, do
the following:
</para>
<screen>
<command>cd /etc/selinux/targeted/src/policy
make clean
make load</command>
</screen> -->
<!-- commented out just in case it needs to be rewritten and included:
<para>
Another reason for getting silent denials is on an
<function>exec</function> when a domain transition would
normally occur, but the new domain is not authorized for
the current role.
</para>
<para>
At present, these errors are only logged when &SEL; is
running in permissive mode. This has been fixed in the
upstream Linux kernel so that it will log an audit message.
The current &FC; test kernel does not yet include this
change.
</para>
from ssmalley:
The Fedora kernel now includes the change, so the transition failures
now show up as security_compute_sid messages (also handled via the audit
framework). Example message below for a policy that failed to authorize
sysadm_r for system_chkpwd_t (an error from an earlier policy that has
been fixed):
audit(1083674459.837:0): security_compute_sid: invalid context root:sysadm_r:system_chkpwd_t for scontext=root:sysadm_r:newrole_t tcontext=system_u:object_r:chkpwd_exec_t tclass=process
</answer>
</qandaentry>
-->
<qandaentry>
<question>
<para>
Why do I not see the output when I run certain daemons in debug or
interactive mode?
</para>
</question>
<answer>
<para>
&SEL; intentionally disables access to the tty devices to stop
daemons from communicating back with the controlling terminal.
This communication is a potential security hole because such
daemons could insert commands into the controlling terminal. A
broken or compromised program could cause serious problems with
this.
</para>
<para>
There are a few ways you can capture STDOUT from daemons. One
method is to pipe the output to the cat command.
</para>
<screen>
<command>snmpd -v | cat</command>
</screen>
<para>
When debugging a daemon, you may want to turn of the transitioning
of the daemon to its specific domain. You can do this using
<application>system-config-securitylevel</application> or
<command>setsebool</command> on the command line.
</para>
<para>
A final option is to turn off enforcing mode while debugging. You
can do this with <command>setenforce 0</command>, using
<command>setenforce 1</command> to re-enable &SEL; when you are
finished debugging.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
When I do an upgrade of the policy package (for example, using
<command>yum</command>), what happens with the policy; is it
updated automatically?
</para>
</question>
<answer>
<para>
Policy reloads itself when the package is updated. This replaces
the manual <command>make load</command>.
</para>
<para>
In certain situations, it may be necessary to relabel the file
system. This might occur as part of an &SEL; bug fix where file
contexts become invalid, or when the policy update makes changes
to <varname>file_contexts</varname>.
</para>
<para>
After relabeling the file system, a <command>reboot</command> is
not required but is useful in ensuring every process and program
is running in the proper domain. This is highly dependent on the
changes in the updated policy.
</para>
<para>
To relabel, use the
<command>fixfiles</command> command or take advantage of the
<filename>/.autorelabel</filename> mechanism:
</para>
<screen>
<command>fixfiles relabel
reboot</command>
</screen>
<screen>
<command>touch /.autorelabel
reboot</command>
</screen>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
If the policy shipping with an application package changes in a
way that requires relabeling, will RPM handle relabeling the files
the package owns?
</para>
</question>
<answer>
<para>
Yes. The security contexts for the files owned by the package are
stored in the header data for the package. The file contexts are
set directly after the <command>cpio</command> copy, as the
package files are being put on the disk.
</para>
</answer>
</qandaentry>
<!-- Source package doesn't exist any more
Is there something similar now?
<qandaentry>
<question>
<para>
What is the relationship between policy and policy source
packages?
</para>
</question>
<answer>
-->
<!--
thanks to "Gene C." <czar czarc net> for authoring the
original answer in
http://www.redhat.com/archives/fedora-test-list/2004-April/msg00755.html
-->
<!--
<para>
A policy package such as
<filename>selinux-policy-targeted</filename> is a requirement for
a working &SEL; installation, while a policy source package such
as <filename>selinux-policy-targeted-sources</filename> is
required if you want to customize the default policy.
</para>
<para>
The policy package has the minimum files necessary for defining
the &SEL; security policy. It is kept trimmed down in size to
support a minimal install footprint.
</para>
<para>
The policy sources packages contain the source definitions in
<filename>/etc/selinux/<replaceable>policyname</replaceable>/src/policy</filename>
that are required to create the files
<filename>/etc/selinux/<replaceable>policyname</replaceable>/contexts/*</filename>
and
<filename>/etc/selinux/<replaceable>policyname</replaceable>/policy/policy.<replaceable>version</replaceable></filename>.
<replaceable>version</replaceable> is the version number of the
policy. </para>
<para>
Choosing which packages to install is based on the type of
installation. If you are going to use only the default security
policy defined by the &FC; developers, you only need the policy
package. If you want to customize your security policy in any
way, or otherwise want to run <command>setools</command>, you need
to install the policy source.
</para>
<para>
Installing or updating the policy package loads the new policy
after it installs the files. Similarly, installing or updating the
policy source package rebuilds the
<filename>policy.<replaceable>version</replaceable></filename>
file as well as the <filename>file_contexts</filename> file, then
loads them as the currently effective policy.
</para>
-->
<!-- not sure if currently still an issue, or how to rephrase
<caution>
<title>Caution</title>
<para>
If you have locally modified any of the policy sources, you want to be cautious about updating <filename>policy</filename> or <filename>policy-sources</filename>. Make
updating policy and/or policy-sources can have
interesting (but not particularly desirable)
effects. See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118604
</para>
</caution>
-->
<!--
</answer>
</qandaentry>
-->
<qandaentry>
<!--
http://www.redhat.com/archives/fedora-selinux-list/2004-May/msg00061.html
-->
<question>
<para>
Why do binary policies (e.g.
<filename>/etc/selinux/<replaceable>policyname</replaceable>/policy/policy.<<replaceable>version</replaceable>></filename>
distributed with Fedora and those I compile myself have different sizes
and md5sums?
</para>
</question>
<answer>
<para>
When you install a policy package, pre-compiled binary policy
files are put directly into <filename>/etc/selinux</filename>.
The different build environments will make target files that have
different sizes, md5sums.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Will new policy packages disable my system?
</para>
</question>
<answer>
<para>
There is a possibility that changes in the policy package or in
the policy shipping with an application package can cause errors,
more denials, or other unknown behaviors. To troubleshoot, you can
discover which package caused the breakage by reverting policy and
application packages one at a time. If you don't want to return
to the previous package, the older version of the configuration
files will be saved with a label of <filename>.rpmsave</filename>.
Be sure to use the mailing lists, bugzilla, and IRC to help you
work through your problem. If you are able, write or fix policy
to resolve your problem.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How can I help write policy?
</para>
</question>
<answer>
<para>
Your help is definitely appreciated.
<itemizedlist>
<listitem>
<para>
You can start by joining the
&FED; &SEL; mailing list, <ulink
url="mailto:fedora-selinux-list at redhat.com">fedora-selinux-list at redhat.com</ulink>;
you can subscribe and read the archives at <ulink
url="http://www.redhat.com/mailman/listinfo/fedora-selinux-list">http://www.redhat.com/mailman/listinfo/fedora-selinux-list</ulink>.
</para>
</listitem>
<listitem>
<para>
The UnOfficial FAQ has some generic policy writing HOWTO
information (<ulink
url="http://sourceforge.net/docman/display_doc.php?docid=14882&group_id=21266#BSP.1">http://sourceforge.net/docman/display_doc.php?docid=14882&group_id=21266#BSP.1</ulink>).
</para>
</listitem>
<listitem>
<para>
Another new resource is the Writing SE Linux policy HOWTO (<ulink
url="https://sourceforge.net/docman/display_doc.php?docid=21959&group_id=21266">https://sourceforge.net/docman/display_doc.php?docid=21959&group_id=21266</ulink>).
</para>
</listitem>
</itemizedlist>
Also, since the &FC; &LOCALVER; policy is based on the <xref linkend="faq-entry-whatis-refpolicy"/>,
you should look at the documentation on its project page.
</para>
<para>
Your best bet is to look at the policy files in
<filename>/usr/share/doc/selinux-policy-<replaceable>>version<</replaceable></filename>
which shows examples of policy.
</para>
<para>
If you want to write a new policy domain, you should install the
selinux-policy-devel package. This will place reference policy
interface files into the
<filename>/usr/share/selinux/refpolicy directory</filename>.
</para>
<para>
There is also a tool there to help you get started. You can use
the tool <command>policygentool</command> to generate your own
<filename>te</filename>, <filename>fc</filename>
and <filename>if</filename> file.
This tool takes two parameters: the Name of the policy module
(mydaemon) and the full path to the executable
(<filename>/usr/sbin/mydaemon</filename>). This will create three
files <filename>mydaemon.te</filename>,
<filename>mydaemon.fc</filename> and
<filename>mydaemon.if</filename>.
After you generate the policy files,
use the supplied Makefile,
<filename>/usr/share/selinux/refpolicy/Makefile</filename>,
build a policy package (<filename>mydaemon.pp</filename>). Now
you can load the policy
module, using <command>semodule</command>, and relabel the
executable using
<filename>restorecon</filename>. 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
<command>audit2allow</command> to translate the avc messages to
allow rules and begin
updating you <filename>mydaemon.te</filename> file. You should
search for interface
macros in the <filename>/etc/selinux/refpolicy/include</filename>
directory and use
these instead of using the allow rules directly, whenever
possible. 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.
</para>
<screen>
<command># /usr/share/selinux/refpolicy/policygentool mydaemon /usr/sbin/mydaemon
# make -f /usr/share/selinux/refpolicy/Makefile
m4 /usr/share/selinux/refpolicy/include/all_perms.spt /usr/share/selinux/refpolicy/include/loadable_module.spt /usr/share/selinux/refpolicy/include/misc_macros.spt
...
/usr/share/selinux/refpolicy/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
# semodule -i mydaemon.pp
# restorecon -v /usr/sbin/mydaemon
restorecon reset /usr/sbin/mydaemon context user_u:object_r:sbin_t->system_u:object_r:mydaemon_exec_t
# setenforce 1
# service mydaemon restart</command>
</screen>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
My console is being flooded with messages, how do I turn them off?
</para>
</question>
<answer>
<para>
To regain useful control, turn off kernel messages to the console
using <command>dmesg -n 1</command>.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Can I test the default policy without installing the policy
source?
</para>
</question>
<answer>
<para>
You can test &SEL; default policy by installing just the
<filename>selinux-policy-<replaceable>policyname</replaceable></filename>
and <filename>policycoreutils</filename> packages. Without the
policy source installed, the <command>fixfiles</command> command
automates the file system relabeling.
</para>
<para>
The command <command>fixfiles relabel</command> is the equivalent
of <command>make relabel</command>. During the relabeling, it
will delete all of the files in <filename>/tmp</filename>,
cleaning up files which may have old file context labels.
</para>
<para>
Other commands are <command>fixfiles check</command>, which checks
for mislabeled files, and <command>fixfiles restore</command>,
which fixes the mislabeled files but will not delete the files in
<filename>/tmp</filename>. <command>fixfiles</command> does not
take a list of directories as an argument, as its purpose is to
relabel the entire file system. If you need to relabel a specific
directory path, use <command>restorecon</command>.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
I am having trouble getting KDE applications to work under &SEL;.
</para>
</question>
<answer>
<para>
KDE executables always appear as <command>kdeinit</command>, which
limits what can be done with &SEL; policy. This is because every
KDE application runs in the domain for <command>kdeinit</command>.
</para>
<para>
Problems often arise when installing &SEL; because it is not
possible to relabel <filename>/tmp</filename> and
<filename>/var/tmp</filename>. There is no good method of
determining which file should have which context.
</para>
<para>
The solution is to fully log out of KDE and remove all KDE
temporary files:
</para>
<screen>
<command>rm -rf /var/tmp/kdecache-<replaceable><username></replaceable>
rm -rf /var/tmp/<replaceable><other_kde_files></replaceable></command>
</screen>
<para>
At your next login, your problem should be fixed.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Why does <computeroutput>SELINUX=disabled</computeroutput> not
work for me?
</para>
</question>
<answer>
<para>
Be careful of white space in the file
<filename>/etc/sysconfig/selinux</filename>. The code is very
sensitive to white space, even trailing space.
</para>
</answer>
</qandaentry>
</qandadiv>
<qandadiv id="faq-div-deploying-selinux">
<title>Deploying &SEL;</title>
<qandaentry>
<question>
<para>
What file systems can I use for &SEL;?
</para>
</question>
<answer>
<para>
The file system must support
<computeroutput>xattr</computeroutput> labels in the right
<parameter>security.*</parameter> namespace. In addition to
ext2/ext3, XFS has recently added support for the necessary
labels.
</para>
<para>
Note that XFS SELinux support is broken in upstream kernel
2.6.14 and 2.6.15, but fixed (worked around)
in 2.6.16. So, make sure your kernel includes this fix if
you choose to use XFS.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How does &SEL; impact system performance?
</para>
</question>
<answer>
<para>
This is a variable that is hard to measure, and is heavily
dependent on the size of the system &SEL; is running on. When
performance was last measured, the impact was around 7% for
completely untuned code. Changes since then are likely to have
made that worse in some cases, such as networking. SELinux
performance tuning will be a priority of the development team.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
What types of deployments/applications/systems, etc. should I
first look to leverage &SEL; in?
</para>
</question>
<answer>
<para>
Initially, &SEL; will serve on Internet facing servers that are
performing few, specialized functions, where it is critical to
keep extremely tight security. Such a box would typically be
stripped of all extra software and services, and run a very
focused service or set of services, such as a Web server or mail
server.
</para>
<para>
In these edge servers, you can lock down the policy very tightly.
This is made easier by the smaller number of interactions with
other components. Similarly, a dedicated box running a
specialized third-party application would be a good candidate.
</para>
<para>
For the future, &SEL; is targeted at all environments. In order to
get there, the community and <abbrev>ISV</abbrev>s
(<firstterm>independent software vendors</firstterm>) will need to
work with the &SEL; developers to produce the necessary policy. So
far, a very restrictive <firstterm>strict policy</firstterm> has
been written, as well as a <firstterm>targeted policy</firstterm>
that focuses on specific, vulnerable daemons.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How does &SEL; affect third-party applications?
</para>
</question>
<answer>
<para>
One goal of implementing a targeted &SEL; policy in &FC; is to
allow third-party applications to work without modification. This
works because the targeted policy is transparent to those
applications it is not trying to control that it essentially falls
back on standard Linux security. These applications will not be
running in an extra-secure manner. Policy needs to be written to
get these applications to be protected by MAC.
</para>
<para>
There are so many variations of third-party applications that it's
impossible to predict how they might behave with &SEL;, even
running the targeted policy. Issues that arise can sometimes be
fixed in policy. You may find that &SEL; shows you security
issues with your application that you were not aware of, requiring
the application to be modified to work under &SEL;.
</para>
<para>
One important value that &FC; testers and users bring to the
community is extensive testing of third-party applications. With
that in mind, please bring your experiences to the appropriate
mailing list (<ulink
url="mailto:fedora-selinux-list at redhat.com">fedora-selinux-list at redhat.com</ulink>)
for discussion.
</para>
<!-- Add policy modules section -->
<!-- Add managed policy section -->
</answer>
</qandaentry>
</qandadiv>
</qandaset>
</section>
</article>
More information about the Fedora-docs-commits
mailing list