selinux-faq/en rpm-info-en.xml,1.3,1.4 selinux-faq-en.xml,1.2,1.3
Paul W. Frields (pfrields)
fedora-docs-commits at redhat.com
Sun Feb 5 18:24:14 UTC 2006
Author: pfrields
Update of /cvs/docs/selinux-faq/en
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv3409/en
Modified Files:
rpm-info-en.xml selinux-faq-en.xml
Log Message:
Style and clarification updates; push to 1.5.1
Index: rpm-info-en.xml
===================================================================
RCS file: /cvs/docs/selinux-faq/en/rpm-info-en.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- rpm-info-en.xml 4 Feb 2006 19:43:55 -0000 1.3
+++ rpm-info-en.xml 5 Feb 2006 18:24:06 -0000 1.4
@@ -7,7 +7,7 @@
<worker surname="Karsten" firstname="Wade" id="KarstenWade" email="kwade at redhat.com" wholename="Karsten Wade" initials="KW"/>
<worker surname="Sellers" firstname="Chad" id="ChadSellers" email="csellers at tresys.com" wholename="Chad Sellers" initials="CS"/>
<worker surname="Tombolini" firstname="Francesco" id="FrancescoTombolini" email="tombo at adamantio.net" wholename="Francesco Tombolini" initials="FT"/>
- <worker firstname="Paul" othername="W." surname="Frields" initials="PWF" email="stickster at gmail.com" wholename="Paul W. Frields" id="PaulFrields"/>
+ <worker firstname="Paul" othername="W." surname="Frields" initials="PWF" email="stickster at gmail.com" wholename="Paul W. Frields" id="PaulWFrields"/>
</colophon>
<author worker="KarstenWade"/>
<author worker="ChadSellers"/>
@@ -24,23 +24,25 @@
</copyright>
<copyright>
<year>2006</year>
- <holder>Red Hat, Inc.</holder>
<holder>Chad Sellers</holder>
+ <holder>Paul W. Frields</holder>
</copyright>
<titles>
<translation lang="en">
<title>Fedora Core 5 SELinux FAQ</title>
- <desc>Frequently Asked Questions about SELinux in Fedora Core 5</desc>
+ <desc>Frequently asked questions about SELinux in Fedora Core 5</desc>
</translation>
<translation lang="it">
<title>Fedora Core 5 SELinux FAQ</title>
- <desc>
- -
- </desc>
+ <desc></desc>
</translation>
</titles>
<changelog order="newest-first">
- <revision date="Fri Feb 3 2006" number="1.5" role="doc">
+ <revision date="2006-02-05" number="1.5.1" role="doc">
+ <author worker="PaulWFrields"/>
+ <details lang="en">Style and readability editing; some element clarifications</details>
+ </revision>
+ <revision date="2006-02-03" number="1.5" role="doc">
<author worker="ChadSellers"/>
<details lang="en">First round of editing.</details>
<details lang="it">Primo round di editing.</details>
Index: selinux-faq-en.xml
===================================================================
RCS file: /cvs/docs/selinux-faq/en/selinux-faq-en.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- selinux-faq-en.xml 4 Feb 2006 17:52:49 -0000 1.2
+++ selinux-faq-en.xml 5 Feb 2006 18:24:06 -0000 1.3
@@ -7,8 +7,8 @@
%FEDORA-ENTITIES-EN;
<!ENTITY DOCBASE "selinux-faq">
-<!ENTITY DOCVERSION "1.5">
-<!ENTITY DOCDATE "2005-12-30-T12:21-0500">
+<!ENTITY DOCVERSION "1.5.1">
+<!ENTITY DOCDATE "2006-02-05">
<!ENTITY DOCID "&DOCBASE;-&DOCVERSION; (&DOCDATE;)"> <!-- version of manual and date -->
<!ENTITY FDP-INFO SYSTEM "fdp-info-en.xml">
@@ -165,26 +165,31 @@
(<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>
+ <variablelist>
+ <varlistentry>
+ <term>Discretionary access control (<abbrev>DAC</abbrev>)</term>
+ <listitem>
+ <para>
+ DAC 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>
+ </varlistentry>
+ <varlistentry>
+ <term>Mandatory access control (<abbrev>MAC</abbrev>)</term>
+ <listitem>
+ <para>
+ MAC provides 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>
+ </varlistentry>
+ </variablelist>
<para>
In a DAC model, file and resource decisions are based solely on
user identity and ownership of the objects. Each user and program
@@ -198,7 +203,7 @@
</para>
<para>
A MAC system does not suffer from these problems. First, you can
- administratively-define a security policy over all processes and
+ 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
@@ -209,26 +214,27 @@
<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.
+ process operation. You can safely grant a process only the
+ permissions it needs to perform 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.
+ 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, or <firstterm>matrix</firstterm> to handle access
+ controls, enforcing policy rules based on the types of processes
+ and objects. Process types are called
+ <firstterm>domains</firstterm>, and a cross-reference on the
+ matrix of the process's domain and the object's type defines their
+ interaction. This system provides extremely granular control for
+ actors in a Linux system.
</para>
</answer>
</qandaentry>
<qandaentry>
- <question>
+ <question id="qa-whatis-policy" xreflabel="What is SELinux policy?">
<para>
What is &SEL; policy?
</para>
@@ -236,58 +242,51 @@
<answer>
<para>
The &SEL; policy describes the access permissions for all subjects
- and objects, i.e., the entire system of users, programs, and
+ and objects, that is, 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>
+ <variablelist>
+ <varlistentry>
+ <term><filename>selinux-policy-<replaceable><version></replaceable>.noarch.rpm</filename></term>
+ <listitem>
+ <para>
+ This package is common to all types of policy and contains
+ config files/man pages.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>selinux-policy-devel-<replaceable><version></replaceable>.noarch.rpm</filename></term>
+ <listitem>
+ <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>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>selinux-policy-strict-<replaceable><version></replaceable>.noarch.rpm</filename></term>
+ <term><filename>selinux-policy-targeted-<replaceable><version></replaceable>.noarch.rpm</filename></term>
+ <term><filename>selinux-policy-mls-<replaceable><version></replaceable>.noarch.rpm</filename></term>
+ <listitem>
+ <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>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</answer>
</qandaentry>
- <qandaentry>
+ <qandaentry id="qa-whatis-targeted-policy" xreflabel="What is the
+ SELinux targeted policy?">
<!-- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133403 thanks to -->
<!-- dwalsh for supplying the source FAQs -->
<question>
@@ -297,44 +296,42 @@
</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.
+ When &SEL; was initially introduced in &FC;, it enforced the NSA
+ strict policy. For testing purposes, this effectively exposed
+ hundreds of problems in the strict policy. In addition, it
+ demonstrated that applying a single strict policy to the many
+ environments of &FED; users was not feasible. To manage a single
+ strict policy for anything other than default installation would
+ 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"/>.
+ decided to try a different strategy. They decided to create a
+ <firstterm>targeted</firstterm> policy that locks down specific
+ daemons, especially those vulnerable to attack or which could
+ devastate a system if broken or compromised. The rest of the
+ system runs exactly as it would under standard Linux DAC security.
+ </para>
+ <para>
+ Under the targeted policy, most processes run in the
+ <computeroutput>unconfined_t</computeroutput> domain. As the name
+ implies, these processes are mostly unconfined by the &SEL;
+ policy. They are still governed by standard Linux DAC security,
+ however.
+ </para>
+ <para>
+ Those network daemons which are addressed in the targeted policy
+ make a transition to the targeted policy when the application
+ starts. For example, at system boot, <command>init</command> runs
+ under the <computeroutput>unconfined_t</computeroutput> policy.
+ When <command>named</command> starts, it makes a transition 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="qa-using-s-c-securitylevel"/>.
</para>
</answer>
</qandaentry>
@@ -348,18 +345,43 @@
</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.
+ Currently, the list of daemons is:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para><command>dhcpd</command></para>
+ </listitem>
+ <listitem>
+ <para><command>httpd</command>
+ (<filename>apache.te</filename>)</para>
+ </listitem>
+ <listitem>
+ <para><command>named</command></para>
+ </listitem>
+ <listitem>
+ <para><command>nscd</command></para>
+ </listitem>
+ <listitem>
+ <para><command>ntpd</command></para>
+ </listitem>
+ <listitem>
+ <para><command>portmap</command></para>
+ </listitem>
+ <listitem>
+ <para><command>snmpd</command></para>
+ </listitem>
+ <listitem>
+ <para><command>squid</command></para>
+ </listitem>
+ <listitem>
+ <para><command>syslogd</command></para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ The policy files for these daemons are found in
+ <filename>/etc/selinux/targeted/src/policy/domains/program</filename>.
+ In the future, more daemons will be added to the targeted policy
+ protection.
</para>
</answer>
</qandaentry>
@@ -373,16 +395,16 @@
<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).
+ policy eventually. For example, <command>vsftpd</command> could
+ work similar to <command>login</command>: after log-in, a new
+ process would be 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.
+ Mail agents can be problematic because 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. &SEL; developers continue to work on this problem.
</para>
</answer>
</qandaentry>
@@ -395,16 +417,15 @@
<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.
+ challenged by the unique environments of different users. To use
+ the strict policy in your environment, you may need to fine-tune
+ 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.
+ To make the strict policy easier to use, &SEL; developers have
+ tried to make 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>
@@ -416,13 +437,13 @@
</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.
+ The mls policy is similar to the strict policy, but adds an
+ additional field to security contexts for separating levels. &SEL;
+ can use these levels to separate data in an environment that calls
+ for strict hierarchical separation. A typical example is a
+ military setting, where data is classified at a certain level.
+ This policy is geared toward this sort of environment, and is
+ probably not useful to you unless you fall into this category.
</para>
</answer>
</qandaentry>
@@ -434,17 +455,17 @@
</question>
<answer>
<para>
- The Reference Policy
+ The <firstterm>Reference Policy</firstterm>
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.
+ Refer to <ulink
+ url="http://serefpolicy.sourceforge.net/"/>
+ for more information on the Reference Policy.
</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
+ policy. Version 2.x policies (as used in &FC; &LOCALVER;) are based
on the Reference Policy.
</para>
</answer>
@@ -457,18 +478,18 @@
</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.
+ <firstterm>File contexts</firstterm> are used by the
+ <command>setfiles</command> command to generate persistent labels
+ which describe the security context for a file or directory.
</para>
<para>
- &FC; ships with the script <command>fixfiles</command> which
+ &FC; ships with the <command>fixfiles</command> script, 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.
+ script 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>
@@ -500,9 +521,9 @@
<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.
+ 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>
@@ -517,7 +538,7 @@
</question>
<answer>
<para>
- The installer handles this based on the choice you make in the
+ The installer follows 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>
@@ -526,52 +547,60 @@
<qandaentry>
<question>
<para>
- How do I switch the policy I'm currently using?
+ How do I switch the policy I am currently using?
</para>
</question>
<answer>
<caution>
- <title>Switching policy is not an act to be taken lightly.</title>
+ <title>Use caution when switching policy</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.
+ research purposes, you should seriously consider your situation
+ before switching to a different policy on a production system.
+ The act of switching is straightforward. This method is fairly
+ safe, but you should try it 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:
+ To use the automated method, run the <application>Security Level
+ Configuration</application> tool. From the GUI Main Menu,
+ select <menuchoice>
+ <guimenu>Desktop</guimenu>
+ <guisubmenu>System Settings</guisubmenu>
+ <guimenuitem>Security level</guimenuitem>
+ </menuchoice>, or from a terminal, run
+ <command>system-config-securitylevel</command>. Change the
+ policy as desired and ensure that the <guilabel>Relabel on next
+ reboot</guilabel> option is enaled.
+ </para>
+ <para>
+ You can also perform these steps manually with the following
+ 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>
+ type and the mode of policy:
+ </para>
+<screen>
+<userinput>SELINUXTYPE=<replaceable>policyname</replaceable>
+SELINUX=permissive</userinput>
+</screen>
<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.
+ This step ensures you will not be locked out after rebooting.
+ &SEL; will run under the correct policy, but will allow you to
+ 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>
+ Set the system to relabel the file system on reboot:
+ </para>
+<screen>
+<command>touch /.autorelabel</command>
+</screen>
</step>
<step>
<para>
@@ -582,13 +611,18 @@
</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.
+ Confirm your changes took effect with the following command:
+ </para>
+<screen>
+<command>sestatus -v</command>
+</screen>
+ <para>
+ 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>
@@ -611,10 +645,10 @@
</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.
+ Use the <command>star</command> utility, which supports the
+ extended attributes that store the security context labels.
+ Specify the <option>-xattr</option> and
+ <option>-H=exustar</option> options when creating archives.
</para>
<screen>
<command>ls -Z /var/log/maillog</command>
@@ -633,7 +667,7 @@
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.
+ rely on this behavior.
</para>
<para>
Consider carefully how you construct your archiving argument.
@@ -668,7 +702,7 @@
</procedure>
</answer>
</qandaentry>
- <qandaentry id="using-s-c-securitylevel" xreflabel="How to use system-config-securitylevel">
+ <qandaentry id="qa-using-s-c-securitylevel" xreflabel="How to use system-config-securitylevel">
<question>
<para>
How do I enable/disable &SEL; protection on specific daemons under
@@ -677,14 +711,16 @@
</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.
+ Use <command>system-config-securitylevel</command>, also known as
+ the <application>Security Level Configuration</application>
+ graphical tool, to control the
+ Boolean values of specific daemons. For example, if 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 change
+ disables the transition to the policy defined in
+ <filename>apache.te</filename>, allowing <command>httpd</command>
+ to remain under regular Linux DAC security.
</para>
</answer>
</qandaentry>
@@ -698,43 +734,43 @@
<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/" />.
+ directories in your Apache configuration file,
+ <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.
+ If you do not already have a
+ <filename>~/public_html</filename> directory, create it and
+ populate it with the files and folders to be served.
</para>
<screen>
-<command>cd ~
+<userinput>cd ~
mkdir public_html
-cp /path/to/content ~/public_html</command>
+cp /path/to/content ~/public_html</userinput>
</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:
+ 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. 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>
+<userinput>ls -Z -d public_html/</userinput>
<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>
+<userinput>chcon -R -t httpd_user_content_t public_html/
+ls -Z -d public_html/</userinput>
<computeroutput>drwxrwxr-x auser auser user_u:object_r:httpd_user_content_t public_html/</computeroutput>
-<command>ls -Z public_html/</command>
+<userinput>ls -Z public_html/</userinput>
<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>
@@ -743,20 +779,21 @@
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
+ 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.
+ Your static webpages should now be served correctly. If you
+ continue to have errors, ensure that the Boolean which enables
+ user home directories is enabled. You can set it using
+ <command>system-config-securitylevel</command>. Select
+ the <guilabel>&SEL;</guilabel> tab, and then select the
+ <guilabel>Modify &SEL; Policy</guilabel> area. Select
+ <computeroutput>Allow HTTPD to read home
+ directories</computeroutput>. The changes take effect
+ immediately.
</para>
</step>
</procedure>
@@ -769,24 +806,25 @@
</para>
</question>
<answer>
+ <para>
+ Set <computeroutput>SELINUX=disabled</computeroutput> in
+ <filename>/etc/selinux/config</filename>.
+ </para>
<para>
- Add <option>selinux=0</option> to your kernel command line.
+ Alternatively, you can add <option>selinux=0</option> to your
+ kernel boot parameters. However, this option is not recommended.
</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>
+ If you boot with <option>selinux=0</option>, any files you
+ create while &SEL; is disabled will not have &SEL; context
+ information. The file system will be marked for relabeling at
+ the next boot. If an unforeseen problem prevents you from
+ rebooting normally, you may need to boot in single-user mode for
+ recovery. Add the option <option>emergency</option> to your
+ kernel boot parameters.
+ </para>
</caution>
</answer>
</qandaentry>
@@ -806,23 +844,20 @@
# 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:
+# disabled - No SELinux policy is loaded.</computeroutput>
+SELINUX=<userinput><replaceable>enforcing</replaceable></userinput>
+<computeroutput># 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>
+# strict - Full SELinux protection.</computeroutput>
+SELINUXTYPE=<userinput><replaceable>targeted</replaceable></userinput>
</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>
+ the same as adding <option>enforcing=1</option> to the kernel boot
+ parameters. Setting the value to
+ <computeroutput>permissive</computeroutput> is the same as adding
+ <option>enforcing=0</option> to the kernel boot parameters.
+ </para>
<para>
However, setting the value to
<computeroutput>disabled</computeroutput> is not the same as the
@@ -831,6 +866,13 @@
<computeroutput>disabled</computeroutput> setting instead turns
enforcing off and skips loading a policy.
</para>
+ <important>
+ <title>&SEL; Configuration Precedence</title>
+ <para>
+ The command line kernel parameter overrides the configuration
+ file.
+ </para>
+ </important>
</answer>
</qandaentry>
<qandaentry>
@@ -842,21 +884,22 @@
</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.
+ Occasionally you may need to perform an action that is normally
+ 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>
+ <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.
+ the <computeroutput>sysadm_r</computeroutput> role. Use the
+ <command>newrole</command> command to assume this role.
+ Alternately, if you switch to root using <command>su
+ -</command>, you assume the
+ <computeroutput>sysadm_r</computeroutput> role automatically.
</para>
</note>
</answer>
@@ -864,20 +907,21 @@
<qandaentry>
<question>
<para>
- How do I turn system-call auditing on/off at boot?
+ 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.
+ 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.
+ System-call auditing is <emphasis>on</emphasis> by default. When
+ on, it provides information about the system call that was
+ executing when SELinux generated a
+ <computeroutput>denied</computeroutput> message. The error
+ message is helpful when debugging policy.
</para>
</answer>
</qandaentry>
@@ -890,7 +934,7 @@
</question>
<answer>
<para>
- To do this, run <command>auditctl -e 0</command>. Note that this
+ Run <command>auditctl -e 0</command>. Note that this command
will not affect auditing of SELinux AVC denials.
</para>
</answer>
@@ -916,7 +960,7 @@
<question>
<para>
My application isn't working as expected and I am seeing
- <computeroutput>avc: denied</computeroutput> messages, how do I
+ <computeroutput>avc: denied</computeroutput> messages. How do I
fix this?
</para>
</question>
@@ -928,28 +972,30 @@
</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
+ 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, use the command <command>restorecon -v
+ <replaceable>/path/to/file</replaceable></command> to restore
+ the file's default context. If you have a large number of denials
+ related to files, you may want to use <command>fixfiles
+ relabel</command>, or run <command>restorecon -R
+ <replaceable>/path</replaceable></command> to recursively
+ relabel a directory path.
+ </para>
+ <para>
+ Denials are sometimes due to a configuration change in the program
+ that triggered the denial message. For example, if you change
+ Apache to also listen on port 8800, you must also change the
+ security policy, <filename>apache.te</filename>. Refer to
<xref linkend="external-link-list"/> for more information about
- writing policy.
+ 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.
+ If you are having trouble getting a specific application like
+ Apache to work, refer to <xref linkend="qa-using-s-c-securitylevel"/>
+ for information on disabling enforcement just for that
+ application.
</para>
</answer>
</qandaentry>
@@ -1002,8 +1048,8 @@
<command>/sbin/fixfiles relabel</command>
</screen>
<para>
- You will need to have the <filename>policycoreutils</filename>
- package installed to use <command>fixfiles</command>.
+ You must have the <filename>policycoreutils</filename> package
+ installed to use <command>fixfiles</command>.
</para>
</answer>
</qandaentry>
@@ -1019,11 +1065,12 @@
<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;.
+ &SEL; disabled. However, files created by a system not using &SEL;
+ 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
+ <filename>/home</filename> when you reboot the &SEL; enabled &FC;
+ system.
</para>
</answer>
</qandaentry>
@@ -1040,11 +1087,11 @@
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;
+ When you mount 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
+ default context by setting it manually, using the
+ <option>context=</option> option. The following command makes
the files in the NFS mounted directory appear to have a context of
<computeroutput>system_u:object_r:tmp_t</computeroutput> to &SEL;:
</para>
@@ -1053,7 +1100,7 @@
</screen>
<para>
- When &SEL; exports a file system via NFS, files created will have
+ When &SEL; exports a file system via NFS, newly created files 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.
@@ -1076,21 +1123,27 @@
-->
<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
+ <command>useradd</command> command. First you must become
+ <systemitem class="username">root</systemitem>. Under the strict
+ policy you will need to change role to
+ <computeroutput>sysadm_r</computeroutput> with the following
+ command:
+ </para>
+<screen>
+<userinput>newrole -r sysadm_r</userinput>
+</screen>
+ <para>
+ 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>
+<userinput>su - root
+id -Z</userinput>
+<computeroutput>root:system_r:unconfined_t</computeroutput>
+<userinput>useradd auser
+ls -Z /home</userinput>
+<computeroutput>drwx------ auser auser root:object_r:user_home_dir_t /home/auser</computeroutput>
</screen>
<para>
The initial context for a new user directory has an identity of
@@ -1141,18 +1194,18 @@
</question>
<answer>
<para>
- For example, if you wanted to not audit <command>dmesg</command>,
+ If you wanted to not audit <command>dmesg</command>, for example,
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>
+<userinput>dontaudit dmesg_t userdomain:fd { use };</userinput>
</screen>
<para>
This eliminates the error output to the terminal for all
- userdomains (<varname>user</varname>, <varname>staff</varname> and
- <varname>sysadm</varname>).
+ user domains, including <varname>user</varname>,
+ <varname>staff</varname> and <varname>sysadm</varname>.
</para>
</answer>
</qandaentry>
@@ -1165,20 +1218,19 @@
</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.
+ In a non-enforcing mode, you should actually receive
+ <emphasis>more</emphasis> messages than in enforcing mode. The
+ kernel logs each access denial as if you were in an enforcing
+ mode. Since you are not restricted by policy enforcement, 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.
+ If an application running under an enforcing mode is denied
+ access to read a number of files in a directory, it is
+ stopped once at the beginning of the action. In a non-enforcing
+ mode, the application is not stopped from traversing the directory
+ tree, and generates a denial message for each file read in the
+ directory.
</para>
</answer>
</qandaentry>
@@ -1273,30 +1325,30 @@
<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.
+ 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 use this hole to cause serious
+ problems.
</para>
<para>
- There are a few ways you can capture STDOUT from daemons. One
- method is to pipe the output to the cat command.
+ There are a few ways you can capture standard output 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.
+ When debugging a daemon, you may want to turn off the transition
+ of the daemon to its specific domain. You can do this using
+ <command>system-config-securitylevel</command> 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.
+ A final option is to turn off enforcing mode while debugging.
+ Issue the command <command>setenforce 0</command> to turn off
+ enforcing mode, and use the command <command>setenforce
+ 1</command> to re-enable &SEL; when you are finished debugging.
</para>
</answer>
</qandaentry>
@@ -1304,36 +1356,39 @@
<question>
<para>
When I do an upgrade of the policy package (for example, using
- <command>yum</command>), what happens with the policy; is it
+ <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>.
+ Policy reloads itself when the package is updated. This behavior
+ 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>.
+ In certain situations, you may need 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 the
+ file
+ <filename>/etc/selinux/targeted/contexts/files/file_contexts</filename>.
</para>
<para>
- After relabeling the file system, a <command>reboot</command> is
- not required but is useful in ensuring every process and program
+ After the file system is relabeled, 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>
+ To relabel, you have several options. You may use the
+ <command>fixfiles</command> command:
+ </para>
<screen>
<command>fixfiles relabel
reboot</command>
</screen>
+ <para>
+ Alternately, use the <filename>/.autorelabel</filename> mechanism:
+ </para>
<screen>
<command>touch /.autorelabel
reboot</command>
@@ -1345,7 +1400,7 @@
<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?
+ owned by the package?
</para>
</question>
<answer>
@@ -1435,10 +1490,9 @@
-->
<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?
+ Why do binary policies distributed with Fedora, such as
+ <filename>/etc/selinux/<replaceable><policyname></replaceable>/policy/policy.<replaceable><version></replaceable></filename>,
+ and those I compile myself have different sizes and MD5 checksums?
</para>
</question>
<answer>
@@ -1446,7 +1500,7 @@
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.
+ different sizes and MD5 checksums.
</para>
</answer>
</qandaentry>
@@ -1459,15 +1513,16 @@
<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.
+ the policy shipping with an application package can cause errors,
+ more denials, or other unknown behaviors. 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 the extension <filename
+ class="extension">.rpmsave</filename>. 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>
@@ -1480,106 +1535,130 @@
<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>
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ You can start by joining the &FED; &SEL; mailing list. You can
+ subscribe and read the archives at <ulink
+ url="http://www.redhat.com/mailman/listinfo/fedora-selinux-list"/>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The Unofficial FAQ has some generic policy writing HOWTO
+ information. Refer to <ulink
+ url="http://sourceforge.net/docman/display_doc.php?docid=14882&group_id=21266#BSP.1"/>
+ for more information.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Another new resource is the Writing SE Linux policy HOWTO,
+ located online at <ulink
+ url="https://sourceforge.net/docman/display_doc.php?docid=21959&group_id=21266"/>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ 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. Another excellent source of
+ information is the policy files in
+ <filename>/usr/share/doc/selinux-policy-<replaceable>>version<</replaceable></filename>
which shows examples of policy.
- </para>
+ </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>
+ <filename>selinux-policy-devel</filename> package. This will place
+ reference policy interface files into the
+ <filename>/usr/share/selinux/refpolicy</filename> directory.
+ There are also tools available to help you generate new policy.
+ The following procedure is an example:
+ </para>
+ <procedure>
+ <step>
+ <para>
+ Use the <command>policygentool</command> command to generate
+ your own <filename>te</filename>, <filename>fc</filename> and
+ <filename>if</filename> files. The
+ <command>policygentool</command> command takes two parameters:
+ the name of the policy module and the full path to the
+ executable. The following command gives a usage example:
+ </para>
+<screen>
+<command>policygentool <replaceable>mydaemon /usr/sbin/mydaemon</replaceable></command>
+</screen>
+ <para>
+ This command creates three files:
+ <filename>mydaemon.te</filename>,
+ <filename>mydaemon.fc</filename> and
+ <filename>mydaemon.if</filename>.
+ </para>
+ </step>
+ <step>
+ <para>
+ After you generate the policy files, use the supplied
+ Makefile,
+ <filename>/usr/share/selinux/refpolicy/Makefile</filename>, to
+ build a policy package:
+ </para>
+<screen>
+<command>make -f /usr/share/selinux/refpolicy/Makefile</command>
+</screen>
+ </step>
+ <step>
+ <para>
+ Now you can load the policy module, using
+ <command>semodule</command>, and relabel the executable using
+ <command>restorecon</command>:
+ </para>
+<screen>
+<command>semodule -i <replaceable>mydaemon.pp</replaceable></command>
+<command>restorecon -v <replaceable>/usr/sbin/mydaemon</replaceable></command>
+</screen>
+ </step>
+ <step>
+ <para>
+ Since you have very limited policy for your executeable,
+ SELinux will prevent it from doing much. Turn on permissive
+ mode and then use the init script to start your daemon:
+ </para>
+<screen>
+<command>setenforce 1</command> <!-- is this right? -->
+<command>service <replaceable>mydaemon</replaceable> restart</command>
+</screen>
+ </step>
+ </procedure>
<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
+ Now you can 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
+ 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?
+ 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>.
+ with this command:
</para>
+<screen>
+<command>dmesg -n 1</command>
+</screen>
</answer>
</qandaentry>
<qandaentry>
@@ -1605,19 +1684,20 @@
</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>.
+ for mislabeled files, and <command>fixfiles restore</command>,
+ which fixes the mislabeled files but does not delete the files in
+ <filename>/tmp</filename>. The <command>fixfiles</command>
+ command does not take a list of directories as an argument,
+ because it relabels 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;.
+ Why are some of my KDE applications having trouble under &SEL;?
</para>
</question>
<answer>
@@ -1648,8 +1728,7 @@
<qandaentry>
<question>
<para>
- Why does <computeroutput>SELINUX=disabled</computeroutput> not
- work for me?
+ Why does <option>SELINUX=disabled</option> not work for me?
</para>
</question>
<answer>
@@ -1680,8 +1759,8 @@
<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.
+ in 2.6.16. Your kernel must include this fix if
+ you choose to use XFS with &SEL;.
</para>
</answer>
</qandaentry>
@@ -1694,45 +1773,51 @@
<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.
+ dependent on the tuning and usage of the system running &SEL;.
+ When performance was last measured, the impact was around 7% for
+ completely untuned code. Subsequent changes in system components
+ such as networking are likely to have made that worse in some
+ cases. &SEL; performance tuning continues to 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?
+ What types of deployments, applications, and systems should I
+ 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.
+ Initially, &SEL; has been used on Internet facing servers that are
+ performing a few specialized functions, where it is critical to
+ keep extremely tight security. Administrators typically strip
+ such a box of all extra software and services, and run a very
+ small, focused set of services. A Web server or mail server is a
+ good example.
</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>
+ The smaller number of interactions with other components makes
+ such a lockdown easier. A dedicated system running a specialized
+ third-party application would also be a good candidate.
+ </para>
+ <para>
+ In the future, &SEL; will be targeted at all environments. In
+ order to achieve this goal, the community and
+ <firstterm>independent software vendors</firstterm>
+ (<abbrev>ISV</abbrev>s) must 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>
+ <para>For more information about these policies, refer to <xref
+ linkend="qa-whatis-policy"/> and <xref
+ linkend="qa-whatis-targeted-policy"/>.
+ </para>
</answer>
</qandaentry>
<qandaentry>
@@ -1744,28 +1829,28 @@
<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.
+ allow third-party applications to work without modification. The
+ targeted policy is transparent to those unaddressed applications,
+ and it falls back on standard Linux DAC security. These
+ applications, however, will not be running in an extra-secure
+ manner. You or another provider must write policy to protect these
+ applications with MAC security.
</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;.
+ It is impossible to predict how every third-party application
+ might behave with &SEL;, even running the targeted policy. You
+ may be able to fix issues that arise by changing the policy. You
+ may find that &SEL; exposes previously unknown security issues
+ with your application. You may have to modify the application 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.
+ community is extensive testing of third-party applications. With
+ that in mind, please bring your experiences to the appropriate
+ mailing list, such as the fedora-selinux.list, for discussion. For
+ more information about that list, refer to <ulink
+ url="http://www.redhat.com/mailman/listinfo/fedora-selinux-list/"/>.
</para>
<!-- Add policy modules section -->
<!-- Add managed policy section -->
More information about the Fedora-docs-commits
mailing list