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: Sat, 15 Oct 2011 13:04:16 +0000 (UTC) [thread overview]
Message-ID: <772e60f6cd55d1189c4a1023fbf56cc036e510a7.SwifT@gentoo> (raw)
commit: 772e60f6cd55d1189c4a1023fbf56cc036e510a7
Author: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
AuthorDate: Thu Oct 13 19:17:05 2011 +0000
Commit: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
CommitDate: Thu Oct 13 19:17:05 2011 +0000
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=772e60f6
Lots of updates on file label management, also introduce booleans
---
xml/selinux/hb-using-configuring.xml | 374 +++++++++++++++++++++++++++++++++-
1 files changed, 372 insertions(+), 2 deletions(-)
diff --git a/xml/selinux/hb-using-configuring.xml b/xml/selinux/hb-using-configuring.xml
index 78ace4f..1a3f536 100644
--- a/xml/selinux/hb-using-configuring.xml
+++ b/xml/selinux/hb-using-configuring.xml
@@ -287,8 +287,378 @@ Within SELinux, access privileges are based on the label given on the
originating part (called the <e>domain</e>) and its target resource. For
instance, a process running in the passwd_t domain wants to read (= privilege)
the file <path>/etc/shadow</path> which is labeled shadow_t (= the target
-resouce). It comes to no surprise then that the majority of SELinux
-administration is (re)labeling the resources.
+resource). It comes to no surprise then that the majority of SELinux
+administration is (re)labeling the resources correctly (and ensuring their label
+stays correct).
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Getting File Label(s)</title>
+<body>
+
+<p>
+There are many ways to relabel commands, and none of them are equal to another.
+But before we explain this in more detail, let's first take a look at a few file
+labels (and how you can query them).
+</p>
+
+<p>
+In SELinux, labels are given on a file level through the file systems' ability
+to keep <e>extended attributes</e>. For SELinux, the attribute is called
+<c>security.selinux</c> and can be obtained through <c>getfattr</c>:
+</p>
+
+<pre caption="Getting a file's extended attribute for SELinux">
+$ <i>getfattr -n security.selinux /etc/hosts</i>
+# file: etc/hosts
+security.selinux="system_u:object_r:net_conf_t"
+</pre>
+
+<p>
+Of course, getting the file attribute this way is time consuming and not that
+flexible. For this purpose, most important applications (including
+<c>coreutils</c>) are made SELinux-aware. These applications mostly use the
+<c>-Z</c> option to display the SELinux context information. In case of files,
+this means the extended attribute content:
+</p>
+
+<pre caption="Getting the context of a file">
+$ <i>ls -Z /etc/hosts</i>
+system_u:object_r:net_conf_t /etc/hosts
+</pre>
+
+<p>
+Other commands exist that display the context as it should be, like
+<c>matchpathcon</c>. However, their purpose is to query the SELinux policy on
+your system to find out what the policy ought to be, not what it is:
+</p>
+
+<pre caption="Difference between context and matchpathcon result">
+$ <i>ls -Z /etc/make.conf</i>
+staff_u:object_r:etc_t /etc/make.conf
+$ <i>matchpathcon /etc/make.conf</i>
+/etc/make.conf system_u:object_r:portage_conf_t
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Setting File Label(s)</title>
+<body>
+
+<p>
+Now how can you manipulate file labels? Well, first of all: you will not be
+allowed to change the file labels of any possible file (not even if you are the
+owner of that file) unless the SELinux policy allows you to. These allow rules
+are made on two privilege types: which labels are you allowed to change
+(<c>relabelfrom</c>) and to which labels are you allowed to change
+(<c>relabelto</c>). You can query these rules through <c>sesearch</c>:
+</p>
+
+<pre caption="Querying the relabelto/relabelfrom types">
+<comment># From which label on files (-c) is user_t (-s) allowed (-A) to relabel from (-p)?</comment>
+$ <i>sesearch -s user_t -c file -p relabelfrom -A</i>
+<comment>[...]</comment>
+allow user_t mozilla_home_t : file { <comment>...</comment> relabelfrom relabelto } ;
+</pre>
+
+<p>
+If you have the permission, then you can use <c>chcon</c> to <e>ch</e>ange the
+<e>con</e>text of a file:
+</p>
+
+<pre caption="Changing a file context">
+$ <i>ls -Z strace.log</i>
+staff_u:object_r:user_home_t strace.log
+$ <i>chcon -t mutt_home_t strace.log</i>
+$ <i>ls -Z strace.log</i>
+staff_u:object_r:mutt_home_t strace.log
+</pre>
+
+<p>
+If you do not hold the right privileges, you will get a descriptive error
+message:
+</p>
+
+<pre caption="Trying to change file context">
+$ <i>chcon -t shadow_t strace.log</i>
+chcon: failed to change context of `strace.log' to `staff_u:object_r:shadow_t': Permission denied
+</pre>
+
+<p>
+Now, if you now think that <c>chcon</c> is all you need, you're wrong. The
+<c>chcon</c> command does nothing more than what it sais - change context. But
+when the system relabels files, these changes are gone. Relabeling files is
+often done to ensure that the file labels are correct (as in: the labels match
+what the SELinux policy sais they ought to be). The SELinux policy contains, for
+each policy module, the list of files, directories, sockets, ... and their
+appropriate file context (label).
+</p>
+
+<p>
+We will look at SELinux policy modules later, but below you'll find an excerpt
+from such a definition, for the <c>mozilla</c> module:
+</p>
+
+<pre caption="Excerpt of the mozilla module file contexts">
+/usr/bin/firefox-bin -- gen_context(system_u:object_r:mozilla_exec_t,s0)
+/usr/bin/mozilla-[0-9].* -- gen_context(system_u:object_r:mozilla_exec_t,s0)
+/usr/bin/mozilla-bin-[0-9].* -- gen_context(system_u:object_r:mozilla_exec_t,s0)
+/usr/lib(64)?/galeon/galeon -- gen_context(system_u:object_r:mozilla_exec_t,s0)
+/usr/lib(64)?/netscape/.+/communicator/communicator-smotif\.real -- gen_context(system_u:object_r:mozilla_exec_t,s0)
+/usr/lib(64)?/netscape/base-4/wrapper -- gen_context(system_u:object_r:mozilla_exec_t,s0)
+/usr/lib/[^/]*firefox[^/]*/plugin-container -- gen_context(system_u:object_r:mozilla_plugin_exec_t,s0)
+/usr/lib64/[^/]*firefox[^/]*/plugin-container -- gen_context(system_u:object_r:mozilla_plugin_exec_t,s0)
+</pre>
+
+<p>
+To put the right label on a file, you can use the <c>setfiles</c> or
+<c>restorecon</c> commands. Since they are both the same command (but with a
+slightly different way of using) we'll only talk about <c>restorecon</c> for now
+- more information on the <c>setfiles</c> command can be found in its man page.
+</p>
+
+<p>
+When you use <c>restorecon</c>, the application will query the SELinux policy to
+find out what the right label of the file should be. If it differs, it will
+change the label to the right setting. That means that you do not need to
+provide the label for a file in order for the command to work. Also,
+<c>restorecon</c> supports recursivity, so you do not need to relabel files one
+by one.
+</p>
+
+<pre caption="Using restorecon">
+$ <i>ls -Z /etc/make.conf</i>
+staff_u:object_r:etc_t /etc/make.conf
+$ <i>restorecon /etc/make.conf</i>
+$ <i>ls -Z /etc/make.conf</i>
+system_u:object_r:portage_conf_t /etc/make.conf
+</pre>
+
+<p>
+Finally, Gentoo also provides a useful application: <c>rlpkg</c>. This script
+relabels the files of a Gentoo package (<c>rlpkg <packagename></c>) or,
+given the right arguments, all files on the file system:
+</p>
+
+<pre caption="Using rlpkg">
+<comment># Relabel the files of the firefox-bin package:</comment>
+# <i>rlpkg firefox</i>
+
+<comment># Relabel all files on the file system:</comment>
+# <i>rlpkg -a -r</i>
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Overriding the SELinux Policy File Labels</title>
+<body>
+
+<p>
+You might not always agree with the label that the SELinux policy enforces on
+the files: you might have your files located elsewhere (a different location for
+your Portage tree is a nice example) or you need to label them differently in
+order for other applications to work. To not have to <c>chcon</c> these files
+over and over again, you can enhance the SELinux policy on your system with
+additional file context rules. These rules are used when you call
+<c>restorecon</c> as well and override the rules provided by the SELinux policy.
+</p>
+
+<p>
+To add additional file context rules, you need to use the <c>semanage</c>
+command. This command is used to manage, manipulate and update the local SELinux
+policy on your system. In this particular case, we will use the <c>semanage
+fcontext</c> command:
+</p>
+
+<pre caption="Using semanage to add a file context rule">
+<comment># Mark /mnt/gentoo/etc/make.conf as a portage_conf_t type</comment>
+# <i>semanage fcontext -a -t portage_conf_t /mnt/gentoo/etc/make.conf</i>
+
+<comment># Mark /mnt/gentoo/usr/portage as portage_ebuild_t</comment>
+# <i>semanage fcontext -a -t portage_ebuild_t "/mnt/gentoo/usr/portage(/.*)?"</i>
+</pre>
+
+<p>
+As you can see from the example, you can use wildcards. But beware about using
+wildcards: when a rule holds a wildcard, it has a lower priority than a rule
+without a wildcard. And the priority on rules with a wildcard is based on how
+"down" the string the first occurance of a wildcard is. For more information,
+please check out our <uri link="../selinux-faq.xml#matchcontext">FAQ on "How do
+I know which file context rule is used for a particular file?."</uri>
+</p>
+
+<p>
+If you want to delete a file context definition, you use <c>semanage fcontext
+-d</c>:
+</p>
+
+<pre caption="Deleting a file context definition">
+# <i>semanage fcontext -d -t portage_ebuild_t /mnt/gentoo/etc/make.conf</i>
+</pre>
+
+<p>
+Finally, to view all file context definitions (both user-set and SELinux policy
+provided), you can use <c>semanage fcontext -l</c>. To only see the locally set,
+add <c>-C</c>:
+</p>
+
+<pre caption="Viewing user-set file context enhancements">
+# <i>semanage fcontext -C -l</i>
+SELinux fcontext type Context
+/opt/xxe/bin/.*\.jar all files system_u:object_r:lib_t
+/srv/virt/gentoo(/.*)? all files system_u:object_r:qemu_image_t
+</pre>
+
+</body>
+</subsection>
+<subsection>
+<title>Customizable types</title>
+<body>
+
+<p>
+Labels on files are not that hard to understand, but you might come into some
+surprises if you do not know that there are also customizable types.
+</p>
+
+<p>
+A <e>customizable type</e> is a specific type which is not touched by the
+SELinux administration tools by default. If you want to relabel a file that
+currently holds a customizable type, you will need to force this through the
+commands (such as <c>restorecon -F</c>).
+</p>
+
+<p>
+There are not that many customizable types by default. The list of types that
+SELinux considers as customizable are mentioned in the
+<path>customizable_types</path> file within the
+<path>/etc/selinux/*/contexts</path> location:
+</p>
+
+<pre caption="Listing the customizable types">
+# <i>cat /etc/selinux/strict/contexts/customizable_types</i>
+mount_loopback_t
+public_content_rw_t
+public_content_t
+swapfile_t
+textrel_shlib_t
+</pre>
+
+<p>
+Such types exist because these types are used for files whose location is known
+not to be fixed (and as such, the SELinux policy cannot without a doubt know if
+the label on the files is correct or not). The <c>public_content_t</c> one,
+which is used for files that are readable by several services (like FTP, web
+server, ...), might give you a nice example for such a case.
+</p>
+
+<p>
+If you look at the <c>restorecon</c> man page, it mentions both customizable
+types as well as the user section. The latter is for rules that are identified
+in the SELinux policy as being files for an end user, like the following
+definitions in the <c>mozilla</c> policy module:
+</p>
+
+<pre caption="User section definition within mozilla module">
+HOME_DIR/\.mozilla(/.*)? gen_context(system_u:object_r:mozilla_home_t,s0)
+HOME_DIR/\.netscape(/.*)? gen_context(system_u:object_r:mozilla_home_t,s0)
+HOME_DIR/\.phoenix(/.*)? gen_context(system_u:object_r:mozilla_home_t,s0)
+</pre>
+
+<p>
+Although in the above example, forcing <c>restorecon</c> on the files is
+probably correct, there are examples where you do not want this. For instance,
+the firefox policy by default only allows the application to write to
+directories labeled <c>mozilla_home_t</c>. If you want to download something,
+this isn't possible (unless you download it into <path>~/.mozilla</path>). The
+solution there is to label a directory (say <path>~/Downloads</path>) as
+<c>mozilla_home_t</c>.
+</p>
+
+</body>
+</subsection>
+</section>
+
+<section>
+<title>SELinux Policy and Booleans</title>
+<subsection>
+<title>Introduction</title>
+<body>
+
+<p>
+We have dealt with users and labels now, but there is still a third aspect that
+we haven't touched: the SELinux policy itself.
+</p>
+
+<p>
+The SELinux policy as offered by Gentoo Hardened is a carefully tuned SELinux
+policy, based on the reference policy (a distribution-agnostic SELinux policy)
+with minor changes. Hopefully, you will not need to rewrite the policy to suit
+it for your needs, but changes are very likely to occur here and there.
+</p>
+
+</body>
+</subsection>
+<subsection>
+<title>Changing the SELinux Policy Behavior: Booleans</title>
+<body>
+
+<p>
+A common and user friendly way of tweaking the SELinux policy is through
+booleans. A <e>SELinux boolean</e>, also known as a conditional, changes how the
+SELinux policy behaves based on the setting that the user provides. To make this
+a bit more clear, let's look at a few booleans available:
+</p>
+
+<pre caption="Getting SELinux booleans">
+# <i>getsebool -a | grep ^user</i>
+user_direct_mouse --> off
+user_dmesg --> off
+user_ping --> on
+user_rw_noexattrfile --> off
+user_tcp_server --> off
+user_ttyfile_stat --> off
+</pre>
+
+<p>
+Although they might not say much on first sight, these booleans alter how the
+SELinux policy enforces user activity (hence the booleans starting with
+<path>user_</path>). For instance, <c>user_ping</c> is set to <c>on</c>, so a
+user is allowed to use <c>ping</c>. If it was set to <c>off</c>, the SELinux
+policy would not allow a user to execute <c>ping</c>.
+</p>
+
+<p>
+Booleans can be toggled on or off using <c>setsebool</c> or <c>togglesebool</c>.
+With <c>setsebool</c> you need to give the value (on or off) whereas
+<c>togglesebool</c> switches the value.
+</p>
+
+<pre caption="Disallowing the use of ping by users">
+# <i>setsebool user_ping off</i>
+</pre>
+
+<p>
+By default, <c>setsebool</c> does not store the boolean values - after a reboot,
+the old values are used again. To persist such changes, you need to add the
+<c>-P</c> option:
+</p>
+
+<pre caption="Persistedly allow users to run dmesg">
+# <i>setsebool -P user_dmesg on</i>
+</pre>
+
+<p>
+Booleans allow administrators to tune the policy, and allow security
+administrators to write policies that are flexible enough for a more widespread
+use. In terms of Gentoo flexibility, these booleans might not be used enough (it
+would be nice to couple these booleans on USE flags, so that a server build with
+USE="ldap" gets the SELinux policy to use ldap, whereas USE="-ldap" disallows
+it). But still, the use of booleans is a popular method for making a more
+flexible SELinux policy.
</p>
</body>
next reply other threads:[~2011-10-15 13:04 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-15 13:04 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-23 13:01 Sven Vermeulen
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-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=772e60f6cd55d1189c4a1023fbf56cc036e510a7.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