selinux-faq/en_US selinux-faq.xml,1.9,1.10
Chad Sellers (csellers)
fedora-docs-commits at redhat.com
Wed Apr 19 18:36:52 UTC 2006
Author: csellers
Update of /cvs/docs/selinux-faq/en_US
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26256
Modified Files:
selinux-faq.xml
Log Message:
moved key FAQs up, per bug in bz#18727
Index: selinux-faq.xml
===================================================================
RCS file: /cvs/docs/selinux-faq/en_US/selinux-faq.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- selinux-faq.xml 19 Apr 2006 18:20:37 -0000 1.9
+++ selinux-faq.xml 19 Apr 2006 18:36:49 -0000 1.10
@@ -714,6 +714,159 @@
</para>
</answer>
</qandaentry>
+ <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
+ the targeted policy?
+ </para>
+ </question>
+ <answer>
+ <para>
+ 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>
+ <qandaentry id="faq-entry-local.te" xreflabel="Local Policy Customizations">
+ <question>
+ <para>
+ In the past I have written local.te file in policy sources for my
+ own local customization to policy, how do I do this
+ in &FC; 5?
+ </para>
+ </question>
+ <answer>
+ <para>
+ Since &FC; 5 uses a modular policy, you don't have to have the
+ complete policy source any more. Now, you can just create a local
+ policy module for your local policy customizations. To do this,
+ follow these steps.
+ </para>
+ <procedure>
+ <step>
+ <para>
+ Create a temporary directory, and change into it.
+ </para>
+<screen>
+<computeroutput>$ mkdir foo
+$ cd foo</computeroutput>
+</screen>
+ </step>
+ <step>
+ <para>
+ Create empty te, if, and fc files.
+ </para>
+<screen>
+<computeroutput>$ touch local.te local.if local.fc</computeroutput>
+</screen>
+ </step>
+ <step>
+ <para>
+ Edit the local.te file, adding appropriate content.
+ For example:
+ </para>
+<screen>
+<computeroutput>policy_module(local, 1.0)
+
+require {
+ attribute httpdcontent;
+ type smbd_t;
+}
+
+allow smbd_t httpdcontent:dir create_dir_perms;
+allow smbd_t httpdcontent:{ file lnk_file } create_file_perms;</computeroutput>
+</screen>
+ <para>
+ There are 3 parts to this file.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The <computeroutput>policy_module</computeroutput> call
+ inserts statements to make the module work, including
+ declaring the module and requiring system roles, classes,
+ and permissions. Make sure the name declared here (local
+ in this case) matches the name you gave the file
+ (local.te).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The <computeroutput>require</computeroutput> block
+ lists the symbols that this module uses that must be
+ declared in other modules. In this case, we require the
+ attribute <computeroutput>httpdcontent</computeroutput>
+ and the type <computeroutput>smbd_t</computeroutput>.
+ Note that all types and attributes you use in rules
+ must be required here unless you are declaring them
+ yourself below.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The rest of the file is the policy, in this case
+ consisting only of a couple of allow rules. You could
+ also place type declarations, dontaudit statements,
+ interface calls, or most things that can go in a normal
+ te file here.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </step>
+ <step>
+ <para>
+ Build the policy module.
+ </para>
+<screen>
+<computeroutput>$ make -f /usr/share/selinux/devel/Makefile
+Compliling targeted local module
+/usr/bin/checkmodule: loading policy configuration from tmp/local.tmp
+/usr/bin/checkmodule: policy configuration loaded
+/usr/bin/checkmodule: writing binary representation (version 5) to tmp/local.mod
+Creating targeted local.pp policy package
+rm tmp/local.mod.fc tmp/local.mod</computeroutput>
+</screen>
+ <para>
+ Note that this uses <command>checkmodule</command>, which is
+ part of the checkpolicy rpm. So, make sure you install this
+ rpm before doing this.
+ </para>
+ </step>
+ <step>
+ <para>
+ Become root, and install the policy module with
+ <command>semodule</command>.
+ </para>
+<screen>
+<computeroutput>$ su
+Password:
+# semodule -i local.pp</computeroutput>
+</screen>
+ </step>
+ </procedure>
+ <note>
+ <title>Module are uniquely identified by name</title>
+ <para>
+ This means that if you later insert another
+ <filename>local.pp</filename>, it will
+ replace the one you just loaded. So, you should keep this
+ <filename>local.te</filename> around, and just add to it if you
+ need to make later policy customizations. If you lose it, but
+ want to keep your previous policy around, just call the new
+ local policy module something else (say local2.te).
+ </para>
+ </note>
+ </answer>
+ </qandaentry>
<qandaentry>
<question>
<para>
@@ -810,6 +963,127 @@
<qandaentry>
<question>
<para>
+ How can I help write policy?
+ </para>
+ </question>
+ <answer>
+ <para>
+ Your help is definitely appreciated.
+ </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 example policy files in
+ <filename>/usr/share/doc/selinux-policy-<replaceable>>version<</replaceable></filename>
+ and <filename>/usr/share/selinux/devel</filename>.
+ </para>
+ <para>
+ If you want to create a new policy domain, you can look at the
+ interface files in the
+ <filename>/usr/share/selinux/devel</filename> sub-directories.
+ There is also a tool there to help you get started.
+ 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>
+ It will prompt you for a few common domain characteristics,
+ and will create 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/devel/Makefile</filename>, to
+ build a policy package
+ (<filename>mydaemon.pp</filename>):
+ </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 executable,
+ 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 0</command>
+<command>service <replaceable>mydaemon</replaceable> restart</command>
+</screen>
+ </step>
+ </procedure>
+ <para>
+ Now you can collect avc messages. You can use
+ <command>audit2allow</command> to translate the avc messages to
+ allow rules and begin updating your
+ <filename>mydaemon.te</filename> file. You should search for
+ interface macros in the
+ <filename>/usr/share/selinux/devel/include</filename> directory and
+ use these instead of using the allow rules directly, whenever
+ possible. <command>audit2allow -R</command> will attempt to find
+ interfaces that match the allow rule.
+ If you want more examples of policy, you could always
+ install the selinux-policy src rpm, which contains all of the
+ policy te files for the reference policy.
+ </para>
+ </answer>
+ </qandaentry>
+ <qandaentry>
+ <question>
+ <para>
How do I switch the policy I am currently using?
</para>
</question>
@@ -965,28 +1239,6 @@
</procedure>
</answer>
</qandaentry>
- <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
- the targeted policy?
- </para>
- </question>
- <answer>
- <para>
- 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>
<qandaentry>
<question>
<para>
@@ -1195,195 +1447,64 @@
</para>
</question>
<answer>
- <para>
- Run <command>auditctl -e 0</command>. Note that this command
- does 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>
- <qandaentry>
- <question>
- <para>
- How do I write policy to allow a domain to use pam_unix.so?
- </para>
- </question>
- <answer>
- <para>
- Very few domains in the SELinux world are allowed to read the
- <filename>/etc/shadow</filename> file. There are constraint rules
- that prevent policy writers from writing code like
- </para>
-<screen>
-<command>allow mydomain_t shadow_t:file read;</command>
-</screen>
- <para>
- In RHEL4 you can setup your domain to use the
- <command>unix_chkpwd</command> command. The easiest way is to use
- the <command>unix_chkpwd</command> attribute. So if you were
- writing policy for an ftpd daemon you would write something like
- </para>
-<screen>
-<command>daemon_domain(vsftpd, `auth_chkpwd')</command>
-</screen>
- <para>
- This would create a context where
- vsftpd_t -> chkpwd_exec_t -> system_chkpwd_t which can read
- <filename>/etc/shadow</filename>, while vsftpd_t is not able to
- read it.
- </para>
- <para>
- In &FC; &LOCALVER;/RHEL5, add the rule
- </para>
-<screen>
-<command>auth_domtrans_chk_passwd(vsftpd_t)</command>
-</screen>
- </answer>
- </qandaentry>
- <qandaentry id="faq-entry-local.te" xreflabel="Local Policy Customizations">
- <question>
- <para>
- In the past I have written local.te file in policy sources for my
- own local customization to policy, how do I do this
- in &FC; 5?
- </para>
- </question>
- <answer>
- <para>
- Since &FC; 5 uses a modular policy, you don't have to have the
- complete policy source any more. Now, you can just create a local
- policy module for your local policy customizations. To do this,
- follow these steps.
- </para>
- <procedure>
- <step>
- <para>
- Create a temporary directory, and change into it.
- </para>
-<screen>
-<computeroutput>$ mkdir foo
-$ cd foo</computeroutput>
-</screen>
- </step>
- <step>
- <para>
- Create empty te, if, and fc files.
- </para>
-<screen>
-<computeroutput>$ touch local.te local.if local.fc</computeroutput>
-</screen>
- </step>
- <step>
- <para>
- Edit the local.te file, adding appropriate content.
- For example:
- </para>
-<screen>
-<computeroutput>policy_module(local, 1.0)
-
-require {
- attribute httpdcontent;
- type smbd_t;
-}
-
-allow smbd_t httpdcontent:dir create_dir_perms;
-allow smbd_t httpdcontent:{ file lnk_file } create_file_perms;</computeroutput>
-</screen>
- <para>
- There are 3 parts to this file.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The <computeroutput>policy_module</computeroutput> call
- inserts statements to make the module work, including
- declaring the module and requiring system roles, classes,
- and permissions. Make sure the name declared here (local
- in this case) matches the name you gave the file
- (local.te).
- </para>
- </listitem>
- <listitem>
- <para>
- The <computeroutput>require</computeroutput> block
- lists the symbols that this module uses that must be
- declared in other modules. In this case, we require the
- attribute <computeroutput>httpdcontent</computeroutput>
- and the type <computeroutput>smbd_t</computeroutput>.
- Note that all types and attributes you use in rules
- must be required here unless you are declaring them
- yourself below.
- </para>
- </listitem>
- <listitem>
- <para>
- The rest of the file is the policy, in this case
- consisting only of a couple of allow rules. You could
- also place type declarations, dontaudit statements,
- interface calls, or most things that can go in a normal
- te file here.
- </para>
- </listitem>
- </itemizedlist>
- </step>
- <step>
- <para>
- Build the policy module.
- </para>
+ <para>
+ Run <command>auditctl -e 0</command>. Note that this command
+ does 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>
+ <qandaentry>
+ <question>
+ <para>
+ How do I write policy to allow a domain to use pam_unix.so?
+ </para>
+ </question>
+ <answer>
+ <para>
+ Very few domains in the SELinux world are allowed to read the
+ <filename>/etc/shadow</filename> file. There are constraint rules
+ that prevent policy writers from writing code like
+ </para>
<screen>
-<computeroutput>$ make -f /usr/share/selinux/devel/Makefile
-Compliling targeted local module
-/usr/bin/checkmodule: loading policy configuration from tmp/local.tmp
-/usr/bin/checkmodule: policy configuration loaded
-/usr/bin/checkmodule: writing binary representation (version 5) to tmp/local.mod
-Creating targeted local.pp policy package
-rm tmp/local.mod.fc tmp/local.mod</computeroutput>
+<command>allow mydomain_t shadow_t:file read;</command>
</screen>
- <para>
- Note that this uses <command>checkmodule</command>, which is
- part of the checkpolicy rpm. So, make sure you install this
- rpm before doing this.
- </para>
- </step>
- <step>
- <para>
- Become root, and install the policy module with
- <command>semodule</command>.
- </para>
+ <para>
+ In RHEL4 you can setup your domain to use the
+ <command>unix_chkpwd</command> command. The easiest way is to use
+ the <command>unix_chkpwd</command> attribute. So if you were
+ writing policy for an ftpd daemon you would write something like
+ </para>
<screen>
-<computeroutput>$ su
-Password:
-# semodule -i local.pp</computeroutput>
+<command>daemon_domain(vsftpd, `auth_chkpwd')</command>
</screen>
- </step>
- </procedure>
- <note>
- <title>Module are uniquely identified by name</title>
- <para>
- This means that if you later insert another
- <filename>local.pp</filename>, it will
- replace the one you just loaded. So, you should keep this
- <filename>local.te</filename> around, and just add to it if you
- need to make later policy customizations. If you lose it, but
- want to keep your previous policy around, just call the new
- local policy module something else (say local2.te).
- </para>
- </note>
- </answer>
- </qandaentry>
+ <para>
+ This would create a context where
+ vsftpd_t -> chkpwd_exec_t -> system_chkpwd_t which can read
+ <filename>/etc/shadow</filename>, while vsftpd_t is not able to
+ read it.
+ </para>
+ <para>
+ In &FC; &LOCALVER;/RHEL5, add the rule
+ </para>
+<screen>
+<command>auth_domtrans_chk_passwd(vsftpd_t)</command>
+</screen>
+ </answer>
+ </qandaentry>
<qandaentry>
<question>
<para>
@@ -1418,6 +1539,28 @@
<qandaentry>
<question>
<para>
+ Where are &SEL; AVC messages (denial logs, etc.) stored?
+ </para>
+ </question>
+ <answer>
+ <para>
+ In &FC; 2 and 3, SELinux AVC messages could be found in
+ <filename>/var/log/messages</filename>.
+ In &FC; 4, the audit daemon was added, and these messages
+ moved to
+ <filename>/var/log/audit/audit.log</filename>.
+ In &FC; 5, the audit daemon is not installed by default, and
+ consequently these messages can be found in
+ <filename>/var/log/messages</filename> unless you choose to
+ install and enable the audit daemon, in which case AVC
+ messages will be in
+ <filename>/var/log/audit/audit.log</filename>.
+ </para>
+ </answer>
+ </qandaentry>
+ <qandaentry>
+ <question>
+ <para>
My application isn't working as expected and I am seeing
<computeroutput>avc: denied</computeroutput> messages. How do I
fix this?
@@ -1980,127 +2123,6 @@
<qandaentry>
<question>
<para>
- How can I help write policy?
- </para>
- </question>
- <answer>
- <para>
- Your help is definitely appreciated.
- </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 example policy files in
- <filename>/usr/share/doc/selinux-policy-<replaceable>>version<</replaceable></filename>
- and <filename>/usr/share/selinux/devel</filename>.
- </para>
- <para>
- If you want to create a new policy domain, you can look at the
- interface files in the
- <filename>/usr/share/selinux/devel</filename> sub-directories.
- There is also a tool there to help you get started.
- 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>
- It will prompt you for a few common domain characteristics,
- and will create 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/devel/Makefile</filename>, to
- build a policy package
- (<filename>mydaemon.pp</filename>):
- </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 executable,
- 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 0</command>
-<command>service <replaceable>mydaemon</replaceable> restart</command>
-</screen>
- </step>
- </procedure>
- <para>
- Now you can collect avc messages. You can use
- <command>audit2allow</command> to translate the avc messages to
- allow rules and begin updating your
- <filename>mydaemon.te</filename> file. You should search for
- interface macros in the
- <filename>/usr/share/selinux/devel/include</filename> directory and
- use these instead of using the allow rules directly, whenever
- possible. <command>audit2allow -R</command> will attempt to find
- interfaces that match the allow rule.
- If you want more examples of policy, you could always
- install the selinux-policy src rpm, which contains all of the
- policy te files for the reference policy.
- </para>
- </answer>
- </qandaentry>
- <qandaentry>
- <question>
- <para>
My console is being flooded with messages. How do I turn them
off?
</para>
@@ -2478,28 +2500,6 @@
</itemizedlist>
</answer>
</qandaentry>
- <qandaentry>
- <question>
- <para>
- Where are &SEL; AVC messages (denial logs, etc.) stored?
- </para>
- </question>
- <answer>
- <para>
- In &FC; 2 and 3, SELinux AVC messages could be found in
- <filename>/var/log/messages</filename>.
- In &FC; 4, the audit daemon was added, and these messages
- moved to
- <filename>/var/log/audit/audit.log</filename>.
- In &FC; 5, the audit daemon is not installed by default, and
- consequently these messages can be found in
- <filename>/var/log/messages</filename> unless you choose to
- install and enable the audit daemon, in which case AVC
- messages will be in
- <filename>/var/log/audit/audit.log</filename>.
- </para>
- </answer>
- </qandaentry>
</qandadiv>
<qandadiv id="faq-div-deploying-selinux">
<title>Deploying &SEL;</title>
More information about the Fedora-docs-commits
mailing list