* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/hardened/selinux: hb-appendix-reference.xml hb-appendix-troubleshoot.xml hb-intro-concepts.xml hb-intro-enhancingsecurity.xml hb-intro-referencepolicy.xml hb-intro-virtualization.xml hb-selinux-conv-reboot1.xml hb-selinux-conv-reboot2.xml hb-using-commands.xml hb-using-enforcing.xml hb-using-install.xml hb-using-permissive.xml hb-using-policymodules.xml index.xml selinux-handbook.xml
@ 2011-03-26 23:29 Magnus Granberg (zorry)
0 siblings, 0 replies; only message in thread
From: Magnus Granberg (zorry) @ 2011-03-26 23:29 UTC (permalink / raw
To: gentoo-commits
zorry 11/03/26 23:29:55
Modified: hb-selinux-conv-reboot1.xml
hb-selinux-conv-reboot2.xml index.xml
selinux-handbook.xml
Added: hb-appendix-reference.xml
hb-appendix-troubleshoot.xml hb-intro-concepts.xml
hb-intro-enhancingsecurity.xml
hb-intro-referencepolicy.xml
hb-intro-virtualization.xml hb-using-commands.xml
hb-using-enforcing.xml hb-using-install.xml
hb-using-permissive.xml hb-using-policymodules.xml
Log:
Update the selinux docs
Revision Changes Path
1.12 xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot1.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot1.xml?rev=1.12&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot1.xml?rev=1.12&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot1.xml?r1=1.11&r2=1.12
Index: hb-selinux-conv-reboot1.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot1.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- hb-selinux-conv-reboot1.xml 6 Oct 2010 15:11:15 -0000 1.11
+++ hb-selinux-conv-reboot1.xml 26 Mar 2011 23:29:55 -0000 1.12
@@ -4,11 +4,11 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot1.xml,v 1.11 2010/10/06 15:11:15 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot1.xml,v 1.12 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
-<version>2.1</version>
-<date>2010-10-06</date>
+<version>2.2</version>
+<date>2010-11-27</date>
<section><title>Merge a SELinux Kernel</title>
<subsection><body>
@@ -119,7 +119,7 @@
</p>
<note>It is recommended to configure PaX if you are using harded-sources (also
-recommended). More information about Pax can be found in the <uri link="http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml">Hardened Gentoo
+recommended). More information about Pax can be found in the <uri link="/proj/en/hardened/pax-quickstart.xml">Hardened Gentoo
PaX Quickstart Guide</uri>.
</note>
1.12 xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot2.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot2.xml?rev=1.12&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot2.xml?rev=1.12&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot2.xml?r1=1.11&r2=1.12
Index: hb-selinux-conv-reboot2.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot2.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- hb-selinux-conv-reboot2.xml 25 Jun 2010 16:07:19 -0000 1.11
+++ hb-selinux-conv-reboot2.xml 26 Mar 2011 23:29:55 -0000 1.12
@@ -4,11 +4,11 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot2.xml,v 1.11 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-selinux-conv-reboot2.xml,v 1.12 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
-<version>2.2</version>
-<date>2009-12-15</date>
+<version>2.3</version>
+<date>2010-11-27</date>
<section><title>Merge SELinux Packages</title>
<subsection>
@@ -200,7 +200,7 @@
# <i>rlpkg -a -r</i>
</pre>
<note>
- It is strongly suggested to <uri link="http://www.gentoo.org/main/en/lists.xml">subscribe</uri>
+ It is strongly suggested to <uri link="/main/en/lists.xml">subscribe</uri>
to the gentoo-hardened mail list. It is generally a low traffic list, and
SELinux announcements are made there.
</note>
1.42 xml/htdocs/proj/en/hardened/selinux/index.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/index.xml?rev=1.42&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/index.xml?rev=1.42&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/index.xml?r1=1.41&r2=1.42
Index: index.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/index.xml,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- index.xml 22 Jul 2009 13:38:18 -0000 1.41
+++ index.xml 26 Mar 2011 23:29:55 -0000 1.42
@@ -2,7 +2,7 @@
<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
<!DOCTYPE project SYSTEM "/dtd/project.dtd">
-<!--$Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/index.xml,v 1.41 2009/07/22 13:38:18 pebenito Exp $-->
+<!--$Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/index.xml,v 1.42 2011/03/26 23:29:55 zorry Exp $-->
<project>
<name>SELinux</name>
@@ -31,12 +31,12 @@
<title>What is SELinux?</title>
<section><body>
<p>
- <uri link="http://www.nsa.gov/selinux">Security-Enhanced Linux</uri> (SELinux)
- is a system of mandatory access control using type enforcement and role-based
- access control. It is implemented as a
- <uri link="http://lsm.immunix.org/">Linux Security Module</uri> (LSM).
- In addition to the kernel portion, SELinux consists of a library (libselinux)
- and userland utilities for compiling policy (checkpolicy), and loading policy
+ <uri link="http://www.nsa.gov/research/selinux/index.shtml">Security-Enhanced
+ Linux</uri> (SELinux) is a system of mandatory access control using type
+ enforcement and role-based access control. It is implemented as a <uri
+ link="http://lsm.immunix.org/">Linux Security Module</uri> (LSM). In addition
+ to the kernel portion, SELinux consists of a library (libselinux) and userland
+ utilities for compiling policy (checkpolicy), and loading policy
(policycoreutils), in addition to other user programs.
</p>
<p>
@@ -49,6 +49,8 @@
</extrachapter>
<dev role="lead" description="Policy, x86, AMD64">pebenito</dev>
+<dev role="Policy development, Proxy (non developer contributors)">blueness
+</dev>
<extraproject name="Base Policy" lead="pebenito">
SELinux policy for the core system, including users, administrators, and
@@ -75,7 +77,29 @@
<!--
<resource link="http://selinux.dev.gentoo.org">SELinux Demonstration Machine</resource>
-->
-<resource link="http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml">Gentoo SELinux Handbook</resource>
+<resource link="/proj/en/hardened/selinux/selinux-handbook.xml">Gentoo SELinux Handbook</resource>
+
+<extrachapter position="devs">
+<title>Contributors</title>
+<section>
+<body>
+
+<p>
+The following people although non-developer is actively contributing with the
+project:
+</p>
+<table>
+<tr><th>Contributor</th><th>Nickname</th><th>Role</th></tr>
+<tr><ti>Chris Richards</ti><ti>gizmo</ti>
+<ti>Policy development, support</ti></tr>
+<tr><ti>Sven Vermeulen</ti><ti>SwifT</ti>
+<ti>Documentation writing, policy development, support</ti></tr>
+</table>
+
+</body>
+</section>
+</extrachapter>
+
<extrachapter position="resources">
<title>How Do I Use This?</title>
1.10 xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml?rev=1.10&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml?rev=1.10&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml?r1=1.9&r2=1.10
Index: selinux-handbook.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- selinux-handbook.xml 25 Jun 2010 16:07:19 -0000 1.9
+++ selinux-handbook.xml 26 Mar 2011 23:29:55 -0000 1.10
@@ -1,15 +1,17 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE book SYSTEM "/dtd/book.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml,v 1.9 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml,v 1.10 2011/03/26 23:29:55 zorry Exp $ -->
-<book link="selinux-handbook.xml">
+<book link="selinux-handbook.xml" disclaimer="draft">
<title>Gentoo SELinux Handbook</title>
<author title="Author">
<mail link="pebenito@gentoo.org">Chris PeBenito</mail>
</author>
-
+<author title="Author">
+ <mail link="sven.vermeulen@siphos.be">Sven Vermeulen</mail>
+</author>
<author title="Author">
Chris Richards
</author>
@@ -22,129 +24,159 @@
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<license/>
-<version>2.00</version>
-<date>2006-10-15</date>
+<version>3.00</version>
+<date>2010-12-01</date>
<part>
-<title>Installing Gentoo SELinux</title>
+<title>Introduction to Gentoo/Hardened SELinux</title>
<abstract>
-In this part you learn how to install Gentoo SELinux on your system.
+In this part we cover what SELinux is and how it is positioned within the
+Gentoo/Hardened project.
</abstract>
<chapter>
-<title>Gentoo SELinux Installation</title>
+<title>Enhancing Linux Security</title>
<abstract>
-How to do a fresh installation of Gentoo SELinux.
+Security is more than enabling a certain framework or installing a different
+Linux kernel. It is a way of working / administrating your Gentoo Linux system.
+We cover a few (generic) best practices, and then elaborate on what Mandatory
+Access Control is and how SELinux fills in this gap.
</abstract>
- <include href="hb-install.xml"/>
+ <include href="hb-intro-enhancingsecurity.xml"/>
</chapter>
-</part>
-<part>
-<title>Converting to Gentoo SELinux</title>
-<abstract>
-SELinux alternatively can be installed on current Linux installations. This
-Chapter deals with converting a prexisting Gentoo install to SELinux.
-</abstract>
<chapter>
-<title>Initial preparations</title>
+<title>SELinux Concepts</title>
<abstract>
-A few preparations must be done before installing SELinux packages.
+To be able to properly work with SELinux, it is vital that you understand a few
+of its concepts like domains, domain transitions and file contexts. Without
+a basic understanding of these aspects, it will be difficult to understand
+how SELinux policies work and how to troubleshoot if things go wrong.
</abstract>
- <include href="hb-selinux-conv-profile.xml"/>
+ <include href="hb-intro-concepts.xml"/>
</chapter>
+
<chapter>
-<title>Boot SELinux Kernel</title>
+<title>The SELinux (Reference) Policy</title>
<abstract>
-Install and boot a SELinux kernel.
+To streamline SELinux policy development, a reference policy is being developed
+that is used by all SELinux-supporting distributions. In this chapter we give
+some intel on what this reference policy is and why it is brought to life, but
+also how this policy functions and how its development is progressing. We also
+cover the basics on SELinux policies in general.
</abstract>
- <include href="hb-selinux-conv-reboot1.xml"/>
+ <include href="hb-intro-referencepolicy.xml"/>
</chapter>
+
+<!--
+ Removed for the time being, not critical.
+ Moved to next major version of handbook.
+
<chapter>
-<title>Install SELinux Userland</title>
+<title>SELinux Virtual Machine Support</title>
<abstract>
-Install SELinux packages and policy, and label filesystems.
+SELinux support is being actively integrated in libvirt and other
+virtualization frameworks to elevate the security of virtualized
+environments. Within this chapter we give you a first introduction
+on how this is done for libvirt managed environments and what you need to take
+into account if you wish to use SELinux within your virtualized environment.
</abstract>
- <include href="hb-selinux-conv-reboot2.xml"/>
+ <include href="hb-intro-virtualization.xml"/>
</chapter>
+-->
</part>
<part>
-<title>Working with SELinux</title>
+<title>Using Gentoo/Hardened SELinux</title>
<abstract>
-Learn how to work with SELinux
+With the theoretic stuff behind us, let us start by installing Gentoo/Hardened
+with a SELinux kernel as well as the SELinux tools.
</abstract>
+
<chapter>
-<title>SELinux Overview</title>
-<abstract>
-SELinux has many parts to understand. This chapter discusses SELinux's
-important concepts and policy.
-</abstract>
- <include href="hb-selinux-overview.xml"/>
-</chapter>
-<chapter>
-<title>SELinux HOWTO</title>
+<title>Gentoo SELinux Installation / Conversion</title>
<abstract>
-This chapter deals with how to common operations in SELinux.
+To set up SELinux within Gentoo/Hardened, you first need to install Gentoo with
+the correct Hardened profile (or convert to the Hardened profile) and then
+update your system to become a SELinux-managed system. This chapter will guide
+you through this process.
</abstract>
- <include href="hb-selinux-howto.xml"/>
+ <include href="hb-using-install.xml"/>
</chapter>
+
<chapter>
-<title>SELinux FAQ</title>
+<title>SELinux Commands</title>
<abstract>
-This chapter deals with frequently asked questions in SELinux.
+Before we start with SELinux, we first take a step back and get to know a few
+commands. As we are currently running a SELinux enabled system (but in
+permissive mode) we can now get acquainted with the various SELinux-specific
+commands.
</abstract>
- <include href="hb-selinux-faq.xml"/>
+ <include href="hb-using-commands.xml"/>
</chapter>
+
<chapter>
-<title>SELinux Management Infrastructure</title>
+<title>Running in Permissive Mode</title>
<abstract>
-The chapter deals with managing SELinux using the management infrastructure.
+Once SELinux is active, we first start by running the system in permissive mode.
+In this chapter, we tell you how to get acquainted with SELinux more in-depth
+with live command information, but without interfering with the standard access
+controls (i.e. in permissive mode).
</abstract>
- <include href="hb-selinux-libsemanage.xml"/>
+ <include href="hb-using-permissive.xml"/>
</chapter>
+
<chapter>
-<title>Local Policy Modules</title>
+<title>Switching to Enforcing Mode</title>
<abstract>
-The chapter deals with adding rules and new modules to your policy.
+Once you believe that the system can be ran in enforcing mode, we switch the
+system to verify if this is true. Once verified, the next step is to (re)boot in
+enforcing mode. Finally, if we are confident that the enforcing is working
+properly and that the system is still doing its job correctly, we fix the
+enforcing mode so that it cannot be disabled anymore.
</abstract>
- <include href="hb-selinux-localmod.xml"/>
+ <include href="hb-using-enforcing.xml"/>
</chapter>
+
<chapter>
-<title>SELinux Reference Materials</title>
+<title>Adding SELinux Policy Modules</title>
<abstract>
-This has a list of external references on SELinux.
+Far from all packages where SELinux policy modules are available for have a
+corresponding package in Gentoo/Hardened. In this chapter, we help you to add
+more modules yourself or create your own modules for those packages that have no
+SELinux policies yet.
</abstract>
- <include href="hb-selinux-references.xml"/>
+ <include href="hb-using-policymodules.xml"/>
</chapter>
</part>
<part>
-<title>Troubleshooting SELinux</title>
+<title>Appendices</title>
<abstract>
-When encountering problems on a machine, SELinux can add extra difficulty
-in fixing the problem. This chapter walks through fixing common problems.
+Additional resources and referenced materials within this book are mentioned in
+this appendix.
</abstract>
+
<chapter>
-<title>Policy Not Loaded on Boot</title>
-<abstract>
-This chapter deals with the problem of the policy not being loaded on boot.
-</abstract>
- <include href="hb-selinux-initpol.xml"/>
-</chapter>
-<chapter>
-<title>Trouble Logging in Locally</title>
+<title>Troubleshooting SELinux</title>
<abstract>
-This chapter deals with problems logging in locally at the console.
+Everything made by a human can and will fail. In this chapter we will try to
+keep track of all potential issues you might come across and how to resolve
+them.
</abstract>
- <include href="hb-selinux-loglocal.xml"/>
+ <include href="hb-appendix-troubleshoot.xml"/>
</chapter>
+
<chapter>
-<title>Trouble Logging in Remotely</title>
+<title>SELinux Reference Material</title>
<abstract>
-This chapter deals with problems logging in remotely by ssh.
+This Gentoo Hardened SELinux handbook gives a first introduction to SELinux and
+how it is integrated in Gentoo Hardened. But more seasoned administrators will
+most definitely want to read up on the more advanced uses (and managerial
+challenges) of SELinux - which we definitely recommend. A non-exhaustive list is
+compiled in this chapter.
</abstract>
- <include href="hb-selinux-logremote.xml"/>
+ <include href="hb-appendix-reference.xml" />
</chapter>
</part>
1.1 xml/htdocs/proj/en/hardened/selinux/hb-appendix-reference.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-appendix-reference.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-appendix-reference.xml?rev=1.1&content-type=text/plain
Index: hb-appendix-reference.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-appendix-reference.xml,v 1.1 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
<version>1.3</version>
<date>2011-01-07</date>
<section>
<title>Background</title>
<subsection>
<title>Introduction to SELinux</title>
<body>
<ul>
<li>
<uri link="http://www.nsa.gov/research/_files/selinux/papers/inevit-abs.shtml">The Inevitability of Failure:
The Flawed Assumption of Security in Modern Computing Environments</uri>
explains the need for mandatory access controls.
</li>
<li>
<uri link="http://www.nsa.gov/research/_files/selinux/papers/flask-abs.shtml">The Flask Security Architecture:
System Support for Diverse Security Policies</uri>
explains the security architecture of Flask, the architecture used by SELinux.
</li>
<li>
<uri link="http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml">Implementing SELinux as a Linux Security Module</uri>
has specifics about SELinux access checks in the kernel.
</li>
</ul>
</body>
</subsection>
</section>
<section>
<title>SELinux Policy</title>
<subsection>
<title>Policy Related References</title>
<body>
<ul>
<li>
<uri link="http://www.nsa.gov/research/_files/selinux/papers/policy2-abs.shtml">Configuring the SELinux Policy</uri>
</li>
<li>
<uri link="http://oss.tresys.com/projects/refpolicy">SELinux Reference Policy</uri>
</li>
<li>
SELinux <uri link="http://www.selinuxproject.org/page/ObjectClassesPerms">Object Classes and Permissions</uri> Overview
</li>
</ul>
</body>
</subsection>
</section>
<section>
<title>Books</title>
<subsection>
<title>Paper Books</title>
<body>
<ul>
<li>
<c>SELinux by Example: Using Security Enhanced Linux</c>, Frank Mayer,
Karl MacMillan, and David Caplan, Prentice Hall, 2006; ISBN 0131963694
</li>
<li>
<c>SELinux: NSA's Open Source Security Enhanced Linux</c>, Bill McCarty,
O'Reilly Media, 2004; ISBN 0596007167
</li>
</ul>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/en/hardened/selinux/hb-appendix-troubleshoot.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-appendix-troubleshoot.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-appendix-troubleshoot.xml?rev=1.1&content-type=text/plain
Index: hb-appendix-troubleshoot.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-appendix-troubleshoot.xml,v 1.1 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
<version>0</version>
<date>2011-02-24</date>
<section>
<title>Unable To Load SELinux Policy</title>
<subsection>
<title>Problem Description</title>
<body>
<p>
If you notice that SELinux is not functioning at all, a quick run of
<c>sestatus</c> should give you closure if SELinux is enabled and loaded or not.
If you get the following output, no SELinux policy is loaded:
</p>
<pre caption="sestatus output">
SELinux status: disabled
</pre>
<p>
If this is the case, read on in this section to find out how to troubleshoot and
resolve this.
</p>
</body>
</subsection>
<subsection>
<title>No Policy Installed</title>
<body>
<p>
One potential reason would be that there is no policy to load to begin with.
Take a look inside <path>/usr/share/selinux/strict</path> or
<path>/usr/share/selinux/targeted</path> (depending on your configuration) and
look for a file called <path>base.pp</path>. If no such file exists, you will
need to install the base policy. This policy is offered by the
<path>sec-policy/selinux-base-policy</path> package, but it is better to read up
on the chapter regarding <uri link="?part=2&chap=1">Gentoo SELinux
Installation / Conversion</uri> as more important changes might be missing.
</p>
</body>
</subsection>
<subsection>
<title>Policy Not Loaded</title>
<body>
<p>
If the <path>base.pp</path> file exists in
<path>/usr/share/selinux/strict</path> (or <path>targeted/</path>), take a look
inside <path>/etc/selinux/strict/policy</path>. This location too should contain
a <path>base.pp</path> policy module (when a SELinux policy is loaded, it is
copied from the first location to the second).
</p>
<p>
If no <path>base.pp</path> file exists, install and load the policy:
</p>
<pre caption="Installing the base policy">
~# <i>semodule -n -B</i>
</pre>
<p>
This is a one-time operation - once installed and loaded, it will be reloaded
upon every reboot.
</p>
</body>
</subsection>
<subsection>
<title>Init Can Not Load the SELinux Policy</title>
<body>
<p>
During system boot, the <c>init</c> process is responsible for loading and
interacting with the SELinux policy in memory. If <c>init</c> does not support
SELinux, you will get no SELinux support in your environment.
</p>
<p>
To verify if <c>init</c> supports SELinux, we need to check if it uses the
<path>libselinux.so</path> shared object:
</p>
<pre caption="Checking if init supports SELinux">
~# <i>ldd /sbin/init</i>
linux-vdso.so.1 => (0x00006ace30e84000)
<comment>( You should see something similar to the following line: )</comment>
libselinux.so.1 => /lib/libselinux.so.1 (0x00006ace30a46000)
libc.so.6 => /lib/libc.so.6 (0x00006ace306e9000)
libdl.so.2 => /lib/libdl.so.2 (0x00006ace304e5000)
/lib64/ld-linux-x86-64.so.2 (0x00006ace30c68000)
</pre>
<p>
If this is not the case, make sure that <c>emerge --info</c> shows that the
selinux USE flag is in place, and reinstall <path>sys-apps/sysvinit</path>. If
the selinux USE flag is not in place, check your Gentoo profile and make sure it
points to a <path>selinux/v2refpolicy/...</path> profile.
</p>
</body>
</subsection>
</section>
<section>
<title>Unable to Log On</title>
<subsection>
<title>Problem Description</title>
<body>
<p>
If you are unable to log on in a particular situation (remote, local, as root,
as regular user, ...) there are a few possible problems which you might have
hit. However, to resolve them you'll need to be able to log on to the system as
<e>sysadm_r</e> in one way or the other.
</p>
<p>
If you can not log in as a <e>sysadm_r</e> user, disable SELinux (boot with
<c>enforcing=0</c>) so that no SELinux enforcements are made. Changes that you
make in permissive mode are equally effective as in enforcing mode.
</p>
</body>
</subsection>
<subsection>
<title>Incorrect Context</title>
<body>
<p>
In the majority of cases will you find that a security context is incorrect. Run
<c>sestatus -v</c> and compare the <e>Process contexts</e> or <e>File
contexts</e> that you see in the output with the next table.
</p>
<table>
<tr>
<th>Process</th>
<th>Context</th>
<th>If wrong context...</th>
</tr>
<tr>
<ti>Init context</ti>
<ti>system_u:system_r:init_t</ti>
<ti>
First, verify that init itself is correclty labeled. Check the output of
the previously run <c>sestatus -v</c> command for the
<path>/sbin/init</path> file and make sure that it is set to
system_u:object_r:init_exec_t. If that is not the case, relabel
<path>sys-apps/sysvinit</path> using <c>rlpkg sysvinit</c>. Also make the
same checks as in the <uri link="#doc_chap1">Unable To Load SELinux
Policy</uri> section. Reboot your system and retry.
</ti>
</tr>
<tr>
<ti>agetty context</ti>
<ti>system_u:system_r:getty_t</ti>
<ti>
Make sure that the <path>/sbin/agetty</path> binary is labeled
system_u:object_r:getty_exec_t. If not, relabel the
<path>sys-apps/util-linux</path> package using <c>rlpkg util-linux</c>. Then
restart all the agetty processes using <c>pkill agetty</c> (they will
automatically respawn).
</ti>
</tr>
<tr>
<th>File</th>
<th>Context</th>
<th>If wrong context...</th>
</tr>
<tr>
<ti>/bin/login</ti>
<ti>system_u:object_r:login_exec_t</ti>
<ti>
The login binary is part of <path>sys-apps/shadow</path>. Run <c>rlpkg
shadow</c> to relabel the files of that package and retry logging in.
</ti>
</tr>
<tr>
<ti>/sbin/unix_chkpwd</ti>
<ti>system_u:object_r:chkpwd_exec_t</ti>
<ti>
This binary is part of the <path>sys-libs/pam</path> package and is used by
SSH when it is configured to use PAM for user authentication. Relabel the
package using <c>rlpkg pam</c> and retry logging in.
</ti>
</tr>
<tr>
<ti>/etc/passwd</ti>
<ti>system_u:object_r:etc_t</ti>
<ti rowspan="2">
The <path>/etc/passwd</path> and <path>/etc/shadow</path> must be labeled
correctly, otherwise PAM will not be able to authenticate any user. Relabel
the files through <c>restorecon /etc/passwd /etc/shadow</c> and retry
logging in.
</ti>
</tr>
<tr>
<ti>/etc/shadow</ti>
<ti>system_u:object_r:shadow_t</ti>
</tr>
<tr>
<ti>/bin/bash</ti>
<ti>system_u:object_r:shell_exec_t</ti>
<ti>
The users' shell (in this case, <c>bash</c>) must be labeled correctly so
the user can transition into the user domain when logging in. To do so,
relabel the <path>app-shells/bash</path> package using <c>rlpkg bash</c>.
Then, try logging in again.
</ti>
</tr>
</table>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/en/hardened/selinux/hb-intro-concepts.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-concepts.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-concepts.xml?rev=1.1&content-type=text/plain
Index: hb-intro-concepts.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-concepts.xml,v 1.1 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
<version>2</version>
<date>2011-01-10</date>
<section>
<title>Introduction</title>
<subsection>
<title>SELinux Concepts</title>
<body>
<p>
Since SELinux is a MAC system, you should already figure out that managing
SELinux-based permissions and rights might be a bit more challenging than
managing the discretionary access control rights generally used on a Linux
system. What is more is that SELinux works <b>on top of</b> the DAC system
everybody is used from Linux. As a system administrator, you will need to be
acquainted with some of the concepts and structures that SELinux has put in
place in order to manage the access on the SELinux system.
</p>
<p>
Describing those concepts is the purpose of this particular chapter. We will
give examples on the various concepts from a SELinux enabled Gentoo Hardened
system. However, do not fear if the use of particular commands is not explained
sufficiently. They are currently meant as examples (their output is more
important) and will be discussed further in this document.
</p>
</body>
</subsection>
</section>
<section>
<title>Security Contexts</title>
<subsection>
<title>Users, Roles and Domains</title>
<body>
<p>
One of the first concepts you will need to be acquainted with is the concept of
a <e>security context</e>. This is a state given to a resource that uniquely
identifies which grants (permissions) are applicable to the resource. This
context is extremely important for SELinux as it is the definition on which it
bases its permissions (grants or denials). When a resource has no security
context assigned, SELinux will try to give it a default security context which -
in the spirit of lowest privilege - has little permissions to perform any actions.
</p>
<p>
Within SELinux, such a security context is displayed using three definitions:
</p>
<dl>
<dt>user</dt>
<dd>
This is the <e>SELinux user</e> (which is not the same as the Linux/Unix
technical user) assigned to the resource
</dd>
<dt>role</dt>
<dd>
This is the SELinux role in which the resource currently works
</dd>
<dt>type</dt>
<dd>
This is the type assigned to the resource and is the key to SELinux'
enforcement rules
</dd>
</dl>
<p>
More information on these particular definitions is given throughout the
remainder of this chapter.
</p>
<p>
As an example let's take a look at the security context of a logged on user:
</p>
<pre caption="Getting the security context of a logged on user">
~$ <i>id -Z</i>
staff_u:staff_r:staff_t
</pre>
<p>
In this case, the user is identified as the SELinux user <e>staff_u</e>,
currently in the <e>staff_r</e> role and assigned to the <e>staff_t</e>
type. The actions the user is allowed to do are based upon this security
context.
</p>
</body>
</subsection>
<subsection>
<title>Access Control Policy</title>
<body>
<p>
As mentioned before, these security contexts are used as the base for the
permission rules. What SELinux does is check the security context of the source
(for instance a process) and the destination (for instance a file that that
process wants to read). It then checks if the requested operation (read) is
allowed between those two contexts. Keep in mind though that SELinux works on
top of the standard permission system used by Linux. If a process is not able to
read a file to begin with, SELinux is not even consulted.
</p>
<p>
Now, where the security context defines the state of a resource, we have not
spoken about the resources themselves. Within SELinux, the resource types are
defined as <e>object classes</e>. Common examples are <e>file</e> or <e>dir</e>,
but SELinux also manages classes such as <e>filesystem</e>, <e>tcp_socket</e>,
<e>process</e>, <e>sem</e> (semaphores) and more.
</p>
<p>
On each object class, a set of <e>permissions</e> is declared which are possible
against a resource within this object class. For instance, the <e>process</e>
object class supports at least the following permissions:
</p>
<pre caption="Supported permissions against a 'process' resource">
fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession setpgid getpgid getcap setcap share getattr setexec setfscreate
setrlimit noatsecure siginh rlimitinh dyntransition setcurrent execmem execstack
execheap setkeycreate setsockcreate
</pre>
<p>
Let's take a look at a small example to explain the permission rules and how
SELinux uses them. The example user is in the <e>staff_u:staff_r:staff_t</e>
context and wants to write to its own home directory. As we can expect, this
should be allowed. Don't worry about the commands here, we'll discuss them more
properly further in this document.
</p>
<pre caption="Seeing if a user can write to its own home directory">
<comment>(Show the security context for the users' home directory)</comment>
~$ <i>ls -dZ ${HOME}</i>
staff_u:object_r:user_home_dir_t /home/swift
<comment>(Find the allow-rule which allows the staff_t type to write into a
directory with the user_home_dir_t type)</comment>
~$ <i>sesearch -s staff_t -t user_home_dir_t -c dir -p write -A</i>
Found 1 semantic av rules:
allow staff_t user_home_dir_t : dir { ioctl read write create ... };
</pre>
<p>
As expected, the security context of the user (to be more specific, the domain
in which it resides) has write access to the domain of the target's directories.
The notion of <e>domain</e> is frequently used in SELinux documentation and
refers to the type assigned to a process. BTW, as files do not have roles,
they are given the default <e>object_r</e> role by SELinux.
</p>
<p>
Now take a look at the following example. Our user, who is inside the portage
group, wants to write to the <path>/var/tmp/portage</path> directory:
</p>
<pre caption="Seeing if a user can write to the /var/tmp/portage directory">
~$ <i>id -a</i>
uid=1001(swift) gid=100(users) groups=100(users),...,250(portage),...
~$ <i>ls -ldZ /var/tmp/portage</i>
drwxrwxr-x. 3 portage portage system_u:object_r:portage_tmp_t 4096 Dec 6 21:08 /var/tmp/portage
</pre>
<p>
From the standard Linux permissions, the user has write access. But does SELinux
also grant it?
</p>
<pre caption="Trying to write into /var/tmp/portage">
~$ <i>sesearch -s staff_t -t portage_tmp_t -c dir -p write -A</i>
~$
<comment>(Notice that there is no output given here)</comment>
~$ <i>touch /var/tmp/portage/foo</i>
touch: cannot touch '/var/tmp/portage/foo': Permission denied
</pre>
<p>
As SELinux could not find a rule that allows the staff_t domain to write to any
directory labeled with the portage_tmp_t type, the permission was denied.
</p>
</body>
</subsection>
</section>
<section>
<title>Type Enforcements / Domain Types</title>
<subsection>
<title>Types and Domains</title>
<body>
<p>
To explain how the permission rules work and how this is enforced through the
security contexts, let's start from the last definition in the context (the
<e>type</e>) and work our way forward through the roles and users.
</p>
<ul>
<li>
A <e>SELinux type</e> is a particular label assigned to a resource. The
<c>passwd</c> command for instance is labeled with the passwd_exec_t type.
</li>
<li>
A <e>SELinux domain</e> is the security state of a process and identifies the rights
and permissions it has. It is most often referred to by its type declaration.
For instance, for a running <c>passwd</c> command, its domain is passwd_t.
</li>
</ul>
<p>
The rules that identify the allowed actions for a domain have the following
syntax:
</p>
<pre caption="Standard SELinux policy rules">
allow <src_domain> <dst_type> : <class> { permission [ permission [ ... ] ] } ;
</pre>
<p>
An example for the <e>passwd_t</e> domain would be the permissions granted
between the <e>passwd_t</e> domain and the <e>shadow_t</e> type (used by the
<path>/etc/shadow</path> file).
</p>
<pre caption="Grants between passwd_t and shadow_t">
allow passwd_t shadow_t : file { ioctl read write create ... } ;
</pre>
<p>
This permission syntax is very powerful, but also difficult. To have a secure
system where normal behavior is allowed, you need to seriously fine-tune these
rules for each and every application (and thus domain) that your system wants to
host. Giving too broad permissions to a domain on a particular type might result
in unauthorized activity being granted. Giving too few permissions might result
in loss of efficiency or even effectiveness.
</p>
<p>
To support easier grant rules, SELinux allows grouping of types using type
attributes. For instance, the attribute <e>exec_type</e> bundles all types
that are assigned to executable files (such as <e>bin_t</e>, <e>ssh_exec_t</e>,
...), whereas the <e>file_type</e> attribute bundles all types that are
assigned to regular files. Although this can simplify rule management, it makes
it easier to grant too many permissions.
</p>
</body>
</subsection>
<subsection>
<title>Domain Transitions</title>
<body>
<p>
So far for types, domain definitions and their permissions. We have stated before
that permissions are based on the domain in which a process resides. But how
does a process become part of the domain? You might think that this happens by
default (starting the <c>passwd</c> command would automatically bring the
process in the <e>passwd_t</e> domain), but this is in fact a combination of
three specific privileges that need to be granted:
</p>
<ol>
<li>
The current domain must be allowed to transition to a domain
</li>
<li>
The target domain should have an <e>entry point</e>, which is an executable
that is allowed to start in the domain
</li>
<li>
The source domain should have <e>execute</e> rights on (the domain of) that
executable
</li>
</ol>
<impo>
Not being allowed to transition does not mean that you cannot
execute the binary. The binary can still be executed, but will not run inside
the target domain. Instead, it will inherit the domain of the executor and hence
the rights and permissions of this domain.
</impo>
<p>
Through these rules, the security administrator of a system can more
specifically control who and under which conditions particular actions can be
taken.
</p>
</body>
</subsection>
</section>
<section>
<title>Roles and Rights</title>
<subsection>
<title>The Role of a Role</title>
<body>
<p>
The previously discussed domains and domain rules is quite powerful. However,
this is not where SELinux stops. After all, you want to be able to deny access
towards particular domains from unauthorized users. One requirement is of course
not to allow transitions from the user domain to that restricted domain, but how
can you enforce one set of users to be allowed and another to be denied?
</p>
<p>
Enter the roles. By using roles, you can tell SELinux which domains are allowed
for a role and which aren't. An example would be the <e>ifconfig_t</e> domain.
This domain has the rights to change the networking interface definitions - not
something you want to allow your users. And in fact, if you would verify,
SELinux does not allow the user role <e>user_r</e> to be assigned with the
<e>ifconfig_t</e> domain.
</p>
<pre caption="ifconfig_t domain and user_r versus sysadm_r">
~$ <i>seinfo -ruser_r -x</i>
user_r
Dominated Roles:
user_r
Types:
...
~$ <i>seinfo -rsysadm_r -x</i>
sysadm_r
Dominated Roles:
sysadm_r
Types:
...
ifconfig_t
...
</pre>
<impo>
Again, not being able to be associated with a domain does not mean that the
<e>user_r</e> role cannot <e>execute</e> the <c>ifconfig</c> binary. It can, but
it will execute the binary within its own domain (<e>user_t</e>) and as such
will not have the rights to manipulate the networking interface (but will still
be able to read the interface information albeit with limited output).
</impo>
<p>
Roles are often used in access control systems to group permissions to a single
functional set (the role) which can then be assigned to individuals (accounts).
For instance, such access control systems create roles for accountants,
operators, managers, ... and grant the appropriate privileges to these roles.
Then, their users are assigned one (or sometimes multiple) roles and the users
inherit the permissions assigned to these roles.
</p>
<p>
With SELinux, the idea remains the same (use roles to functionally differentiate
privileges) but is implemented differently: roles are assigned target domains
in which a role is allowed to "be in". The permissions remain assigned to the
domains.
</p>
</body>
</subsection>
<subsection>
<title>Role Transitions</title>
<body>
<p>
Users (and processes) have the ability to switch roles. This is allowed by
SELinux, but of course only when the switch itself is granted. By default,
the SELinux policy used by Gentoo Hardened offers five roles on a SELinux
system:
</p>
<dl>
<dt>object_r</dt>
<dd>
The <e>object_r</e> role is the only role by default available through
SELinux. It is usually only assigned to resources where roles have no
benefit or value (such as files and directories).
</dd>
<dt>system_r</dt>
<dd>
The <e>system_r</e> role is used for highly privileged system services.
The <e>system_r</e> role is allowed to switch to any other "default" role.
No role exception <e>sysadm_r</e> can switch to the <e>system_r</e> role.
</dd>
<dt>sysadm_r</dt>
<dd>
The <e>sysadm_r</e> role is used for system administration activities. The
<e>sysadm_r</e> role is allowed to switch to any other "default" role. Only
the <e>system_r</e> and <e>staff_r</e> roles are allowed to switch to the
<e>sysadm_r</e> role.
</dd>
<dt>staff_r</dt>
<dd>
The <e>staff_r</e> role is used for system operators who might have the
rights to perform system administration tasks. The <e>staff_r</e> role is
only allowed to switch to the <e>sysadm_r</e> role. Only <e>sysadm_r</e> and
<e>system_r</e> can switch to the <e>staff_r</e> role.
</dd>
<dt>user_r</dt>
<dd>
The <e>user_r</e> role is used for standard, unprivileged users. It is not
allowed to transition towards any other role; only <e>sysadm_r</e> and
<e>system_r</e> roles are allowed to switch to the <e>user_r</e> role.
</dd>
</dl>
<note>
A "default" role is any of <e>user_r</e>, <e>staff_r</e>, <e>sysadm_r</e> or
<e>system_r</e>. If you create additional roles yourself, they are not part of
the "default" roles.
</note>
<p>
Using these definitions, a user inside the <e>user_r</e> role will never be able
to execute <c>ifconfig</c> within the <e>ifconfig_t</e> domain. The use of the
word <e>never</e> here is important: not even if the user is able to become
root using <c>sudo</c> or any other command will he be able to run the
<c>ifconfig</c> command in the <e>ifconfig_t</e> domain because, even after
running <c>sudo</c>, he is still inside the <e>user_r</e> role.
</p>
</body>
</subsection>
<subsection>
<title>SELinux Users</title>
<body>
<p>
A SELinux user is not the same as the Linux user. Whereas standard Linux user
accounts can be switched using commands such as <c>su</c> or <c>sudo</c>, a
SELinux user can not be changed. Even when you successfully execute <c>sudo</c>,
your SELinux user will remain the same.
</p>
<p>
When you look at a SELinux powered system, you might notice that that system
doesn't use many SELinux users. For instance, Gentoo Hardened's default setup
defines the users <e>root</e>, <e>user_u</e>, <e>staff_u</e>, <e>sysadm_u</e> and
<e>system_u</e> and some systems never introduce any other SELinux user. But if
that is the case, is the above advantage of SELinux users (once a user is logged
on, he cannot change his SELinux user) the only one?
</p>
<p>
Well, no. SELinux users are also used to categorize accounts which have the
permission to use a particular role.
</p>
<pre caption="SELinux users and their associated roles">
~# <i>semanage user -l</i>
SELinux User SELinux Roles
root staff_r sysadm_r
staff_u staff_r sysadm_r
sysadm_u sysadm_r
system_u system_r
user_u user_r
</pre>
<p>
Standard Linux users are mapped to these SELinux users:
</p>
<pre caption="Linux users and their SELinux user mappings">
~# <i>semanage login -l</i>
Login Name SELinux User
__default__ user_u
root root
swift staff_u
</pre>
<p>
In this example, only logins of the Linux user <e>swift</e> (through
<e>staff_u</e>) and <e>root</e> (through the <e>root</e> SELinux user)
will be able to eventually run inside the <e>sysadm_r</e> role. All other
Linux accounts will be by default mapped to the <e>user_u</e> user (and
this <e>user_r</e> role).
</p>
<p>
This is <e>only</e> applicable for interactive logins. Processes that are
launched through an init script or otherwise do not automatically become part of
the SELinux user <e>user_u</e>: depending on the security context of whatever
process is starting them, they can become anything. Of course, if the security
context of the process that is starting them is <e>user_u:user_r:user_t</e> then
they will not be able to transform into anything other than
<e>user_u:user_r:*</e> with <e>*</e> a domain supported by the <e>user_r</e>
role.
</p>
<p>
SELinux users are also used to implement <e>User Based Access Control</e> or
<e>UBAC</e>. This SELinux functionality allows for domains to be SELinux user
aware: a process running in the context of a particular SELinux user can then -
for instance - only work with files of the same SELinux user. This offers a
finer grained access method, because that process might run within a domain
which has write access to the domain of the file, but can still not write to the
file because the SELinux users' differ.
</p>
</body>
</subsection>
</section>
<section>
<title>Multi Level Security / Multi Category Security</title>
<subsection>
<title>Introduction</title>
<body>
<p>
Next to the type enforcement feature, SELinux also offers MLS and MCS support.
This allows administrators to define a hierarchical confidentiality policy.
For instance, you can ensure that a user or process within a certain
security domain and level can write to files with the same level (or higher), or
read files with the same level (or lower), but not write files to a lower level.
This allows administrators to implement some sort of
public/internal/confidential/strictly confidential hierarchical security level
for files.
</p>
<p>
Although implementation of MLS is possible with the type enforcement rules we
have previously explained, it would lead to an unmanageable collection of types
and permissions. The MLS implementation simplifies this.
</p>
<p>
At this moment, the Gentoo Hardened SELinux handbook does not cover MLS/MCS, but
this might (and probably will) change in the future.
</p>
</body>
</subsection>
</section>
<section>
<title>Next Steps</title>
<subsection>
<title>What Next</title>
<body>
<p>
It might be difficult to understand now, but the concepts are important because,
if something fails on your system when SELinux is enabled, but it doesn't fail
when SELinux is disabled, then you will need to dive into the security contexts,
rules, types and domain transitions to find out why.
</p>
<p>
The next chapter in line will discuss how distributions such as Gentoo Hardened
manage the various permission rules and how they use a macro language to
generate the permissions instead of creating the allow-rules one by one.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/en/hardened/selinux/hb-intro-enhancingsecurity.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-enhancingsecurity.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-enhancingsecurity.xml?rev=1.1&content-type=text/plain
Index: hb-intro-enhancingsecurity.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-enhancingsecurity.xml,v 1.1 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
<version>1</version>
<date>2011-01-10</date>
<section>
<title>Introduction</title>
<subsection>
<title>A Warm Welcome</title>
<body>
<p>
Welcome to the Gentoo SELinux handbook. In this resource, we will bring you up
to speed with Gentoo Hardened's implementation of SELinux and the policies
involved. Part of this exercise is to help you understand why SELinux was
brought to life and which concept is behind the development of the SELinux
patches. We will cover the SELinux concepts, the reference policy that Gentoo
Hardened uses and elaborate on how to work with the various SELinux tools.
</p>
<p>
The purpose of this book is not to explain SELinux itself in great detail. There
are many references available on the Internet and in the better bookstores that
help you with the SELinux topic. Instead, we will focus on SELinux integration
within Gentoo Hardened. Of course, we will give a quick introduction to SELinux
to allow you to understand how it works, what it is and help you identify which
actions you will need to take in order to properly secure your system using the
SELinux tools.
</p>
</body>
</subsection>
</section>
<section>
<title>Securing Linux</title>
<subsection>
<title>Security In General</title>
<body>
<p>
Security is often seen as a vague concept. What is security in general? How do
you measure security? What is the benefit and how do you make sure you do not
put too much effort in securing your system?
</p>
<p>
Well, security zealots will tell you that there is no such thing as too much
security. If properly implemented, security does not restrict functionality or
performance. It does not give you too much overhead in order to do your tasks.
But implementing security properly is a different and time-consuming task. That
is also why you often hear that security is as good as its administrator.
</p>
<p>
So, how can you look at security? A good practice on security is to define your
security goals. List what you want to achieve and why. By tracking the threats
that you want to minimize, you build up a security model that is appropriate for
your environment. Such threats can be very broad, such as "Ensure no-one is able
to work around our security measures".
</p>
<p>
In case of a Linux system powered with SELinux, this would at least mean that
you want to protect critical system files, such as kernel image(s) and boot
loader configuration, passwords and the SELinux policy binary itself from being
written by anyone or anything except trusted processes.
</p>
</body>
</subsection>
<!-- Suggestion to remove from guide, more interesting for a generic security
document?
<subsection>
<title>Security on Operating System Level</title>
<body>
<p>
So far for the high-level and theoretic explanation on security. What about
operating system security?
</p>
<p>
On the Internet, you will find a multitude of documents helping you secure your
system. Some of these documents are procedure-driven (execute this, delete that,
change permissions of this file and that file) and are often found as security
best practices for operating systems or distributions. You can find such
documents on the project sites themselves (such as the <uri
link="/doc/en/security/security-handbook.xml">Gentoo Security Handbook</uri>) or
on specialized sites of organizations that keep track of secure configuration
baselines in general (such as <uri
link="http://www.cisecurity.org">CISecurity</uri>'s benchmark documents).
Others are higher-level descriptions (often called frameworks) that help you
focus on the various fields in which security plays a role.
</p>
<p>
A simple example of such higher-level descriptions can be seen in the CoBIT
framework, which has a process called <e>Ensure Systems Security</e> which
defines (at least) the following control objectives:
</p>
<ol>
<li>Manage Security Measures</li>
<li>Identification, Authentication and Access</li>
<li>Security of Online Access to Data</li>
<li>User Account Management</li>
<li>Management Review of User Accounts</li>
<li>User Control of User Accounts</li>
<li>Security Surveillance</li>
<li>Data Classification</li>
<li>Central Identification and Access Rights Management</li>
<li>Violation and Security Activity Reports</li>
<li>Incident Handling</li>
<li>Re-accreditation</li>
<li>Counterparty Trust</li>
<li>Transaction Authorization</li>
<li>Non-repudiation</li>
<li>Trusted Path</li>
<li>Protection of Security Functions</li>
<li>Cryptographic Key Management</li>
<li>Malicious Software Preventions, Detection and Correction</li>
<li>Firewall Architectures and Connections with Public Networks</li>
<li>Protection of Electronic Value</li>
</ol>
<p>
If your head is not spinning yet, then I suggest to dive deeper into these
subjects. However, for this handbook, we'll leave it at this and focus on those
topics that are relevant for further SELinux discussions.
</p>
</body>
</subsection>
<subsection>
<title>Operating System Security Best Practices</title>
<body>
<p>
To properly secure any operating system, there are a few best practices that you
might need to keep in mind. They do not cover the full spectrum of configuration
directives or requirements, but if you do not implement those properly, you risk
that the threats facing your system become reality faster.
</p>
<dl>
<dt>Only run necessary services</dt>
<dd>
Only run services (scripts, daemons, jobs, servers ...) of which you know
you need them. Regularly verify your system runtime behavior to see if no
services are running that you don't need. The more services that run, the
more <e>access vectors</e> intruders or malicious people have towards your
system.
</dd>
<dt>Update your system regularly</dt>
<dd>
Updating your system will resolve all potential vulnerabilities of software
you have if they were known by the developers and fixed in later versions.
Some distributions, including Gentoo, allow you to pull in only
security-related updates so that your upgrade cycle is not too time and
resource consuming. See <c>glsa-check</c> for more information on how to do
this with Gentoo.
</dd>
<dt>Do not use privileged accounts</dt>
<dd>
For each task you execute on a system, make sure that that task has the
least amount of privileges needed to get to its goal. Only a few services
will require root privileges (Unix/Linux' highest privileged account), but
other accounts might also be seen as privileged (such as accounts that have
password-less <c>sudo</c> rights, or accounts that are in the <e>wheel</e>
group. The same is true for your regular day-to-day tasks.
</dd>
<dt>Implement a good password policy</dt>
<dd>
Make sure that your passwords are not easy to guess or to brute-force. If
your system uses passwords for authentication and the password is
compromised, security is completely compromised as well as, as far as the
system knows, the malicious user that is using your password is you.
</dd>
<dt>Configure your services properly</dt>
<dd>
Do not trust services to come with a good, default configuration. Most
default configurations are so that the majority of users can use the service
(feature-wise), which might not always be the proper configuration for you.
</dd>
<dt>Use proper permissions</dt>
<dd>
Make sure your files are properly protected permission-wise. Never use
world-readable files and only allow other accounts to read (or modify) your
file(s) if they need to. Use group-permissions wisely and often validate
group membership. If file systems can be used in a read-only fashion, do so.
If you do not need to access a particular file system by default, don't
mount it.
</dd>
</dl>
<p>
This is just a subset of best practices. One of the aspects within an operating
system setup is the method of <e>accessing</e> the system, services or data.
Implementing a good access control is mandatory from a systems' security
point-of-view.
</p>
</body>
</subsection>
-->
<subsection>
<title>Access Control</title>
<body>
<p>
A decent access control system (or group of systems) ensures that only
authorized individuals or processes are granted access to the resources they are
tring to work with.
</p>
<p>
Before one can implement an access control system, you first need to have proper
authentication in place. If your authentication schemes are flawed, your access
control system might not be able to differentiate legitimate users from
malicious ones.
</p>
<p>
Authenticating users within Linux is often done through PAM (<e>Pluggable
Authentication Modules</e>), a powerful mechanism to integrate multiple
low-level authentication schemes into a high-level interface.
</p>
<p>
Authorizing access to resources however is often done through a simple
permission scheme. Most resources are not hidden by default, although
patches and updates exist (such as those offered by Gentoo Hardened's
kernel sources with grSecurity patches which includes support for this
kind of measures). File-system wise, you can hide the existence of files
by ensuring the directory in which the file resides is not readable nor
"executable" by unauthorized accounts.
</p>
<p>
This default permission scheme has major drawbacks. It does not allow you to
define very flexible authorizations (it only allows permissions on three levels:
owner, group-owner and everybody else) and is limited to read/write/execute
rights (although a few additional attributes are supported nowadays as well).
</p>
<p>
Another drawback is that the permission scheme is <e>discretionary</e>, meaning
that users and processes are able to change the security policy in place.
</p>
<p>
For the majority of uses, this permission scheme is sufficient and has proven to
offer a decent method for managing access authorizations. But the drawbacks have
shown to be a major hole in the Linux' offering.
</p>
</body>
</subsection>
</section>
<section>
<title>Mandatory Access Control</title>
<subsection>
<title>Enter SELinux</title>
<body>
<p>
If the above mentioned discretionary access control, abbreviated to <e>DAC</e>,
is not sufficient (and if you are keen on security, you will not find it
sufficient), you need a <e>Mandatory</e> Access Control, or <e>MAC</e> system.
</p>
<p>
When using a MAC system, activities that a process wants to perform on another
resource need to be explicitly allowed. It offers a higher granularity on
permissions as well as resources. They often support not only files, but also
sockets, ports, memory segments, queues, processes, kernel services, system
calls, devices, file systems and more. The granularity of activities supported
is also quite large. For files, this can be append, create, execute, write,
link, ioctl, get- and setattr, read, rename, lock, ... whereas for sockets this
might be append, bind, connect, create, write, sendto, accept, ... Also, when
using a MAC system, no user or process can manipulate the security policy
itself: what the security administrator has defined cannot be overturned.
</p>
<p>
This is where SELinux comes to play. SELinux is a Linux kernel feature which
implements, amongst other things, a MAC system for controlling and governing
access to various resources. It uses a deny-by-default permission scheme, so any
access that a process wants to perform needs to be explicitly granted.
</p>
<p>
SELinux also allows you to put a finer-grained permission model <b>on top
of</b> the traditional DAC system (which is still in use when using SELinux
- in other words, if the traditional system does not allow certain activities,
it will not be allowed even if there are SELinux policies granting the
permission).
</p>
</body>
</subsection>
<subsection>
<title>What is SELinux</title>
<body>
<p>
To support this finer-grained permission model, you would think that changes
are needed to the Linux kernel. Yet thanks to the Linux kernel <e>LSM</e>
interface (<e>Linux Security Modules</e>), support for SELinux was easily added
and since the 2.6 kernel series, SELinux has been integrated in the mainstream
kernel release. But supporting SELinux and using SELinux are very different topics.
</p>
<p>
In order to properly identify resources, SELinux needs to assign labels to these
resources. When the resources are in-memory, this is mostly supported by the
Linux kernel itself, but for persistent resources such as files, these labels
need to be placed somewhere. SELinux has chosen to use a file's extended
attributes (which is stored on the file system itself). The advantage here is
that a label remains on the file even if the file is renamed. A disadvantage of
this approach is that the file system must support <e>extended attributes</e>,
which not all file systems do (or have activated).
</p>
<p>
SELinux also uses roles to govern resource access. A user that does not have
access to the system administration role should never be allowed to execute any
system administration activities even if he is able to escalate its privileges
(say through a set-uid application). To support roles, SELinux requires changes
to the authentication services (PAM) and needs to store role definitions and
authorizations somewhere.
</p>
<p>
Next to the kernel support and labels assigned to the resources and support
within the authorization system, SELinux also requires particular tools to
support the SELinux features. Examples are administrative tools to view and
manipulate labels, privilege management tools (like <c>sudo</c>), system
services (like HAL or SysVInit) etc. This is reflected in a set of patches
against these (and more) tools which are not always part of the applications'
main source code.
</p>
</body>
</subsection>
<subsection>
<title>Gentoo Hardened and SELinux</title>
<body>
<p>
What Gentoo Hardened offers is SELinux integrated in the distribution. When you
select SELinux support, Gentoo Hardened will apply the necessary patches against
the applications and help you (re)label your files and other resources to become
SELinux-manageable. Gentoo Hardened also integrates SELinux support inside
Portage, allowing for newly installed files to be automatically labeled and to
use a SELinux-supporting sandbox environment for
safe package building.
</p>
<p>
Next to the pure technological support, we hope that you will also find the
necessary supporting documents, guides, experience and on-line support for using
SELinux within Gentoo. Never hesitate to come and say hi on the
<c>#gentoo-hardened</c> chat channel in the Freenode IRC network or on our
mailing lists.
</p>
<p>
If you believe that SELinux is the right thing for you and you want to try it
out using Gentoo Hardened, please read on. The next chapter will inform you how
SELinux security is "designed" and how it is conceptually structured. Further
chapters will then help you with the authorization language and the "base"
policies that most distributions start from, and finally help you install,
run and manage a SELinux hardened Gentoo system.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/en/hardened/selinux/hb-intro-referencepolicy.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-referencepolicy.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-referencepolicy.xml?rev=1.1&content-type=text/plain
Index: hb-intro-referencepolicy.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-referencepolicy.xml,v 1.1 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
<version>0</version>
<date>2010-12-01</date>
<section>
<title>About SELinux Policies</title>
<subsection>
<title>SELinux Policy Language</title>
<body>
<p>
As described previously, SELinux uses type enforcement to describe the state of
your system. This is done by giving each resource on your system (be it a
process, a network port, a file or directory) a specific type and describe the
rules how types can work with each other.
</p>
<p>
For instance, the allow-rule to allow all regular users (which are in the
user_t domain) to execute files with the bin_t label:
</p>
<pre caption="Allow rule to execute bin_t files">
allow user_t bin_t:file { read execute open };
</pre>
<p>
Other supported rules are
</p>
<ul>
<li>
<e>dontaudit</e> will disable the logging of the denial message(s)
</li>
<li>
<e>auditallow</e> will allow the access but will also log it (by default,
allowances are not logged)
</li>
<li>
<e>neverallow</e> forces that a certain allow rule cannot be granted. Even
though SELinux is a positive security model (white listing), sometimes
neverallow rules might be needed. But generally you will not often see them.
</li>
</ul>
<p>
As you can imagine, defining the rules for an entire system is very
resource-intensive if you want to do it right. It not only requires a deep
insight in how the system works, but also a lot of rule writing and testing. But
even more time consuming is that you will write the same rules over and over
again for different domains. To help developers with policy writing, a
<e>reference policy</e> has been brought to life with the following required
functionalities:
</p>
<ul>
<li>
development of SELinux policy rules should be centralized even for different
distributions
</li>
<li>
a macro language should be supported that makes it easier to write new
policies
</li>
<li>
the policies should be modular, allowing for additional rules to be added or
removed
</li>
</ul>
<p>
By centralizing the SELinux policy rule development, SELinux users will have the
same domain naming conventions as on other distributions. This makes debugging a
lot easier, documenting a lot less distribution-specific and makes it a bit
easier for end users to get acquainted with SELinux.
</p>
</body>
</subsection>
<subsection>
<title>Tresys Reference Policy</title>
<body>
<p>
The reference policy by choice is the <uri
link="http://oss.tresys.com/projects/refpolicy">Tresys SELinux Reference
Policy</uri>. This reference policy - currently at major version 2 - is used by
almost all SELinux supporting distributions, including Gentoo Hardened, Fedora,
RedHat Enterprise Linux, Debian, Ubuntu and more. This implementation not only
offers the modular policies that users are looking for, but also enhances the
SELinux experience with additional development tools that make it easier to
work with the SELinux policies on your system.
</p>
<p>
The reference policy starts off with a <e>base</e> policy called
<path>base.pp</path>. This is a collection of policies needed to get a system up
and running and also offers the necessary functions towards the policy modules.
In Gentoo Hardened, this base policy is offered by <c>selinux-base-policy</c>.
</p>
<p>
The policy modules themselves also use the <path>.pp</path> extension, but are
named more appropriately towards their content. For instance, the policy module
that contains all policy rules for the <c>screen</c> application is called
<path>screen.pp</path>. However, don't count on all policy modules to be named
after the tool: the policy module that contains the <c>wpa_supplicant</c>
specific rules is called <path>networkmanager.pp</path>. In Gentoo Hardened, the
modular policies are available in the <path>sec-policy</path> category and are
named <path>selinux-<module></path>.
</p>
<p>
To get a list of running modules, run <c>semodule</c>:
</p>
<pre caption="Listing the running SELinux policy modules">
~# <i>semodule -l</i>
dbus 1.14.0
dnsmasq 1.9.0
hal 1.13.0
[...]
</pre>
</body>
</subsection>
<subsection>
<title>Toggle Policy States</title>
<body>
<p>
As policies are built off from a "deny all" perspective, you can imagine that
there are thousands of rules already available in the reference policy.
Sometimes the developers know that particular rules will be active on one system
and inactive on another. Although this can be accomplished by developing two
different modules, SELinux development has opted to support <e>SELinux
booleans</e>.
</p>
<p>
SELinux booleans allow for rules to be conditionally applied, based on the
administrator's requirements. You can get a list of supported booleans through
<c>getsebool</c>:
</p>
<pre caption="Getting a list of supported booleans and their current state">
~# <i>getsebool -a</i>
allow_execheap --> off
allow_execmem --> off
[...]
fcron_crond --> off
global_ssp --> on
[...]
</pre>
<p>
If you need to change a boolean, you can use <c>togglesebool</c> to switch its
value, or <c>setsebool</c> so explicitly set its state:
</p>
<pre caption="Toggling boolean states">
~# <i>getsebool user_dmesg</i>
user_dmesg --> off
~# <i>togglesebool user_dmesg</i>
user_dmesg: active
<comment>(Now, the state is set to 'on')</comment>
~# <i>getsebool user_dmesg</i>
user_dmesg --> on
<comment>(Explicitly set the value to 'off')</comment>
~# <i>setsebool user_dmesg off</i>
</pre>
</body>
</subsection>
<subsection>
<title>Policy Files and Locations</title>
<body>
<p>
On Gentoo Hardened, the SELinux policy files are stored in
<path>/usr/share/selinux/strict</path> or
<path>/usr/share/selinux/targeted</path> (depending on your SELinux
configuration). Within this location, you will find:
</p>
<ul>
<li>
a file called <path>base.pp</path>, which is the SELinux base policy,
</li>
<li>
one or more files with extension <path>.pp</path>, which are the SELinux
policy modules, and
</li>
<li>
an <path>include/</path> folder which contains the necessary files for
SELinux module developers to build additional modules for this system
</li>
</ul>
</body>
</subsection>
<subsection>
<title>Policy Versions</title>
<body>
<p>
The SELinux policy infrastructure that is used (i.e. the capabilities and
functionalities that it offers) isn't in its first version. If you would run
<c>sestatus</c> now, you'll notice that we are using policy version 24. Every
time functionalities or capabilities are added which require changes to the
internal structure of the compiled policy, this version is incremented. The
following is an overview of the policy versions' history.
</p>
<dl>
<dt>Version 12</dt>
<dd>"Old API" for SELinux, which is now deprecated</dd>
<dt>Version 15</dt>
<dd>"New API" for SELinux, merged in Linux kernel 2.6.0 (until 2.6.5)</dd>
<dt>Version 16</dt>
<dd>Conditional policy extensions added (2.6.5)</dd>
<dt>Version 17</dt>
<dd>IPV6 support added (2.6.6 - 2.6.7)</dd>
<dt>Version 18</dt>
<dd>Fine-grained netlink socket support added (2.6.8 - 2.6.11)</dd>
<dt>Version 19</dt>
<dd>Enhanced multi-level security (2.6.12 - 2.6.13)</dd>
<dt>Version 20</dt>
<dd>Access vector table size optimizations (2.6.14 - 2.6.18)</dd>
<dt>Version 21</dt>
<dd>Object classes in range transitions (2.6.19 - 2.6.24)</dd>
<dt>Version 22</dt>
<dd>Policy capabilities (features) (2.6.25)</dd>
<dt>Version 23</dt>
<dd>Per-domain permissive mode (2.6.26 - 2.6.27)</dd>
<dt>Version 24</dt>
<dd>Explicit hierarchy (type bounds) (2.6.28 - current)</dd>
</dl>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/en/hardened/selinux/hb-intro-virtualization.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-virtualization.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-virtualization.xml?rev=1.1&content-type=text/plain
Index: hb-intro-virtualization.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-virtualization.xml,v 1.1 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
<version>0</version>
<date>2010-12-01</date>
<section>
<title>TODO</title>
<subsection>
<body>
<p>
This is a place-holder for future expansion.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/en/hardened/selinux/hb-using-commands.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-commands.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-commands.xml?rev=1.1&content-type=text/plain
Index: hb-using-commands.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-commands.xml,v 1.1 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
<version>1</version>
<date>2010-12-31</date>
<section>
<title>SELinux Information Commands</title>
<subsection>
<title>Introduction</title>
<body>
<p>
You should currently have a SELinux enabled system (but running in permissive
mode, so it will not enforce its policy rules). So before we introduce you to
the world of SELinux and how you can add more rules to make sure your system
remains functional when you switch to enforcing mode, we first give a quick
overview of the various SELinux related commands.
</p>
<p>
We start off with state commands where you can get global information on SELinux
state (is it running in enforcing mode or not, versions etc.)
</p>
</body>
</subsection>
<subsection>
<title>Getting SELinux Status</title>
<body>
<p>
The first command we will talk about is <c>sestatus</c>.
</p>
<pre caption="Running sestatus">
~# <i>sestatus</i>
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: strict
</pre>
<p>
The output of this command shows you that SELinux is enabled and is currently in
the <e>permissive</e> mode. It also tells you that the system is configured to
run in <e>strict</e> mode - so no unconfined_t domain here.
</p>
</body>
</subsection>
<subsection>
<title>Getting SELinux Object Information</title>
<body>
<p>
Next on the table is the <c>seinfo</c> command. This command allows you to query
the running policy for all objects (types, roles, attributes, users, booleans
...) defined.
</p>
<p>
Common usages are:
</p>
<ul>
<li>
checking if a specific domain is defined on your system (in case you're
wondering if you need to load an additional SELinux policy module or not)
</li>
<li>
checking which domains a particular role can be in (in case you're wondering
if your regular users are allowed by SELinux policies to even be
transitioned towards a specific domain)
</li>
<li>
checking which attributes are assigned to a specific domain (or vice versa,
which domains have a specific attribute set) as some SELinux policy rules
work on attributes rather than domains
</li>
</ul>
<p>
As an example, we query if the crontab_t domain is known, if the user_r role can
use the contab_t domain and finally which domains have the cron_spool_type
attribute set.
</p>
<pre caption="Using seinfo">
~# <i>seinfo -tcrontab_t</i>
crontab_t
~# <i>seinfo -ruser_r -x</i>
user_r
Dominated Roles:
user_r
Types:
[...]
crontab_t
[...]
~# <i>seinfo -acron_spool_type -x</i>
cron_spool_type
user_cron_spool_t
system_cron_spool_t
</pre>
</body>
</subsection>
<subsection>
<title>Querying SELinux Policy Rules</title>
<body>
<p>
A command which you will often use is <c>sesearch</c>. This command allows you
to query the current policy allow rules and is a huge help when trying to find
out if something is allowed (or why something isn't allowed).
</p>
<p>
The <c>sesearch</c> command is most often used with a source domain (<c>-s</c>),
target domain (<c>-t</c>) or both, the class for which you want to query allow
rules for (file, dir, socket, process ...) and the privilege you want to query
for (read, write, open, transition, execute ...).
</p>
<p>
For instance, to find out which domains can write the files that have the
shadow_t domain:
</p>
<pre caption="Querying allow rules with sesearch">
~# <i>sesearch -t shadow_t -c file -p write -A</i>
Found 8 semantic av rules:
[...]
allow portage_t shadow_t : file { ioctl read write ... };
allow useradd_t shadow_t : file { ioctl read write ... };
...
</pre>
<p>
You will notice that there are sometimes results based on attributes rather than
domains:
</p>
<pre caption="Allow rule based on attribute">
allow portage_t file_type : file { ioctl read write ... };
</pre>
<p>
In this case, the source domain (portage_t) is allowed to write to files whose
domain have the file_type attribute set. If you get the feeling of these things,
you'll wonder if the above rule is not a flagrant security issue as almost all
domains for files have the file_type set. Yes and no - if we take a look at
which domains have file write privileges to file_type domains, you'll notice
that this is only portage:
</p>
<pre caption="Querying domains with file-write privileges to file_type domains">
~# <i>sesearch -t file_type -c file -p write -A -d</i>
Found 1 semantic av rules:
allow portage_t file_type : file { ioctl read write ... };
</pre>
<p>
Note that we had one command without the <c>-d</c> option and one with. When
<c>-d</c> is given, the search will perform an exact search without resolving
the attributes. When <c>-d</c> is not given, it will resolve the attribute. In
the last command example, dropping <c>-d</c> would result in hundreds of allow
rules: for each domain that has file_type set, the search tries to find rules
that allow file-write access to that particular domain.
</p>
</body>
</subsection>
<subsection>
<title>Getting Security Context Information</title>
<body>
<p>
During administrative tasks, and especially when you are checking if a SELinux
denial could be made, it is important to find out what the security context is
for a particular resource. Luckily, Gentoo Hardened - if properly installed -
has already patched some tools to allow you to get this information using your
standard tools.
</p>
<p>
To get the security context of a file, use <c>ls -Z</c>:
</p>
<pre caption="Getting a file security context">
~$ <i>ls -Z /etc/make.conf</i>
system_u:object_r:portage_conf_t /etc/make.conf
</pre>
<p>
To get the security context of a process, use <c>ps -Z</c>:
</p>
<pre caption="Getting a process security context">
~# <i>ps -Z $(pidof init)</i>
LABEL PID TTY STAT TIME COMMAND
system_u:system_r:init_t 1 ? Ss 0:00 init [3]
</pre>
<p>
To get the security context of the current user, use <c>id -Z</c>:
</p>
<pre caption="Getting a user security context">
~$ <i>id -Z</i>
staff_u:staff_r:staff_t
</pre>
</body>
</subsection>
</section>
<section>
<title>Managing SELinux</title>
<subsection>
<title>Introduction</title>
<body>
<p>
Managing SELinux objects (booleans, users, ports, contexts ...) is most often
done using <c>semanage</c>. As this application offers the interface towards
various SELinux configurations, we dedicate an entire section on it, but will
also cover the commands that offer similar functionality (and are sometimes
easier to remember).
</p>
</body>
</subsection>
<subsection>
<title>Booleans</title>
<body>
<p>
We have already covered SELinux booleans earlier in this book as well as the
<c>getsebool</c> and <c>setsebool</c> commands. With <c>semanage</c> you can too
manage the booleans and, as an added bonus, listing the booleans will also show
the description of the boolean (even though there is still work to be done in
this area).
</p>
<pre caption="Listing the available SELinux booleans">
~# <i>semanage boolean -l</i>
SELinux boolean Description
allow_ptrace -> off allow_ptrace
rsync_export_all_ro -> off rsync_export_all_ro
</pre>
<note>
As you will notice, most descriptions are just the boolean name, but you will
find more and more booleans with a better description as you get acquainted with
- and install more - SELinux policy modules.
</note>
<p>
You can set a boolean with both <c>setsebool</c> and <c>semanage</c>:
</p>
<pre caption="Setting SELinux boolean values">
~# <i>semanage boolean -m --on -F user_dmesg</i>
</pre>
</body>
</subsection>
<subsection>
<title>SELinux Users and Logins</title>
<body>
<p>
SELinux users and logins are different from Unix accounts. SELinux logins allow
you to map a Unix account to a SELinux user:
</p>
<pre caption="Listing the SELinux logins">
~# <i>semanage login -l</i>
Login Name SELinux User
__default__ user_u
root root
swift staff_u
system_u system_u
</pre>
<p>
The default behavior is that users are logged on as the <e>user_u</e> SELinux
user. If you want to allow another user (say <c>anna</c>) to log on as
<c>staff_u</c>:
</p>
<pre caption="Letting 'anna' log on as 'staff_u'">
~# <i>semanage login -a -s staff_u anna</i>
</pre>
<p>
SELinux users then can be configured to belong to one or more roles.
</p>
<pre caption="Listing login / role mappings">
~# <i>semanage user -l</i>
SELinux User SELinux Roles
root staff_r sysadm_r
staff_u staff_r sysadm_r
[...]
</pre>
</body>
</subsection>
<subsection>
<title>Managing Ports</title>
<body>
<p>
Even network ports (like port 22 for SSH) are 'protected' by SELinux. To get an
overview of which domains are assigned to which ports (or port ranges) use
<c>semanage port -l</c>.
</p>
<pre caption="Listing SELinux managed ports">
~# <i>semanage port -l | grep '22$'</i>
ssh_port_t tcp 22
</pre>
</body>
</subsection>
</section>
<section>
<title>Using SELinux</title>
<subsection>
<title>Introduction</title>
<body>
<p>
Up until now we've covered getting SELinux related information as well as
managing SELinux settings. However, users on a SELinux hardened system will also
need to know a few things about working with SELinux, including (but not limited
to) roles and role transitions.
</p>
</body>
</subsection>
<subsection>
<title>Switching Roles</title>
<body>
<p>
As a type enforcement access control system, SELinux allows particular roles to
be within a set of domains. If you are using a role which is not allowed within
a particular domain, you will not be successful in using that domain and will be
denied the actions assigned to that domain.
</p>
<p>
If your standard users are all SELinux user_u users (with the only supported
role being user_r) then those users will never need to switch roles (nor are
they allowed to). But users that are staff_u (or other users that have multiple
roles) those users should be made clear how they switch between roles.
</p>
<p>
The command that accomplishes this is called <c>newrole</c>. It's use is pretty
straight forward.
</p>
<pre caption="Using newrole">
~$ <i>newrole -r sysadm_r</i>
Password: <comment>(Enter the users' password - not root's!)</comment>
</pre>
<p>
When performing a role transition, SELinux will ask the user to re-authenticate
through its users' password. If you are logged on as a regular user and used
<c>su</c> or <c>sudo</c> to become the root user, then <c>newrole</c> will still
require you to enter the regular users' password.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/en/hardened/selinux/hb-using-enforcing.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-enforcing.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-enforcing.xml?rev=1.1&content-type=text/plain
Index: hb-using-enforcing.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-enforcing.xml,v 1.1 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
<version>1</version>
<date>2011-03-02</date>
<section>
<title>Switching to Enforcing Mode</title>
<subsection>
<title>Introduction</title>
<body>
<p>
Switching to enforcing mode doesn't require all policies to be fully
operational, nor does it require that the system boots in enforcing mode. You
can first start small by enabling enforcing mode the moment your system is
booted, then enable enforcing during boot (but with the possibility to disable
it again when some things fail) and finally reconfigure your kernel so that
disabling SELinux isn't possible anymore.
</p>
</body>
</subsection>
<subsection>
<title>Booting, Switch</title>
<body>
<p>
To boot your system before enabling enforcing mode, just boot as you do
currently. Then, when you believe that you can run your system in enforcing
mode, run <c>setenforce 1</c>.
</p>
<pre caption="Enabling enforcing mode">
~# <i>setenforce 1</i>
</pre>
<p>
It is wise to ensure that you have booted the system but not logged in anywhere
except as the root user. Also verify that the session you're currently in (as
root) uses the <c>root:sysadm_r:sysadm_t</c> or
<c>unconfined_u:unconfined_r:unconfined_t</c> context (otherwise trying to
disable enforcing mode might not work).
</p>
<p>
When you realize that things are going very, very wrong, disable SELinux using
<c>setenforce 0</c> and try to resolve the failures.
</p>
</body>
</subsection>
<subsection>
<title>Booting in Enforcing Mode (Once)</title>
<body>
<p>
When you want to boot in enforcing mode, but you don't want to configure SELinux
(yet) to run always in enforcing mode (say you want to try it once), add
<c>enforcing=1</c> as a boot option inside the boot loader configuration.
</p>
<pre caption="Sample GRUB configuration to boot in enforcing mode">
kernel /vmlinuz root=/dev/md3 rootflags=data=journal <i>enforcing=1</i>
</pre>
</body>
</subsection>
<subsection>
<title>Booting in Enforcing Mode</title>
<body>
<p>
Once you believe that you can always (re)boot in enforcing mode, edit
<path>/etc/selinux/config</path> and change <c>SELINUX=permissive</c> to
<c>SELINUX=enforcing</c>.
</p>
</body>
</subsection>
<subsection>
<title>Reconfiguring the Kernel</title>
<body>
<p>
Once you are fully confident that you can always and ever remain in enforcing
mode, reconfigure your kernel so that SELinux cannot be disabled anymore.
</p>
<pre caption="Reconfiguring the Linux kernel">
[*] NSA SELinux Support
[ ] NSA SELinux boot parameter
[ ] NSA SELinux runtime disable
<comment># Make sure the following is deselected</comment>
<i>[ ] NSA SELinux Development Support</i>
[ ] NSA SELinux AVC Statistics
(1) NSA SELinux checkreqprot default value
[ ] NSA SELinux maximum supported policy format version
</pre>
</body>
</subsection>
</section>
<section>
<title>Analyzing AVC</title>
<subsection>
<title>Intrusion or Not</title>
<body>
<p>
Once you are running in enforcing mode, the role of the
<path>/var/log/avc.log</path> logfile starts changing. Whereas it was previously
used to inform you about denials which might cause functional failures on your
system, it is now more and more becoming a source of information for the
behavior of applications - and sometimes, the unexpected behavior of it.
</p>
<p>
Being able to read the AVC logs is important, because in the (near) future you
should use the AVC logs to identify potential intrusion attempts. Say that you
are running an Internet-facing web server which is contained within its own
SELinux domain. Suddenly you start getting weird AVC denials of that SELinux
domain trying to read files it really shouldn't read, or write stuff in some
temporary location it shouldn't write anything into. This can be a totally
expected behavior, but can also be a malicious user that is attempting to run
some exploit code against your web server.
</p>
<p>
Interpreting the AVC logs can be considered a time-consuming job if you are
still getting lots of cosmetic (and safe) AVC denials. So let's first see if we
can ignore those...
</p>
</body>
</subsection>
<subsection>
<title>Ignoring Cosmetic AVC Events</title>
<body>
<p>
When you get AVC denials which you believe are harmless for your system, you can
create a policy module yourself which contains the exact AVC rule, but using the
<e>dontaudit</e> statement rather than <e>allow</e>.
</p>
<p>
Consider the following AVC denial:
</p>
<pre caption="Sample harmless AVC denial">
Jan 6 19:49:25 hpl kernel: [10482.016339] type=1400 audit(1294339765.865:1527):
avc: denied { use } for pid=19421 comm="ifconfig" path="/dev/null" dev=tmpfs
ino=1552 scontext=system_u:system_r:ifconfig_t
tcontext=system_u:system_r:wpa_cli_t tclass=fd
</pre>
<p>
The denial states that the <c>ifconfig</c> process is trying to use a file
descriptor within the wpa_cli_t domain. The target file descriptor points to
<path>/dev/null</path>. This usually means that the <c>ifconfig</c> process is
started from within the wpa_cli_t domain with <c>> /dev/null</c> to redirect
its output to the <path>/dev/null</path> device. Although it is denied (so no output
will be redirected to <path>/dev/null</path>) it has no functional impact on the
system as the intention was to ignore the output anyhow.
</p>
<p>
So how can we ensure that this rule doesn't fill up our AVC logs? Well, we need
to create a module (like we have seen before and which we discuss in a later
chapter again :-):
</p>
<pre caption="Creating a module to ignore these AVC denials">
~$ <i>cat ignoreavc.te</i>
module ignoreavc 1.0.0;
require {
type ifconfig_t;
type wpa_cli_t;
class fd use;
}
dontaudit ifconfig_t wpa_cli_t:fd { use };
~$ <i>checkmodule -m -o ignoreavc.mod ignoreavc.te</i>
~$ <i>semodule_package -o ignoreavc.pp -m ignoreavc.mod</i>
~$ <i>semodule -i ignoreavc.pp</i>
</pre>
<p>
Once this module is loaded, you should no longer see these denials in your log.
However, if you ever feel that you might have <e>dontaudit</e>'ed too many
things, you can always reload the SELinux policies without the dontaudit
statements:
</p>
<pre caption="Reloading the SELinux policies without dontaudit">
~# <i>semodule -R -D</i>
</pre>
<p>
If you are confident to continue with the dontaudit statements again, run the
same command without the <c>-D</c>.
</p>
<p>
Gentoo Hardened uses a specific boolean called <c>gentoo_try_dontaudit</c> to
show or hide the denials that the developers believe are cosmetic. Thanks to
this approach, you can first disable the Gentoo-selected dontaudit statements
before showing all of them - which can be quite a lot more.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/en/hardened/selinux/hb-using-install.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-install.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-install.xml?rev=1.1&content-type=text/plain
Index: hb-using-install.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-install.xml,v 1.1 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
<version>2</version>
<date>2011-03-09</date>
<section>
<title>Installing Gentoo Hardened</title>
<subsection>
<title>Introduction</title>
<body>
<p>
Getting a Gentoo Hardened SELinux installation doesn't require weird actions.
What you need to do is install Gentoo Linux with the correct profile, correct
kernel configuration and some file system relabelling. We seriously recommend to
use SELinux together with other hardening improvements (such as PaX /
grSecurity).
</p>
<p>
This chapter will describe the steps to install Gentoo Hardened with SELinux. We
assume that you have an existing Gentoo Linux system which you want to convert
to Gentoo Hardened with SELinux. If this is not the case, you should still read
on: you can install Gentoo Hardened with SELinux immediately if you make the
correct decisions during the installation process, based on the information in
this chapter.
</p>
</body>
</subsection>
<subsection>
<title>Performing a Standard Installation</title>
<body>
<p>
Install Gentoo Linux according to the <uri link="/doc/en/handbook">Gentoo
Handbook</uri> installation instructions. We recommend the use of the hardened
stage 3 tarballs instead of the standard ones. Perform a full installation to
the point that you have booted your system into a (primitive) Gentoo base
installation.
</p>
<note>
If you are an XFS user, make sure that the inode sizes of the XFS file
system is 512 byte. Since the default is 256, you will need to run the
<c>mkfs.xfs</c> command with the <c>-i size=512</c> arguments, like so:
<c>mkfs.xfs -i size=512 /dev/sda3</c>
</note>
</body>
</subsection>
<subsection>
<title>Installing the Hardened Development Overlay</title>
<body>
<p>
Although optional, we recommend to enable the <c>hardened-development</c>
overlay. The state of SELinux within Gentoo Hardened is still undergoing
major development.
</p>
<p>
Install <c>app-portage/layman</c> and add the <c>hardened-development</c>
overlay. This overlay uses a git repository, so either install <c>git</c> as
well, or set <c>USE="git"</c> in <path>/etc/make.conf</path>.
Make sure to include layman's <path>make.conf</path> in your
<path>make.conf</path> file.
</p>
<pre caption="Installing hardened-development overlay">
~# <i>emerge layman</i>
~# <i>layman -S</i>
~# <i>layman -a hardened-development</i>
~# <i>nano /etc/make.conf</i>
<comment># Add the following line at the top of your make.conf file</comment>
<i>source /var/lib/layman/make.conf</i>
</pre>
</body>
</subsection>
<subsection>
<title>Optional: Setting the /tmp context</title>
<body>
<p>
If your <path>/tmp</path> location is a tmpfs-mounted file system, then you need
to tell the kernel that the root context of this location is <c>tmp_t</c>
instead of <c>tmpfs_t</c>. Many SELinux policy objects (including various
server-level policies) assume that <path>/tmp</path> is <c>tmp_t</c>.
</p>
<p>
To configure the <path>/tmp</path> mount, edit your <path>/etc/fstab</path>:
</p>
<pre caption="Update /etc/fstab for /tmp">
tmpfs /tmp tmpfs defaults,noexec,nosuid<i>,rootcontext=system_u:object_r:tmp_t</i> 0 0
</pre>
</body>
</subsection>
<subsection>
<title>Enabling ~Arch Packages</title>
<body>
<p>
The current stable SELinux related packages are not fit for use anymore (or are
even broken) so we seriously recommend to enable ~arch packages for SELinux. Add
the following settings to the right file (for instance
<path>/etc/portage/package.accept_keywords/selinux</path>):
</p>
<pre caption="SELinux ~arch packages">
sys-libs/libselinux
sys-apps/policycoreutils
sys-libs/libsemanage
sys-libs/libsepol
app-admin/setools
dev-python/sepolgen
sys-apps/checkpolicy
sec-policy/*
=sys-process/vixie-cron-4.1-r11
</pre>
</body>
</subsection>
<subsection>
<title>Change the Gentoo Profile</title>
<body>
<p>
Now that you have a running Gentoo Linux installation, switch the Gentoo profile
to the right SELinux hardened profile (for instance,
<path>selinux/v2refpolicy/amd64/hardened</path>).
</p>
<pre caption="Switching the Gentoo profile">
~# <i>eselect profile list</i>
Available profile symlink targets:
[1] default/linux/amd64/10.0
[2] default/linux/amd64/10.0/desktop
[3] default/linux/amd64/10.0/desktop/gnome
[4] default/linux/amd64/10.0/desktop/kde
[5] default/linux/amd64/10.0/developer
[6] default/linux/amd64/10.0/no-multilib
[7] default/linux/amd64/10.0/server *
[8] hardened/linux/amd64
[9] hardened/linux/amd64/no-multilib
[10] selinux/2007.0/amd64
[11] selinux/2007.0/amd64/hardened
[12] selinux/v2refpolicy/amd64
[13] selinux/v2refpolicy/amd64/desktop
[14] selinux/v2refpolicy/amd64/developer
[15] selinux/v2refpolicy/amd64/hardened
[16] selinux/v2refpolicy/amd64/server
~# <i>eselect profile set 15</i>
</pre>
<note>
Starting from the profile change, Portage will warn you after every installation
that it was "Unable to set SELinux security labels". This is to be expected,
because the tools and capabilities that Portage requires to set the security
labels aren't available yet. This warning will vanish the moment the SELinux
installation is completed.
</note>
<p>
Edit your <path>/etc/make.conf</path> file and set
<c>FEATURES="-loadpolicy"</c>. The current SELinux profile enables the
loadpolicy feature, but this isn't supported anymore so can be safely ignored.
</p>
<p>
Don't update your system yet - we will need to install a couple of packages in a
particular order which Portage isn't aware of in the next couple of sections.
</p>
</body>
</subsection>
<subsection>
<title>Manual System Changes</title>
<body>
<warn>
Most, if not all of the next few changes will be resolved through regular
packages as soon as possible. However, these fixes have impact beyond the Gentoo
Hardened installations. As such, these changes will be incorporated a bit slower
than the SELinux-specific updates. For the time being, manually correcting these
situations is sufficient (and a one-time operation).
</warn>
<p>
The following changes <e>might</e> be necessary on your system, depending on the
tools or configurations that apply.
</p>
<ul>
<li>
If you use LVM for one or more file systems, you need to edit
<path>/lib/rcscripts/addons/lvm-start.sh</path> (or <path>/lib64/..</path>)
and <path>lvm-stop.sh</path> and set the config location from
<path>/dev/.lvm</path> to <path>/etc/lvm/lock</path>. Next, create the
<path>/etc/lvm/lock</path> directory.
</li>
<li>
Check if you have <path>*.old</path> files in <path>/bin</path>. If you do,
either remove those or make them a copy of their counterpart so that they
get their own security context. The <path>.old</path> files are hard links
which mess up the file labelling. For instance, <c>cp /bin/hostname
/bin/hostname.old</c>.
</li>
</ul>
</body>
</subsection>
<subsection>
<title>Installing a SELinux Kernel</title>
<body>
<p>
Although the default Linux kernels offer SELinux support, we recommend the use
of the <path>sys-kernel/hardened-sources</path> package.
</p>
<pre caption="Installing hardened-sources">
<comment>(Only if you have not installed it previously of course)</comment>
~# <i>emerge hardened-sources</i>
</pre>
<p>
Next, reconfigure the kernel with the appropriate security settings. This
includes, but is not limited to
</p>
<ul>
<li>Support for extended attributes in the various file systems</li>
<li>Support system-call auditing</li>
<li>Support for SELinux</li>
</ul>
<p>
Below you can find a quick overview of the recommended settings.
</p>
<pre caption="Recommended settings for the Linux kernel configuration">
<comment>Under "General setup"</comment>
[*] Prompt for development and/or incomplete code/drivers
[*] Auditing support
[*] Enable system-call auditing support
<comment>Under "File systems"</comment>
<comment>(For each file system you use, make sure extended attribute support is enabled)</comment>
<*> Second extended fs support
[*] Ext2 extended attributes
[ ] Ext2 POSIX Access Control Lists
[*] Ext2 Security Labels
[ ] Ext2 execute in place support
<*> Ext3 journalling file system support
[ ] Default to 'data=ordered' in ext3
[*] Ext3 extended attributes
[ ] Ext3 POSIX Access Control Lists
[*] Ext3 Security Labels
<*> The Extended 4 (ext4) filesystem
[*] Ext4 extended attributes
[ ] Ext4 POSIX Access Control Lists
[*] Ext4 Security Labels
<*> JFS filesystem support
[ ] JFS POSIX Access Control Lists
[*] JFS Security Labels
[ ] JFS debugging
[ ] JFS statistics
<*> XFS filesystem support
[ ] XFS Quota support
[ ] XFS POSIX ACL support
[ ] XFS Realtime subvolume support (EXPERIMENTAL)
[ ] XFS Debugging Support
<*> Btrfs filesystem (EXPERIMENTAL)
[ ] Btrfs POSIX Access Control Lists
<comment>Under "Security options"</comment>
[*] Enable different security models
[*] Socket and Networking Security Hooks
[*] NSA SELinux Support
[ ] NSA SELinux boot parameter
[ ] NSA SELinux runtime disable
[*] NSA SELinux Development Support
[ ] NSA SELinux AVC Statistics
(1) NSA SELinux checkreqprot default value
[ ] NSA SELinux maximum supported policy format version
Default security module (Unix Discretionary Access Controls) --->
<comment>(The latter can also be set to SELinux - but this serves little purpose)</comment>
</pre>
<p>
We recommend to use PaX as well. More information on PaX within Gentoo Hardened
can be found in the <uri link="/proj/en/hardened/pax-quickstart.xml">Hardened
Gentoo PaX Quickstart Guide</uri>.
</p>
<p>
Build and install the new Linux kernel and its modules.
</p>
</body>
</subsection>
<subsection>
<title>Update fstab</title>
<body>
<p>
Next, edit <path>/etc/fstab</path> and add the following line:
</p>
<pre caption="Enabling selinux file system">
none /selinux selinuxfs defaults 0 0
</pre>
<p>
Make the <path>/selinux</path> mountpoint as well:
</p>
<pre caption="Creating the /selinux mountpoint">
~# <i>mkdir /selinux</i>
</pre>
</body>
</subsection>
<subsection>
<title>Reboot</title>
<body>
<p>
With the above changes made, reboot your system. Assert yourself that you are
now running a Linux kernel with SELinux enabled (the <path>/selinux</path> file
system should be mounted). Don't worry - SELinux is at this point not activated.
</p>
</body>
</subsection>
</section>
<section>
<title>Configure SELinux</title>
<subsection>
<title>Introduction</title>
<body>
<p>
Next we will need to configure SELinux by installing the appropriate
utilities, label our file system and configure the policy.
</p>
</body>
</subsection>
<subsection>
<title>Install Policies and Utilities</title>
<body>
<p>
First, install the <path>sys-apps/checkpolicy</path> and
<path>sys-apps/policycoreutils</path> packages. Although these will be pulled in
as dependencies of the SELinux policy packages themselves, we need to install
these one time first - hence the <c>-1</c> option.
</p>
<pre caption="Installing SELinux policy core utilities">
~# <i>emerge -1 checkpolicy policycoreutils</i>
</pre>
<p>
Next, install the SELinux policy package
(<path>sec-policy/selinux-base-policy</path>). This package contains the base
SELinux policy needed to get your system up and running using SELinux.
As Portage will try to label and reload policies (since the installation of
<path>sys-apps/policycoreutils</path>) we need to temporarily disable SELinux
support (as Portage wouldn't be able to label anything as it doesn't understand
it yet).
</p>
<pre caption="Installing the SELinux policy packages">
~# <i>FEATURES="-selinux" emerge selinux-base-policy</i>
</pre>
<p>
Next, rebuild those packages affected by the profile change we did previously
through a standard world update, taking into account USE-flag changes (as the
new profile will change many default USE flags, including enabling the
<c>selinux</c> USE flag).
</p>
<pre caption="Update your Gentoo Linux system">
~# <i>emerge -uDN world</i>
</pre>
<p>
Next, install the additional SELinux tools that you might need in the future to
debug or help with your SELinux installation. These packages are optional, but
recommended.
</p>
<pre caption="Installing additional SELinux packages">
~# <i>emerge setools sepolgen checkpolicy</i>
</pre>
<p>
Finally, install the policy modules for those utilities you think you need
policies for. In the near future, this will be done automatically for you (the
packages will have an optional dependency on it, triggered by the selinux USE
flag), but until that time, you will need to install them yourself.
</p>
<pre caption="Installing SELinux modules">
~# <i>eix selinux-</i>
[...]
<comment>(Select the modules you want to install)</comment>
~# <i>emerge selinux-screen selinux-gnupg selinux-sudo selinux-ntp selinux-networkmanager ...</i>
</pre>
</body>
</subsection>
<subsection>
<title>Configure the SELinux Policy</title>
<body>
<p>
Inside <path>/etc/selinux/config</path> you can configure how SELinux is
configured at boot time.
</p>
<pre caption="Editing the /etc/selinux/config file">
# This file controls the state of SELinux on the system on boot.
# 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=<i>permissive</i>
# SELINUXTYPE can take one of these two values:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=<i>strict</i>
</pre>
<p>
Within this configuration file, two variables can be set:
</p>
<ul>
<li>
<c>SELINUX</c> sets how SELinux should behave:
<ul>
<li>
<c>enforcing</c> will enable and enforce policies. This is where we want
to go for, but you should probably start with <c>permissive</c>.
</li>
<li>
<c>permissive</c> will enable policies, but not enforce them. Any
violation is reported but not denied. This is where you should start
from as it will not impact your system yet allow you to get acquainted
with SELinux - and validate the warnings to see if you can switch
towards <c>enforcing</c> or not.
</li>
<li>
<c>disabled</c> will completely disable the policies. As this will not
show any violations as well, it is not recommended.
</li>
</ul>
</li>
<li>
<c>SELINUXTYPE</c> selects if an "unconfined" domain will be loaded or not.
Gentoo Hardened recommends the use of <c>strict</c> for servers, and
<c>targeted</c> for desktops.
</li>
</ul>
<p>
The differentiation between <c>strict</c> and <c>targeted</c> is based upon the
<e>unconfined</e> domain. When loaded, the processes on your system that are not
specifically confined within a particular policy module will be part of the
unconfined_t domain whose purpose is to allow most activities by default (rather
than deny by default). As a result, processes that run inside the unconfined_t
domain have no restrictions apart from those already enforced by standard Linux
security. Although running without the unconfined_t domain is considered more
secure, it will also be more challenging for the administrator to make sure the
system still functions properly as there are no policy modules for each and
every application "out there".
</p>
<p>
When you have made your choice between <c>strict</c> and <c>targeted</c>, save
this in your <path>/etc/make.conf</path> file as well. That way, Portage will
only install the policy modules for that SELinux type rather than both.
</p>
<pre caption="Setting the policy type in make.conf">
~# <i>nano /etc/make.conf</i>
POLICY_TYPES="<i>strict</i>"
</pre>
</body>
</subsection>
<subsection>
<title>Label the File System</title>
<body>
<impo>
Repeat these steps every time you have rebooted from a non-SELinux enabled
kernel into a SELinux enabled kernel, as running with a non-SELinux enabled
kernel will not update the security attributes of the files you create or
manipulate during your day-to-day activities on your system.
</impo>
<p>
First relabel your devices. This will apply the correct security contexts
(labels) onto the device files.
</p>
<pre caption="Relabel /dev structure">
~# <i>mkdir /mnt/gentoo</i>
~# <i>mount -o bind / /mnt/gentoo</i>
<comment>(Substitute the "strict" in the next command with "targeted" if that is your SELINUXTYPE selection)</comment>
~# <i>setfiles -r /mnt/gentoo /etc/selinux/strict/contexts/files/file_contexts /mnt/gentoo/dev</i>
~# <i>umount /mnt/gentoo</i>
</pre>
<p>
Now relabel your entire file system. The next command will apply the correct
security context onto the files on your file system, based on the security
context information provided by the SELinux policy modules installed.
</p>
<pre caption="Relabel the entire file system">
~# <i>rlpkg -a -r</i>
</pre>
<p>
If you ever have to install a SELinux policy module for a package after that
that particular package is installed, you need to run <c>rlpkg</c> for that
package to make sure that the security contexts for these files are set
correctly. For instance, if you have installed
<path>sec-policy/selinux-screen</path> after discovering that you have
<c>screen</c> on your system:
</p>
<pre caption="Relabeling the files for a single package">
<comment>(Make sure no screen sessions are running as their security contexts will not be adapted)</comment>
~# <i>rlpkg -t screen</i>
</pre>
</body>
</subsection>
<subsection>
<title>Reboot</title>
<body>
<p>
Reboot your system. Log on and, if you have indeed installed Gentoo using the
hardened sources (as we recommended), enable the SSP SELinux boolean:
</p>
<pre caption="Enabling the global_ssp boolean">
~# <i>setsebool -P global_ssp on</i>
</pre>
<p>
With that done, enjoy - your first steps into the SELinux world are now
made.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/en/hardened/selinux/hb-using-permissive.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-permissive.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-permissive.xml?rev=1.1&content-type=text/plain
Index: hb-using-permissive.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-permissive.xml,v 1.1 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
<version>2</version>
<date>2011-03-02</date>
<section>
<title>Keeping Track of Denials</title>
<subsection>
<title>Introduction</title>
<body>
<p>
The moment you start using SELinux in permissive mode, SELinux will start
logging all of its denials through your system logger. Based on this
information, you can and will:
</p>
<ul>
<li>
see if certain domains are missing (for instance, commands are being ran
inside a more standard domain whereas you would expect it to run within a
more specific one) in which case you'll probably look for a SELinux policy
module to introduce the specific domain,
</li>
<li>
see if some files have wrong security contexts in which case you'll either
restore their context or set it yourself,
</li>
<li>
see if some denials are made which you don't expect in which case you'll
find out why the denial is made and what the original policy writer intended
(a prime example would be a website hosted in the wrong location in the file
system)
</li>
</ul>
<p>
Of course, several other aspects can be performed the moment you analyze the
denial messages, but the above ones are the most common.
</p>
</body>
</subsection>
<subsection>
<title>Configuring System Logger</title>
<body>
<p>
Before we start investigating denials, let's first configure the system logger
to log the denials in its own log file. If you are running syslog-ng with a
Gentoo Hardened profile, it will already be configured to log these denials in
<path>/var/log/avc.log</path>:
</p>
<pre caption="syslog-ng configuration">
destination avc { file("/var/log/avc.log"); };
[...]
filter f_avc { message(".*avc: .*"); };
filter f_audit { message("^(\\[.*\..*] |)audit.*") and not message(".*avc: .*"); };
[...]
log { source(kernsrc); filter(f_avc); destination(avc); };
</pre>
<p>
If you use a different logger, look for the configuration of the kernel audit
events. Throughout the rest of this document, we assume that the log where the
denials are logged in is <path>/var/log/avc.log</path>.
</p>
</body>
</subsection>
<subsection>
<title>What is AVC?</title>
<body>
<p>
When we previously showed a few of SELinux' policy allow rules, what you were
actually looking at was an <e>access vector</e> rule. For instance:
</p>
<pre caption="Example access vector rule">
allow sysadm_t portage_t : process transition ;
</pre>
<p>
Up until now we have seen only the <e>allow</e> permission, but SELinux supports
others as well:
</p>
<ul>
<li>
<e>auditallow</e> will allow an activity to occur, but will still log it
(but then with a "granted" message instead of "denied")
</li>
<li>
<e>dontaudit</e> will not allow an activity to occur but will also not log
this. This is particularly useful where the activity is not needed and would
otherwise fill the <path>avc.log</path> file.
</li>
</ul>
<p>
To improve efficiency of the policy enforcement, SELinux uses a cache for its
access vectors - the <e>access vector cache</e> or <e>AVC</e>. Whenever some
access is requested which isn't in the cache yet, it is first loaded in the
cache from which the allow/deny is triggered. Hence the "avc" messages and the
<path>avc.log</path> log file.
</p>
</body>
</subsection>
<subsection>
<title>Looking at the AVC Log</title>
<body>
<p>
During regular system operations, you can keep track of the denials through a
simple <c>tail</c> session:
</p>
<pre caption="Looking at the avc logs">
~# <i>tail -f /var/log/avc.log</i>
Jan 1 09:56:59 hpl kernel: [ 2232.354810] type=1400 audit(1293872219.247:156):
avc: denied { setattr } for pid=7419 comm="gorg" name="selinux-handbook.xml" dev=dm-3 ino=159061
scontext=staff_u:staff_r:staff_t tcontext=staff_u:object_r:var_t tclass=file
Jan 1 10:08:52 hpl kernel: [ 2944.664577] type=1400 audit(1293872932.907:157):
avc: denied { use } for pid=9917 comm="ifconfig" path="/dev/null" dev=tmpfs ino=1546
scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:wpa_cli_t tclass=fd
Jan 1 10:08:53 hpl kernel: [ 2945.504956] type=1400 audit(1293872933.749:158):
avc: denied { create } for pid=10016 comm="logger"
scontext=system_u:system_r:wpa_cli_t tcontext=system_u:system_r:wpa_cli_t tclass=unix_stream_socket
</pre>
<p>
But how do you interprete such messages? Well, let's take a closer look at the
first denial from the example.
</p>
<pre caption="Sample denial message">
<comment>[ Standard data within log message, such as date, time, hostname, ... ]</comment>
Jan 1 09:56:59 hpl kernel: [ 2232.354810] type=1400
<comment>[ The message is an AVC audit message, telling a deny for the setattr system call ]</comment>
audit(1293872219.247:156): avc: denied { setattr }
<comment>[ The offending process has PID 7419 and is named "gorg" ]</comment>
for pid=7419 comm="gorg"
<comment>[ The target for the system call is a file named "selinux-handbook.xml"
on the dm-3 device; the file has inode 159061 ]</comment>
name="selinux-handbook.xml" dev=dm-3 ino=159061
<comment>[ The source and target security contexts and the class of the target (in this case, a file) ]</comment>
scontext=staff_u:staff_r:staff_t tcontext=staff_u:object_r:var_t tclass=file
</pre>
<p>
A similar one can be found of the last line in the example.
</p>
<pre caption="Another sample denial message">
Jan 1 10:08:53 hpl kernel: [ 2945.504956] type=1400 audit(1293872933.749:158):
avc: denied { create } for pid=10016 comm="logger"
scontext=system_u:system_r:wpa_cli_t tcontext=system_u:system_r:wpa_cli_t tclass=unix_stream_socket
</pre>
<p>
In this particular case, the offending process is <c>logger</c> (with PID 10016)
which is trying to create a Unix stream socket (see the <e>tclass</e>
information).
</p>
<p>
Note though that not all AVC messages imply denials. Some accesses recorded by
the access vector cache are grants but which have an explicit <e>auditallow</e>
statement so that this can be tracked in the logs.
</p>
</body>
</subsection>
</section>
<section>
<title>Analyzing Denials</title>
<subsection>
<title>A Standard Setup Will Not Work</title>
<body>
<p>
If you have taken a look at your denials, you'll probably think "If I'm going to
go to enforcing mode, my system will not function properly" and you're right. At
this point, Gentoo Hardened is constantly updating the SELinux policies to get
you a working system - but we're not there yet. For this reason, being able to
analyze the denials (and take corrective actions) is very important.
</p>
<p>
It is not easy to describe what the best option is when you see a denial which
shouldn't be. But a few ground-rules do apply.
</p>
<ul>
<li>
Verify if the denial is cosmetic or not. Try focusing on denials of which
you are <e>sure</e> that they are not cosmetic and will result in a
malfunction of your system (or that particular command) if no corrective
action is taken.
</li>
<li>
If you see a denial where the source context is a generic one (such as
<e>sysadm_t</e> or <e>staff_t</e> or <e>user_t</e>), try to find out if
there are specific SELinux policy modules for the offending resource. In the
previous example of the <c>gorg</c> process, we definitely need to check if
there is no selinux-gorg SELinux policy. Note that, even if there is none,
it doesn't mean there shouldn't be ;-)
</li>
<li>
If the target for the denial is a file, verify if its security context is
correct or if no different context should be given. It is also possible that
the process is trying to work on the wrong path. Sometimes a simple
configuration change of that process is sufficient to make it work properly
under its SELinux policy.
</li>
</ul>
<p>
During development of the policies, Gentoo Hardened developers will try to
hide denials they believe are cosmetic. This hiding can be toggled using the
SELinux <c>gentoo_try_dontaudit</c> boolean:
</p>
<pre caption="Getting and setting Gentoo's gentoo_try_dontaudit boolean">
~# <i>getsebool gentoo_try_dontaudit</i>
gentoo_try_dontaudit --> off
~# <i>setsebool -P gentoo_try_dontaudit on</i>
</pre>
<p>
When set, the denials that are believed to be cosmetic are hidden from your
audit logs. But if your system is not functioning properly and you do not see
any denials, it is wise to toggle this boolean again to verify if the denial
is now shown or not.
</p>
</body>
</subsection>
<subsection>
<title>Installing Additional SELinux Policy Modules</title>
<body>
<p>
When a denial is found for which you think a SELinux policy module should
exist, find out which package provides the offending resource and verify if
Gentoo offers a SELinux policy for that package. If it does, install it and
relabel the files of the package.
</p>
<pre caption="Finding Gentoo SELinux packages">
~# <i>tail -f /var/log/avc.log</i>
Jan 1 09:42:37 hpl kernel: [ 1372.708172] type=1400 audit(1293871357.972:76):
avc: denied { search } for pid=6937 comm="screen" name="selinux" dev=dm-0
ino=1053303 scontext=staff_u:staff_r:staff_t
tcontext=staff_u:object_r:user_home_t tclass=dir
~# <i>whereis screen</i>
screen: /usr/bin/screen
~# <i>qfile /usr/bin/screen</i>
app-misc/screen (/usr/bin/screen)
~# <i>eix selinux-screen</i>
* sec-policy/selinux-screen
Available versions: ~2.20090730 ~2.20091215 ~2.20101213
Homepage: http://www.gentoo.org/proj/en/hardened/selinux/
Description: SELinux policy for general applications
~# <i>emerge selinux-screen</i>
[...]
~# <i>rlpkg screen</i>
Relabeling: app-misc/screen-4.0.3
</pre>
<p>
If you believe a SELinux policy module should exist but you cannot find one,
then you can either download the reference policy tarball (which you might find
in your <path>distfiles</path> directory - it is called
<path>refpolicy-2.YYYYMMDD.tar.bz2</path>) and see if there are already modules
available (look inside the <path>refpolicy/policy/modules</path> location) or
ask around on #gentoo-hardened on irc.freenode.net.
</p>
</body>
</subsection>
<subsection>
<title>Updating the Security Contexts of Files</title>
<body>
<p>
The most common case of denials when the necessary policies are in place are
wrongly labeled files or directories (in other words, the security context of
the target file or directory is not what the policy would expect). This can be
either because the file has not been (re)labeled after the policy has been
loaded or because the label has for some reason changed (case 1) or because
the path of the file is not in accordance to the file context specifications
in the SELinux module (case 2).
</p>
<p>
The first possibility (security context correct in policy, but not applied) can
be easily fixed using the <c>restorecon</c> command. You can apply it against a
single file, or run it recursively using the <c>-R</c> option.
</p>
<pre caption="Running restorecon to restore a security context">
~# <i>restorecon /etc/make.conf</i>
</pre>
<p>
If the file context definition in the policy however doesn't apply to the file
(or directory), you can still tell your system to label the file or directory
accordingly. For instance, say you have your <path>lvm.conf</path> file inside
<path>/etc</path> rather than <path>/etc/lvm</path> as the policy would expect,
then you can still label the file correctly using <c>semanage</c>. With
<c>semanage</c>, you assign a correct security context unrelated to any
module. It is a local setting - but which is persistent across reboots.
</p>
<pre caption="Setting a new file context using semanage">
~# <i>semanage fcontext -a -t lvm_etc_t /etc/lvm.conf</i>
~# <i>restorecon /etc/lvm.conf</i>
</pre>
<p>
If you want to make such a definition part of a module you're writing, you will
need to create a file context file which contains the definition(s) for the
files whose context you want to set. Its syntax can be obtained through the
<path>/etc/selinux/strict/contexts/files/file_contexts</path> (or
<path>.../targeted/...</path>).
</p>
<pre caption="Getting the example file context syntax">
<comment>[ Capture the syntax for a file ]</comment>
~# <i>tail /etc/selinux/strict/contexts/files/file_contexts</i>
/opt/vmware/workstation/lib/lib/wrapper-gtk24\.sh -- system_u:object_r:bin_t
[...]
</pre>
<p>
By just blindly copying the syntax for our example, this would yield:
</p>
<pre caption="Sample file context syntax for /etc/lvm.conf">
/etc/lvm\.conf -- system_u:object_r:lvm_etc_t
</pre>
<p>
Assuming this is stored in <path>fixlvm.fc</path> you can create the module
as follows.
</p>
<pre caption="Creating the fixlvm module">
~# <i>semodule_package -o fixlvm.pp -m fixlvm.mod -f fixlvm.fc</i>
</pre>
</body>
</subsection>
<subsection>
<title>Creating Specific Allow Rules</title>
<body>
<p>
If a denial isn't resolved through an available SELinux policy module or a
corrective action taken against the target file or directory, or there
is no such module available, then you might opt to create your own policy. If
your goal is to allow a specific set of rules (rather than to write a
full-fledged SELinux policy module) then you can use the <c>audit2allow</c> tool
to generate a policy based on the denial logs.
</p>
<p>
With <c>audit2allow</c>, you can transform an AVC denial message into a SELinux
policy module definition. This can then be compiled into a binary policy module
and finally packaged into an easily (re)loadable SELinux policy module. It is
recommended to keep the (raw) AVC logs that you use to build the SELinux policy
module as this will allow you to continuously update the module when new denials
occur.
</p>
<p>
For instance, to allow some <c>sudo</c>-related denials, you can do the
following steps...
</p>
<pre caption="Generating, building and inserting a SELinux policy">
<comment>[ We append the AVC messages to the sudo.raw file so that, in the future, we can
add additional denial messages inside the same raw file which will be used to
build a new SELinux policy module ]</comment>
~# <i>grep 'comm="sudo"' /var/log/avc.log >> sudo.raw</i>
<comment>[ We generate a module definition called 'fixsudo' based on the captured AVC denials ]</comment>
~# <i>cat sudo.raw | audit2allow -m fixsudo > fixsudo.te</i>
<comment>[ Next we build the SELinux module ]</comment>
~# <i>checkmodule -m -o fixsudo.mod fixsudo.te</i>
~# <i>semodule_package -o fixsudo.pp -m fixsudo.mod</i>
</pre>
<p>
The generated policy module (with the <path>.pp</path> suffix) can then be
dynamically loaded into the SELinux policy store:
</p>
<pre caption="Loading the generated module">
~# <i>semodule -i fixsudo.pp</i>
</pre>
<p>
The module definition (in our example called <path>fixsudo.te</path>) can be
modified as you please - it's content is standard ASCII, human readable.
</p>
<p>
Not all denials that you might get are bugs in the default security policy.
It is very probable that you use your system in a slightly different way than
intended within the Gentoo Hardened SELinux default policy. However, if you
believe that you had to change your runtime policy due to a bug in the
current policy, please report it on <uri
link="https://bugs.gentoo.org">Bugzilla</uri> so that the Gentoo Hardened
SELinux developers can take a look at it. Also, don't hesitate to contact
the Gentoo Hardened SELinux developers if you are uncertain about things.
</p>
<p>
They don't bite. They get fed regularly so they don't have to.
</p>
</body>
</subsection>
</section>
<section>
<title>Working with SELinux</title>
<subsection>
<title>Loading and Unloading of Modules</title>
<body>
<p>
We have already crossed SELinux modules quite a few times. You even saw that, in
order to load a module, you can use <c>semodule -i modulename.pp</c>. The
<c>semodule</c> command offers the following functions:
</p>
<ul>
<li>
With <c>semodule -u modulename.pp</c> you upgrade an existing installed
module with a new version of this module
</li>
<li>
With <c>semodule -r modulename.pp</c> you remove a module from the SELinux
policy store. It will not be reloaded, not even after a reboot.
</li>
<li>
With <c>semodule -R</c> you reload the policies. An interesting feature here
is that you can add <c>-D</c> which will <e>disable</e> the <e>dontaudit</e>
rules from the policy. This can be useful, especially later in enforcing
mode, to find out why something is failing even though you get no denials.
</li>
<li>
With <c>semodule -B</c> you force a rebuild of the policy (which includes by
default a reload of the policy as well). Amongst some other things, such a
rebuild will read up on the existing users' and their home directories and
create the associated domains.
</li>
</ul>
</body>
</subsection>
<subsection>
<title>Listing Modules</title>
<body>
<p>
With the <c>semodule -l</c> command you can get an overview of the installed
modules, together with their current version. When you have issues with SELinux
policies and are trying to get online help on the matter, knowing the version of
the particular module is important to help you troubleshoot problems.
</p>
<pre caption="Listing the installed modules">
~# <i>semodule -l</i>
dbus 1.14.0
dnsmasq 1.9.0
hal 1.13.0
[...]
</pre>
</body>
</subsection>
<subsection>
<title>Switching Roles</title>
<body>
<p>
When you are working with a SELinux system, your default users will be using the
user_u SELinux login (and as such the user_r SELinux role) so they will not need
to perform any role switching: there are no other roles they can switch to.
</p>
<p>
Accounts that you use to perform more administrative tasks however are most
likely mapped to the staff_u SELinux login or have their own login but with the
same roles supported: staff_r and sysadm_r. These accounts should by default
start within the staff_r role. Although still restricted, it has more
possibilities (with respect to supported target domains to transition to)
than the user_r role.
</p>
<p>
The major difference however is that these users will also have to switch roles
from time to time. For instance, if you want to use Portage - even just for
querying the tree - you will need to be in the sysadm_r role. To switch roles,
use the <c>newrole</c> command:
</p>
<pre caption="Switching roles">
~$ <i>newrole -r sysadm_r</i>
Password: <comment>(Enter your personal password)</comment>
~$
</pre>
<p>
With <c>id -Z</c> you can verify that you have indeed successfully switched
roles.
</p>
<p>
Now how do you know that you need to switch roles? Generally, you will get a
<e>Permission denied</e> statement on one or more files:
</p>
<pre caption="Getting to know when to switch roles">
~$ <i>emerge --info</i>
Permission denied: '/etc/make.conf'
</pre>
<p>
You might not be able, from within your current role, to find out if switching
roles is sufficient to gain read access. Within your current role, you might not
be able to get to view the current security context or query the SELinux AV
rules. But if you switch to the sysadm_r role and run the necessary queries, you
might get the information you need:
</p>
<pre caption="Verifying read access against the /etc/make.conf file">
~$ <i>id -Z</i>
staff_u:staff_r:staff_t
~$ <i>newrole -r sysadm_r</i>
Password: <comment>(Enter your personal password)</comment>
~$ <i>id -Z</i>
staff_u:sysadm_r:sysadm_t
~$ <i>ls -Z /etc/make.conf</i>
system_u:object_r:portage_conf_t /etc/make.conf
~$ <i>sesearch -t portage_conf_t -c file -p read -A -d</i>
Found 8 semantic av rules:
allow portage_t portage_conf_t : file { ioctl read getattr lock execute execute_no_trans open } ;
<comment># This is the one we are looking for</comment>
allow sysadm_t portage_conf_t : file { ioctl read write ... } ;
allow portage_fetch_t portage_conf_t : file { ioctl read getattr lock open } ;
allow restorecond_t portage_conf_t : file { ioctl read getattr lock relabelfrom relabelto open } ;
allow gcc_config_t portage_conf_t : file { ioctl read getattr lock open } ;
allow portage_sandbox_t portage_conf_t : file { ioctl read getattr lock open } ;
allow rsync_t portage_conf_t : file { ioctl read getattr lock open } ;
allow mount_t portage_conf_t : file { ioctl read getattr lock open } ;
</pre>
<p>
As you can see, the sysadm_t domain (which is affiliated with the sysadm_r role)
has the necessary read access, whereas there is no sign of any read access for
the staff_t domain.
</p>
</body>
</subsection>
<subsection>
<title>Using File Labels</title>
<body>
<p>
During regular system usage, you will get into situations where you need to set
file labels (security contexts). We have already covered the use of
<c>semanage</c> and <c>restorecon</c> to do so, but a few other methods exist as
well, each of them for specific purposes...
</p>
<p>
With <c>chcon</c> users (and not only administrators) can relabel files (if they
have the necessary privileges to do so) to the type they want. As an example,
consider the domains and rules for the Mozilla applications (such as firefox).
By default, this domain has no ability to create new files in the user home
directory. However, a specific domain has been created (mozilla_home_t) in which
the application can create files. By creating a folder (say
<path>Downloads</path>) and relabeling it correctly, the application is able to
create new files inside this location.
</p>
<pre caption="Relabelling a directory">
~$ <i>ls -Zd ~/Downloads</i>
staff_u:object_r:user_home_t Downloads/
~$ <i>chcon -t mozilla_home_t ~/Downloads</i>
~$ <i>ls -Zd ~/Downloads</i>
staff_u:object_r:mozilla_home_t
</pre>
<p>
It is important to understand that relabeling is a specific privilege which is
also governed by SELinux policies (the staff_t domain has this privilege on the
user_home_t domain). Also, the target domain (mozilla_home_t) is still
manageable by the staff_t domain (including relabeling) so that the relabeling
activity doesn't lower the privileges that staff_t has on this folder. This
isn't always the case, so be careful when you relabel.
</p>
<p>
Relabelling files is governed by the relabelfrom and relabelto privileges.
Consider the following two hypothetical rules:
</p>
<pre caption="Relabelling rules">
allow staff_t foo_t : dir { relabelfrom relabelto };
allow staff_t bar_t : dir { relabelto };
</pre>
<p>
In the first rule, the staff_t domain has the ability to relabel directories
that are currently in the foo_t domain (relabelfrom) and to relabel directories
to the foo_t domain (if their source domain has a correct relabelfrom
privilege). In the second rule, the staff_t domain is only able to relabel
directories to the bar_t domain. However, once a directory has the bar_t domain,
the staff_t domain has no ability to relabel it to something else (no
relabelfrom privilege).
</p>
</body>
</subsection>
<subsection>
<title>Relabelling Gentoo Package Content</title>
<body>
<p>
As a last section let's talk about Gentoo support for relabeling files. By
default, Portage will relabel all files of a package once it is installed. This
is governed by the FEATURES="selinux" setting which is enabled when you select
the selinux profiles. An administrator can also relabel the contents of a
package using the (Gentoo-specific) <c>rlpkg</c> command (installed through
the policycoreutils package):
</p>
<pre caption="Relabelling the files and directories of a package">
~# <i>rlpkg net-tools</i>
Relabeling: sys-apps/net-tools-1.60_p20090728014017-r1
</pre>
<p>
The same tool can be used to relabel the entire system:
</p>
<pre caption="Relabelling the entire (file) system">
~# <i>rlpkg -a -r</i>
</pre>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/en/hardened/selinux/hb-using-policymodules.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-policymodules.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-policymodules.xml?rev=1.1&content-type=text/plain
Index: hb-using-policymodules.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-policymodules.xml,v 1.1 2011/03/26 23:29:55 zorry Exp $ -->
<sections>
<version>1</version>
<date>2011-03-02</date>
<section>
<title>Writing Simple Policies</title>
<subsection>
<title>Writing a TE File</title>
<body>
<p>
Let us summarize our previous experiences with writing simple policies. We have
already covered how to write a <path>.te</path> file and convert it to a
loadable SELinux module. Let's go over this once again with a simple example:
allowing execmem for the mozilla_t domain.
</p>
<p>
When using the <path>selinux-mozilla</path> provided SELinux module, you might
still get a failure if you are using the 32-bit binary firefox package
(<path>www-client/firefox-bin</path>) and if you do not allow memexec (see the
<c>allow_memexec</c> boolean). You will probably find an AVC denial telling you
this exact same thing. If you want to allow just mozilla_t to run execmem, you
can write the following <path>fixmozilla.te</path> module:
</p>
<pre caption="Content of fixmozilla.te">
module fixmozilla 1.0.0;
require {
type mozilla_t;
class process execmem;
}
allow mozilla_t self:process { execmem };
</pre>
<p>
This simple policy sais that the module is called <e>fixmozilla</e> with module
version <e>1.0.0</e> (it is wise to update this version every time you update
the content of the module so that you can quickly verify with <c>semodule -l</c>
if the new version is loaded or not). It requires the <e>mozilla_t</e> domain
(if <path>sec-policy/selinux-mozilla</path> isn't installed, loading of this
policy will fail as it will not find the mozilla_t domain) and the
<e>process</e> class with the <e>execmem</e> operation. The policy itself
(the AVC statement) is to allow the mozilla_t domain to use execmem on its
own processes.
</p>
<p>
To convert this source into a loadable policy, we first convert it into a
<path>.mod</path> file:
</p>
<pre caption="Converting a .te file to a .mod file">
~$ <i>checkmodule -m -o fixmozilla.mod fixmozilla.te</i>
</pre>
<p>
In this particular command, we create a non-base (<c>-m</c>) module file
(<path>fixmozilla.mod</path>) which contains the statements offered by the
<path>fixmozilla.te</path> file. If you are running an MLS/MCS system you will
need to add the <c>-M</c> option.
</p>
<p>
Next we package this module into a loadable SELinux module:
</p>
<pre caption="Packaging the .mod file to a loadable SELinux module">
~$ <i>semodule_package -o fixmozilla.pp -m fixmozilla.mod</i>
</pre>
<p>
This final module file (<path>fixmozilla.pp</path>) can then be loaded into the
SELinux policy store using <c>semodule -i fixmozilla.pp</c>.
</p>
<p>
Using this relatively simple method, you can create all the policy rules you
want. However, you most likely want to add information on file labeling as
well...
</p>
</body>
</subsection>
<subsection>
<title>Writing an FC File</title>
<body>
<p>
An FC file (<e>File Context</e>) contains the file labels (security contexts)
that should be assigned to particular files. If you structure your modules
correctly, you most likely have policies for particular programs, and you would
like to label the program files and binaries accordingly. This is what the
<path>.fc</path> files are for.
</p>
<p>
Let's take a look at a sample .fc file which contains the various types of
context definitions that are supported:
</p>
<pre caption="Sample .fc file">
/var/.* gen_context(system_u:object_r:var_t)
/dev/.*tty[^/]* -c gen_context(system_u:object_r:tty_device_t)
/dev/p[fg][0-3] -b gen_context(system_u:object_r:removable_device_t)
/vmlinuz.* -l gen_context(system_u:object_r:boot_t)
/usr/bin/firefox -- gen_context(system_u:object_r:mozilla_exec_t)
/tmp/\.ICE-unix/.* -s <<none>>
/dev/initctl -p gen_context(system_u:object_r:initctl_t)
/mnt(/[^/]*)? -d gen_context(system_u:object_r:mnt_t)
</pre>
<p>
The first column (in every line) starts with a regular expression to match
against a file's path. This is usually sufficient to match any possible file.
SELinux does support some special variables like ROLE, HOME_DIR, HOME_ROOT and
USER which are substituted with their corresponding values when the file context
is (re)compiled (for instance when you add or delete SELinux users or rebuild
the policy using <c>semodule</c>).
</p>
<p>
The second column, if available, starts with a dash followed by the file type:
<c>c</c>haracter device, <c>b</c>lock device, symbolic <c>l</c>ink,
<c>s</c>ocket, <c>d</c>irectory, named <c>p</c>ipe or a regular file (<c>-</c>).
</p>
<p>
The last column gives the security context (label) that should be assigned to
the resource(s) that match the regular expression. You should always see the
"standard three" (user, role, domain), but you might also see the security level
and even category if MLS/MCS is used or supported by the module.
</p>
<pre caption="Sample file context with MLS/MCS support">
/usr/tmp -d gen_context(system_u:object_r:tmp_t,s0-s15,c0.c255)
</pre>
<p>
You can write your own FC file. For instance, Gentoo adds the following
definition to the <path>sec-policy/selinux-mozilla</path> package to support the
binary firefox package:
</p>
<pre caption="Example .fc content">
/usr/bin/firefox-bin -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/opt/firefox/libxul\.so -- gen_context(system_u:object_r:textrel_shlib_t,s0)
/opt/firefox/firefox -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/opt/firefox/run-mozilla.sh -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/opt/firefox/firefox-bin -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/opt/firefox/plugin-container -- gen_context(system_u:object_r:mozilla_exec_t,s0)
</pre>
<p>
If you want to add such a file to your policy, add it during the
<c>semodule_package</c> phase:
</p>
<pre caption="Adding file context information to a policy">
~$ <i>semodule_package -o fixmozilla.pp -m fixmozilla.mod -f fixmozilla.fc</i>
</pre>
<p>
Once this policy is loaded, you can use tools like <c>matchpathcon</c>,
<c>restorecon</c> and more as they now know how to deal with the files you have
mentioned in your file context file.
</p>
</body>
</subsection>
</section>
<section>
<title>Building a Reference Policy Module</title>
<subsection>
<title>Introduction to the Reference Policy</title>
<body>
<p>
Initially we have already covered the fact that Gentoo Hardened bases its
policies on the reference policy maintained by Tresys. This reference policy
offers an important additional functionality during module development:
interfaces.
</p>
<p>
By creating an interface, you actually create a function of some sort which can
be used in other modules. Such interfaces allow module writers to generate rules
to interact with the domain of their module without knowing what the other
domains are. For instance, the mozilla module has an interface definition like
so:
</p>
<pre caption="Example interface definition">
interface(`mozilla_read_user_home_files',`
gen_require(`
type mozilla_home_t;
')
allow $1 mozilla_home_t:dir list_dir_perms;
allow $1 mozilla_home_t:file read_file_perms;
allow $1 mozilla_home_t:lnk_file read_lnk_file_perms;
userdom_search_user_home_dirs($1)
')
</pre>
<p>
This interface allows other modules to use the
<c>mozilla_read_user_home_files</c> function if they want their domain to be
able to (in this case) read the files in the mozilla_home_t domain. Of course,
they can add all statements inside their own definition, but then they would
have to require that the mozilla module is loaded, which might be a wrong
assumption, and duplicate the same allow statements for each application.
The use of interfaces makes policy development easier.
</p>
<p>
Also, the reference policy allows the use of <e>optional</e> statements:
a module can call an interface of another module, but this may not fail if
the other module is not available on a users' system.
</p>
<p>
For instance, in the evolution policy:
</p>
<pre caption="Extract from evolution.te">
optional_policy(`
mozilla_read_user_home_files(evolution_t)
mozilla_domtrans(evolution_t)
')
</pre>
<p>
In this extract we see that the previously defined interface is called with
argument evolution_t (the Evolution domain) within an <c>optional_policy</c>
clause. As a result, building this policy will attempt to call this interface,
but if the interface is missing (because the mozilla module isn't installed) it
will not fail the build of the evolution module.
</p>
<p>
Using the interfaces allows for a clean separation of the various modules.
Within the reference policy, the following guidelines are used:
</p>
<ul>
<li>
Inside a <path>.te</path> file, the only domains that are allowed to be
mentioned are those defined in the same <path>.te</path> file. Any
interaction with other domains need to happen through interfaces offered by
that domain.
</li>
<li>
Inside an <path>.if</path> file, where the interfaces are defined, an XML
like syntax is used to document each interface, allowing for developers to
read easily what an interface is meant to do (because honestly, there are
far more complex interfaces than the one we have previously shown)
</li>
<li>
Distribution-specific aspects of modules should be enclosed within a
<c>ifdef(`distro_gentoo',`...')</c> statement (example for Gentoo). This
statement is supported in all three files (<path>.te</path>,
<path>.if</path> and <path>.fc</path>).
</li>
</ul>
</body>
</subsection>
<subsection>
<title>Building the Reference Policy Module</title>
<body>
<p>
If you want to build a module using the reference policy interfaces, you first
need to create the <path>.te</path> file and, optionally (but most likely
needed) <path>.if</path> and <path>.fc</path> file. It is wise to start from an
example set of files for a similar application. If you want to or need to use
interfaces of different modules, you can find the interfaces that are valid on
your system inside <path>/usr/share/selinux/strict/include</path>.
</p>
<p>
Once you want to build the module, copy the
<path>/usr/share/selinux/strict/include/Makefile</path> file inside the
directory where your policy definition(s) are stored. Then, call the <c>make</c>
command to build the policy modules.
</p>
<p>
The result should be one (or more) loadable SELinux modules.
</p>
</body>
</subsection>
</section>
<section>
<title>Example: Start Building the Skype Policy</title>
<subsection>
<title>Labelling</title>
<body>
<p>
Let's start to create a sample reference policy based SELinux module for the <c>skype</c>
application. This application is a well-known application used to perform voice-
and video chats across the Internet. We will not finish the module in this
chapter (as the exercise will become a repetitive try-and-correct cycle which
isn't the purpose to document here) but rather show an approach on how to deal
with such policy building exercises.
</p>
<p>
First get acquainted with the application.
</p>
<p>
The usual way of interacting with <c>skype</c> is from an end-user point (not
administrator). From interacting with it in permissive mode (or from a
non-SELinux system) we know it creates a <path>~/.Skype</path> folder for its
configuration, chat history and more.
</p>
<p>
Given this above information, let's take a look at the content of the
<path>net-im/skype</path> package:
</p>
<pre caption="Content of the skype package">
~$ <i>qlist skype</i>
<comment>(Output shortened for clarity)</comment>
/usr/bin/skype
/usr/share/... <comment># Unrelated to the application but used by distribution</comment>
/opt/skype/skype
/opt/skype/sounds/...
/opt/skype/lang/...
/opt/skype/avatars/...
</pre>
<p>
Given this information, we could create the following file context definition:
</p>
<pre caption="Sample file context for skype">
/usr/bin/skype -- gen_context(system_u:object_r:skype_exec_t,s0)
/opt/skype/skype -- gen_context(system_u:object_r:skype_exec_t,s0)
HOME_DIR/\.Skype(/.*)? gen_context(system_u:object_r:skype_home_t,s0)
</pre>
<p>
We will not give the various skype files a specific label - they are all
read-only files so can keep the default label assigned to them.
</p>
<p>
Within the <path>skype.te</path> file, we define the necessary domains and
also use the first interfaces which are often associated with this kind of
domains (for reasoning you can read the sources for the apache module or
other services). A sample module to base our definition from could be
telepathy...
</p>
<pre caption="Initial skype module definition">
policy_module(skype, 1.0.0)
type skype_t;
type skype_exec_t;
application_domain(skype_t, skype_exec_t)
type skype_home_t;
userdom_user_home_content(skype_home_t)
# Allow skype_t to put files in the skype_home_t location(s)
manage_dirs_pattern(skype_t, skype_home_t, skype_home_t)
manage_files_pattern(skype_t, skype_home_t, skype_home_t)
userdom_user_home_dir_filetrans(skype_t, skype_home_t, { dir file })
userdom_search_user_home_dirs(skype_t)
</pre>
<p>
Again, we're not going to cover the various interfaces and explain them. They
are documented and available on the system, and there are plenty of examples to
use.
</p>
<p>
Finally, we are going to create an interface to allow users to transition to the
skype_t domain. The idea here is that you add <c>skype_role(role, domain)</c> in
the <path>.te</path> definition of the users' domain or within your own policy.
</p>
<pre caption="Defining the skype_role interface">
interface(`skype_role',`
gen_require(`
type skype_t, skype_exec_t;
')
role $1 types skype_t;
domain_auto_trans($2, skype_exec_t, skype_t)
')
</pre>
<p>
Build the module and load it in the SELinux module store. Next, create a small
policy to allow users (user_r, user_t) to access skype:
</p>
<pre caption="Adding access to skype for users">
~$ <i>cat skypeusers.te</i>
policy_module(skypeusers, 1.0.0)
gen_require(`
type user_t;
role user_r;
type staff_t;
role staff_r;
')
optional_policy(`
skype_role(user_r, user_t)
skype_role(staff_r, staff_t)
')
</pre>
<p>
Build that module as well and load it. A regular SELinux user should now have
the ability to execute skype_exec_t and transition to the skype_t domain.
</p>
</body>
</subsection>
<subsection>
<title>Dry Run</title>
<body>
<p>
With the policy loaded, do a dry run. Relabel the files of the
<path>net-im/skype</path> package (and if you have previously ran skype yourself,
relabel the <path>~/.Skype</path> folder as well), then start <c>skype</c> and both
watch skype's output as well as the AVC denials.
</p>
<p>
We notice that the binary (skype) hangs and cannot be killed. In the AVC denial
logs, we notice the following denials:
</p>
<pre caption="Shown denials while running skype">
Jan 6 22:01:56 hpl kernel: [18418.420427] type=1400 audit(1294347716.358:2221):
avc: denied { read write } for pid=25540 comm="skype" name="1" dev=devpts
ino=4 scontext=staff_u:staff_r:skype_t tcontext=staff_u:object_r:user_devpts_t
tclass=chr_file
Jan 6 22:01:56 hpl kernel: [18418.420455] type=1400 audit(1294347716.358:2222):
avc: denied { use } for pid=25540 comm="skype" path="/dev/pts/1" dev=devpts
ino=4 scontext=staff_u:staff_r:skype_t tcontext=staff_u:staff_r:staff_t
tclass=fd
Jan 6 22:01:56 hpl kernel: [18418.420563] type=1400 audit(1294347716.358:2225):
avc: denied { sigchld } for pid=6532 comm="bash"
scontext=staff_u:staff_r:skype_t tcontext=staff_u:staff_r:staff_t tclass=process
</pre>
<p>
Note that the attempt is done in enforcing mode - running in permissive mode
will yield more AVC denials and is also a plausible way to create the necessary
rules.
</p>
<p>
From the denials, we see that skype attempts to use the pts in which the command
is ran (notice that this fails because we didn't explicitly allow it) and also
fails to exit properly (a sigchld signal isn't allowed to be submitted).
</p>
<p>
By looking into the example policies already around, we notice that they have
interfaces in use such as <c>userdom_use_user_terminals</c> as well as generic
allowances such as <c>ps_process_pattern</c> (to allow users to view a process
and kill it). This is a nice example of how a type enforcement MAC system works:
nothing is assumed by default.
</p>
</body>
</subsection>
<subsection>
<title>Next Dry Run</title>
<body>
<p>
So after adding some interfaces to allow the use of the user terminals, file
descriptors and also allow process signals to be sent, we try to run the
application again. Now, we get:
</p>
<pre caption="Output of running the skype command">
~$ <i>skype</i>
Killed
~$ <i>cat /var/log/avc.log</i>
Jan 6 22:27:41 hpl kernel: [19961.313321] type=1400
audit(1294349261.991:9089017): avc: denied { execmem } for pid=27256
comm="skype" scontext=staff_u:staff_r:skype_t tcontext=staff_u:staff_r:skype_t
tclass=process
</pre>
<p>
At least <c>skype</c> now exits. From the AVC log, we see that it wants to call
execmem (which isn't something we like, but have seen in the past for mozilla as
well). Okay, let's allow this, rebuild the modules and retry.
</p>
<pre caption="Output of running the skype command again">
~$ <i>skype</i>
./skype: error while loading shared libraries: libasound.so.2: cannot open
shared object file: Permission denied
~$ <i>cat /var/log/avc.log</i>
Jan 6 22:33:41 hpl kernel: [20319.960127] type=1400
audit(1294349621.275:9089042): avc: denied { read } for pid=27536
comm="skype" name="libasound.so.2" dev=dm-1 ino=525098
scontext=staff_u:staff_r:skype_t tcontext=system_u:object_r:usr_t
tclass=lnk_file
</pre>
<p>
Okay, we need to grant it read rights to links within the usr_t domain (and most
likely then load libraries from the lib_t domain, so we need to add
<c>files_read_usr_symlinks</c> and <c>libs_use_ld_so</c>, etc.
</p>
</body>
</subsection>
<subsection>
<title>Finishing Up</title>
<body>
<p>
After running into the standard "can't start" issues, you'll notice that the
application then wants to bind and connect to ports - which are also protected
by SELinux and can be manipulated by various interfaces. It wants to access your
soundcard and webcam, etc.
</p>
<p>
As you can see from the above information, writing policies correctly isn't
easy. You need to constantly keep in mind what you are allowing - aren't you
granting too much? Are you forgetting something? Also, the first time(s) you
create policies it will take lots of time, but over time you will grow better in
it. You'll start realizing what all those standard things are that you need to
allow and what not.
</p>
<p>
Writing SELinux policies isn't hard, but it's far more difficult than setting
the standard Linux permissions on files and directories. It requires a decent
knowledge of how the application behaves and what the SELinux reference policy
interfaces grant when you select them.
</p>
<p>
If you ever feel like writing these policies, don't hesitate to read up on the
various resources at the end of this book.
</p>
</body>
</subsection>
</section>
</sections>
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2011-03-26 23:30 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-26 23:29 [gentoo-commits] gentoo commit in xml/htdocs/proj/en/hardened/selinux: hb-appendix-reference.xml hb-appendix-troubleshoot.xml hb-intro-concepts.xml hb-intro-enhancingsecurity.xml hb-intro-referencepolicy.xml hb-intro-virtualization.xml hb-selinux-conv-reboot1.xml hb-selinux-conv-reboot2.xml hb-using-commands.xml hb-using-enforcing.xml hb-using-install.xml hb-using-permissive.xml hb-using-policymodules.xml index.xml selinux-handbook.xml Magnus Granberg (zorry)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox