From: "Sven Vermeulen" <sven.vermeulen@siphos.be>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/hardened-docs:master commit in: xml/selinux/
Date: Sun, 23 Oct 2011 13:01:47 +0000 (UTC) [thread overview]
Message-ID: <2ddbc661e6b6470d9c35363bbfc1fea574ebc7af.SwifT@gentoo> (raw)
commit: 2ddbc661e6b6470d9c35363bbfc1fea574ebc7af
Author: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
AuthorDate: Sun Oct 23 13:00:43 2011 +0000
Commit: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
CommitDate: Sun Oct 23 13:00:43 2011 +0000
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=2ddbc661
Remove obsolete documents
---
xml/selinux/hb-using-enforcing.xml | 224 -----------
xml/selinux/hb-using-permissive.xml | 666 --------------------------------
xml/selinux/hb-using-policymodules.xml | 576 ---------------------------
3 files changed, 0 insertions(+), 1466 deletions(-)
diff --git a/xml/selinux/hb-using-enforcing.xml b/xml/selinux/hb-using-enforcing.xml
deleted file mode 100644
index ca626c3..0000000
--- a/xml/selinux/hb-using-enforcing.xml
+++ /dev/null
@@ -1,224 +0,0 @@
-<?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.2 2011/04/25 20:12:59 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 in <uri
-link="?part=2&chap=3#create_module">Creating Specific Allow Rules</uri>):
-</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>
diff --git a/xml/selinux/hb-using-permissive.xml b/xml/selinux/hb-using-permissive.xml
deleted file mode 100644
index 2b331c7..0000000
--- a/xml/selinux/hb-using-permissive.xml
+++ /dev/null
@@ -1,666 +0,0 @@
-<?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.3 2011/06/07 19:46:52 klondike Exp $ -->
-
-<sections>
-<version>6</version>
-<date>2011-09-11</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 id="avclog">
-<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 Might 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 might be
-right. At this point, Gentoo Hardened is constantly updating the SELinux
-policies to get you a working system - but we're not fully 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>emerge --search selinux-screen</i>
-Searching...
-[ Results for search key : selinux-screen ]
-[ Applications found : 1 ]
-
-* sec-policy/selinux-screen
- Latest version available: 2.20110726
- Latest version installed: 2.20110726
- Size of files: 574 kB
- Homepage: http://www.gentoo.org/proj/en/hardened/selinux/
- Description: SELinux policy for screen
- License: GPL-2
-
-~# <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 and
-relabelling activities.
-</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. Writing policy modules is described later
-in this book in <uri link="?part=2&chap=5">Adding SELinux Policy
-Modules</uri>.
-</p>
-
-</body>
-</subsection>
-<subsection id="create_module">
-<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 -i modulename.pp</c> you (re)install a module (or install
- a higher version of said module)
- </li>
- <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>
diff --git a/xml/selinux/hb-using-policymodules.xml b/xml/selinux/hb-using-policymodules.xml
deleted file mode 100644
index 3032bcb..0000000
--- a/xml/selinux/hb-using-policymodules.xml
+++ /dev/null
@@ -1,576 +0,0 @@
-<?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.5 2011/06/07 19:46:52 klondike 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>
next reply other threads:[~2011-10-23 13:02 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-23 13:01 Sven Vermeulen [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-05-07 20:20 [gentoo-commits] proj/hardened-docs:master commit in: xml/selinux/ Sven Vermeulen
2012-05-07 20:07 Sven Vermeulen
2012-05-05 18:56 Sven Vermeulen
2012-04-29 14:22 Sven Vermeulen
2012-04-10 18:22 Sven Vermeulen
2012-04-10 18:22 Sven Vermeulen
2012-04-10 18:22 Sven Vermeulen
2012-04-05 16:24 Sven Vermeulen
2012-03-01 20:09 Sven Vermeulen
2012-01-29 12:42 Sven Vermeulen
2012-01-21 13:20 Sven Vermeulen
2011-12-17 10:52 Sven Vermeulen
2011-12-11 14:39 Sven Vermeulen
2011-12-11 14:36 Sven Vermeulen
2011-12-10 14:00 Sven Vermeulen
2011-11-22 20:08 Sven Vermeulen
2011-11-11 19:59 Sven Vermeulen
2011-10-27 19:18 José María Alonso
2011-10-26 22:05 José María Alonso
2011-10-19 12:55 Sven Vermeulen
2011-10-15 18:24 Sven Vermeulen
2011-10-15 17:43 Sven Vermeulen
2011-10-15 17:12 Sven Vermeulen
2011-10-15 15:54 Sven Vermeulen
2011-10-15 15:18 Sven Vermeulen
2011-10-15 13:04 Sven Vermeulen
2011-10-15 13:04 Sven Vermeulen
2011-09-30 17:36 Sven Vermeulen
2011-09-18 13:49 Sven Vermeulen
2011-09-11 9:51 Sven Vermeulen
2011-09-04 19:22 Sven Vermeulen
2011-08-16 16:58 José María Alonso
2011-08-12 21:00 Sven Vermeulen
2011-07-22 16:03 Sven Vermeulen
2011-07-21 19:11 Sven Vermeulen
2011-07-13 21:39 Sven Vermeulen
2011-07-09 18:56 Sven Vermeulen
2011-06-09 18:54 José María Alonso
2011-06-09 17:49 Sven Vermeulen
2011-06-09 17:40 Francisco Blas Izquierdo Riera
2011-06-09 17:24 Sven Vermeulen
2011-06-07 19:38 Sven Vermeulen
2011-06-07 19:26 Sven Vermeulen
2011-06-02 19:50 Sven Vermeulen
2011-06-02 11:57 Sven Vermeulen
2011-06-02 11:55 Sven Vermeulen
2011-06-02 11:03 Sven Vermeulen
2011-06-02 11:03 Sven Vermeulen
2011-05-31 20:22 Sven Vermeulen
2011-05-31 20:16 Sven Vermeulen
2011-05-31 20:16 Sven Vermeulen
2011-05-24 20:39 Sven Vermeulen
2011-05-24 19:56 Sven Vermeulen
2011-05-20 19:32 Sven Vermeulen
2011-05-14 12:51 Sven Vermeulen
2011-05-13 19:43 Sven Vermeulen
2011-05-03 20:47 Sven Vermeulen
2011-05-03 20:12 Sven Vermeulen
2011-04-22 21:43 Sven Vermeulen
2011-04-22 19:30 Sven Vermeulen
2011-04-22 19:28 Sven Vermeulen
2011-04-22 19:05 Sven Vermeulen
2011-04-22 19:05 Sven Vermeulen
2011-04-22 10:32 Sven Vermeulen
2011-04-22 10:32 Sven Vermeulen
2011-04-16 9:06 Sven Vermeulen
2011-04-15 19:10 Sven Vermeulen
2011-04-15 17:52 Sven Vermeulen
2011-04-15 17:52 Sven Vermeulen
2011-04-10 7:49 Sven Vermeulen
2011-04-01 17:45 Sven Vermeulen
2011-03-09 16:54 Sven Vermeulen
2011-03-02 20:48 Sven Vermeulen
2011-03-02 20:38 Sven Vermeulen
2011-03-02 20:38 Sven Vermeulen
2011-03-02 20:13 Sven Vermeulen
2011-03-02 20:13 Sven Vermeulen
2011-03-02 20:13 Sven Vermeulen
2011-03-02 15:53 Sven Vermeulen
2011-02-24 21:19 Sven Vermeulen
2011-02-20 13:26 Sven Vermeulen
2011-02-19 17:00 Francisco Blas Izquierdo Riera
2011-02-19 3:21 Francisco Blas Izquierdo Riera
2011-02-19 3:12 Francisco Blas Izquierdo Riera
2011-02-13 18:20 Sven Vermeulen
2011-02-12 23:44 Sven Vermeulen
2011-02-12 23:44 Sven Vermeulen
2011-02-12 20:50 Sven Vermeulen
2011-02-12 20:49 Sven Vermeulen
2011-02-12 20:47 Sven Vermeulen
2011-02-12 20:47 Sven Vermeulen
2011-02-12 20:47 Sven Vermeulen
2011-02-12 17:33 Sven Vermeulen
2011-02-06 19:53 Sven Vermeulen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ddbc661e6b6470d9c35363bbfc1fea574ebc7af.SwifT@gentoo \
--to=sven.vermeulen@siphos.be \
--cc=gentoo-commits@lists.gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox