| 1 |
commit: 6ae1cd1ee8b563b826ee0c669bb7cdb4077cc1fc |
| 2 |
Author: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be> |
| 3 |
AuthorDate: Fri Sep 30 17:35:58 2011 +0000 |
| 4 |
Commit: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be> |
| 5 |
CommitDate: Fri Sep 30 17:35:58 2011 +0000 |
| 6 |
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=6ae1cd1e |
| 7 |
|
| 8 |
Update new selinux handbook, information on selinux users and login mappings |
| 9 |
|
| 10 |
--- |
| 11 |
xml/selinux/hb-using-configuring.xml | 243 +++++++++++++++++++++++++++++++++- |
| 12 |
1 files changed, 237 insertions(+), 6 deletions(-) |
| 13 |
|
| 14 |
diff --git a/xml/selinux/hb-using-configuring.xml b/xml/selinux/hb-using-configuring.xml |
| 15 |
index 139295d..78ace4f 100644 |
| 16 |
--- a/xml/selinux/hb-using-configuring.xml |
| 17 |
+++ b/xml/selinux/hb-using-configuring.xml |
| 18 |
@@ -8,7 +8,7 @@ |
| 19 |
|
| 20 |
<sections> |
| 21 |
<version>1</version> |
| 22 |
-<date>2011-09-18</date> |
| 23 |
+<date>2011-09-30</date> |
| 24 |
|
| 25 |
<section> |
| 26 |
<title>Administering Users</title> |
| 27 |
@@ -45,12 +45,12 @@ and SELinux users. |
| 28 |
<pre caption="Running semanage login -l"> |
| 29 |
# <i>semanage login -l</i> |
| 30 |
|
| 31 |
-Login Name SELinux User |
| 32 |
+Login Name SELinux User |
| 33 |
|
| 34 |
-__default__ user_u |
| 35 |
-root root |
| 36 |
-john staff_u |
| 37 |
-system_u system_u |
| 38 |
+__default__ user_u |
| 39 |
+root root |
| 40 |
+john staff_u |
| 41 |
+system_u system_u |
| 42 |
</pre> |
| 43 |
|
| 44 |
<p> |
| 45 |
@@ -60,6 +60,237 @@ not defined otherwise. This makes sure that a newly defined account does not get |
| 46 |
elevated privileges by default. |
| 47 |
</p> |
| 48 |
|
| 49 |
+<p> |
| 50 |
+The next table gives an overview of the standard SELinux users available after |
| 51 |
+an installation. |
| 52 |
+</p> |
| 53 |
+ |
| 54 |
+<table> |
| 55 |
+<tr> |
| 56 |
+ <th>SELinux User</th> |
| 57 |
+ <th>Description</th> |
| 58 |
+</tr> |
| 59 |
+<tr> |
| 60 |
+ <ti>user_u</ti> |
| 61 |
+ <ti> |
| 62 |
+ Default regular SELinux user, which should be used by end-user accounts that |
| 63 |
+ are not going to administer any service(s) on the system |
| 64 |
+ </ti> |
| 65 |
+</tr> |
| 66 |
+<tr> |
| 67 |
+ <ti>staff_u</ti> |
| 68 |
+ <ti> |
| 69 |
+ SELinux user for administrators. This user has the right to switch roles and |
| 70 |
+ as such gain elevated privileges |
| 71 |
+ </ti> |
| 72 |
+</tr> |
| 73 |
+<tr> |
| 74 |
+ <ti>root</ti> |
| 75 |
+ <ti> |
| 76 |
+ SELinux user for the root account. It differs little from the staff_u |
| 77 |
+ account beyond being a different ID. This ensures that files protected by |
| 78 |
+ the user based access control for root cannot be handled by the staff_u |
| 79 |
+ (and other) users |
| 80 |
+ </ti> |
| 81 |
+</tr> |
| 82 |
+<tr> |
| 83 |
+ <ti>sysadm_u</ti> |
| 84 |
+ <ti> |
| 85 |
+ SELinux user for system administration. By default, this account is not |
| 86 |
+ immediately used as this user immediately gets the administrative role |
| 87 |
+ (whereas staff_u and root still need to switch roles). |
| 88 |
+ </ti> |
| 89 |
+</tr> |
| 90 |
+<tr> |
| 91 |
+ <ti>system_u</ti> |
| 92 |
+ <ti> |
| 93 |
+ SELinux user for system services. It should never be used for end users or |
| 94 |
+ administrators as it provides direct access to the system role (and |
| 95 |
+ privileges) |
| 96 |
+ </ti> |
| 97 |
+</tr> |
| 98 |
+<tr> |
| 99 |
+ <ti>unconfined_u</ti> |
| 100 |
+ <ti> |
| 101 |
+ Used when the policy is <e>targeted</e>, this SELinux user has many |
| 102 |
+ privileges (it is essentially not limited in its actions, although it is |
| 103 |
+ still handled through SELinux - just through a "wide open" policy). |
| 104 |
+ </ti> |
| 105 |
+</tr> |
| 106 |
+</table> |
| 107 |
+ |
| 108 |
+<p> |
| 109 |
+To map a user to a specific SELinux user, use <c>semanage login -a</c>: |
| 110 |
+</p> |
| 111 |
+ |
| 112 |
+<pre caption="Mapping a user 'sophie' to the staff_u user"> |
| 113 |
+# <i>semanage login -a -s staff_u sophie</i> |
| 114 |
+</pre> |
| 115 |
+ |
| 116 |
+<p> |
| 117 |
+However, when you update such mapping, the files in that users' home directory |
| 118 |
+will be owned by a wrong SELinux user. It is therefor important to relabel the |
| 119 |
+files of that user: |
| 120 |
+</p> |
| 121 |
+ |
| 122 |
+<pre caption="Relabeling sophie's files"> |
| 123 |
+# <i>restorecon -R -F /home/sophie</i> |
| 124 |
+</pre> |
| 125 |
+ |
| 126 |
+</body> |
| 127 |
+</subsection> |
| 128 |
+<subsection> |
| 129 |
+<title>Additional SELinux Accounts</title> |
| 130 |
+<body> |
| 131 |
+ |
| 132 |
+<p> |
| 133 |
+It is perfectly possible to create additional SELinux accounts, and then map the |
| 134 |
+Linux logins to these new accounts. This can be necessary when you want a more |
| 135 |
+thorough auditing (on end user level) or when you will be enhancing the policy |
| 136 |
+with additional roles. Also, if you want to use the User Based Access Control |
| 137 |
+feature, using different SELinux users is important to enforce the control on |
| 138 |
+different users (if they all use the same SELinux user, then UBAC has little to |
| 139 |
+no effect). |
| 140 |
+</p> |
| 141 |
+ |
| 142 |
+<p> |
| 143 |
+Managing the SELinux accounts is done through <c>semanage user</c>: |
| 144 |
+</p> |
| 145 |
+ |
| 146 |
+<pre caption="Creating a SELinux user"> |
| 147 |
+# <i>semanage user -a -R "staff_r sysadm_r" sophie</i> |
| 148 |
+</pre> |
| 149 |
+ |
| 150 |
+<p> |
| 151 |
+Let's verify how the SELinux users are currently configured: |
| 152 |
+</p> |
| 153 |
+ |
| 154 |
+<pre caption="Checking the SELinux user identities"> |
| 155 |
+# <i>semanage user -l</i> |
| 156 |
+SELinux User SELinux Roles |
| 157 |
+ |
| 158 |
+root staff_r sysadm_r |
| 159 |
+sophie staff_r sysadm_r |
| 160 |
+staff_u staff_r sysadm_r |
| 161 |
+sysadm_u sysadm_r |
| 162 |
+system_u system_r |
| 163 |
+unconfined_u unconfined_r |
| 164 |
+user_u user_r |
| 165 |
+ |
| 166 |
+# <i>semanage login -l</i> |
| 167 |
+Login Name SELinux User |
| 168 |
+ |
| 169 |
+__default__ user_u |
| 170 |
+root root |
| 171 |
+sophie staff_u |
| 172 |
+swift staff_u |
| 173 |
+system_u system_u |
| 174 |
+</pre> |
| 175 |
+ |
| 176 |
+<p> |
| 177 |
+Now that a new SELinux user called "sophie" exists, we can now update the Linux |
| 178 |
+user mapping for "sophie" towards the new SELinux user "sophie": |
| 179 |
+</p> |
| 180 |
+ |
| 181 |
+<pre caption="Updating the Linux user mapping"> |
| 182 |
+# <i>semanage login -m -s sophie sophie</i> |
| 183 |
+# <i>semanage login -l</i> |
| 184 |
+Login Name SELinux User |
| 185 |
+ |
| 186 |
+__default__ user_u |
| 187 |
+root root |
| 188 |
+sophie sophie |
| 189 |
+swift staff_u |
| 190 |
+system_u system_u |
| 191 |
+</pre> |
| 192 |
+ |
| 193 |
+<p> |
| 194 |
+Again, do not forget to relabel this users' files. |
| 195 |
+</p> |
| 196 |
+ |
| 197 |
+<p> |
| 198 |
+As you can see, managing SELinux users means defining the roles to which the |
| 199 |
+user has access to. We already gave a high-level introduction to the default |
| 200 |
+roles in <uri link="?part=1&chap=2">SELinux Concepts</uri>, but as roles are |
| 201 |
+important when using a Mandatory Access Control system, let's refresh our memory |
| 202 |
+again: |
| 203 |
+</p> |
| 204 |
+ |
| 205 |
+<table> |
| 206 |
+<tr> |
| 207 |
+ <th>SELinux Role</th> |
| 208 |
+ <th>Description</th> |
| 209 |
+</tr> |
| 210 |
+<tr> |
| 211 |
+ <ti>user_r</ti> |
| 212 |
+ <ti> |
| 213 |
+ Default end-user role. This role provides access to regular applications and |
| 214 |
+ activities, but does not allow any system or service administration beyond |
| 215 |
+ what is expected for a regular user. |
| 216 |
+ </ti> |
| 217 |
+</tr> |
| 218 |
+<tr> |
| 219 |
+ <ti>staff_r</ti> |
| 220 |
+ <ti> |
| 221 |
+ Default administration role for day-to-day activities. This role has some |
| 222 |
+ additional privileges beyond what is offered through user_r, but is not a |
| 223 |
+ full system administrative role. It is meant for the non-administrative |
| 224 |
+ activities done by operators and administrators |
| 225 |
+ </ti> |
| 226 |
+</tr> |
| 227 |
+<tr> |
| 228 |
+ <ti>sysadm_r</ti> |
| 229 |
+ <ti> |
| 230 |
+ System administration role. This role is highly privileged (since it also |
| 231 |
+ contains the privileges to update the policy) and should only be given to |
| 232 |
+ fully trusted administrators. It is almost never immediately granted to |
| 233 |
+ users (they first need to switch roles) except for direct root access (for |
| 234 |
+ instance through the console) |
| 235 |
+ </ti> |
| 236 |
+</tr> |
| 237 |
+<tr> |
| 238 |
+ <ti>system_r</ti> |
| 239 |
+ <ti> |
| 240 |
+ System service role, which is used for the runtime services (processes). It |
| 241 |
+ is never granted to users directly. |
| 242 |
+ </ti> |
| 243 |
+</tr> |
| 244 |
+<tr> |
| 245 |
+ <ti>unconfined_r</ti> |
| 246 |
+ <ti> |
| 247 |
+ The unconfined role is used when the <e>targeted</e> policy is supported. |
| 248 |
+ This role is given to unconfined users (such as the SELinux unconfined_u |
| 249 |
+ user) which have very wide privileges (they almost run without constraints). |
| 250 |
+ </ti> |
| 251 |
+</tr> |
| 252 |
+</table> |
| 253 |
+ |
| 254 |
+<p> |
| 255 |
+It should be noted that these roles are the default ones, but the security |
| 256 |
+administrator - yes, that means you - can create additional roles and add |
| 257 |
+particular privileges to it. We will discuss this later in this book as it means |
| 258 |
+you'll need to update the Gentoo Hardened SELinux policy. |
| 259 |
+</p> |
| 260 |
+ |
| 261 |
+</body> |
| 262 |
+</subsection> |
| 263 |
+</section> |
| 264 |
+ |
| 265 |
+<section> |
| 266 |
+<title>Using (File) Labels</title> |
| 267 |
+<subsection> |
| 268 |
+<title>Introduction</title> |
| 269 |
+<body> |
| 270 |
+ |
| 271 |
+<p> |
| 272 |
+Within SELinux, access privileges are based on the label given on the |
| 273 |
+originating part (called the <e>domain</e>) and its target resource. For |
| 274 |
+instance, a process running in the passwd_t domain wants to read (= privilege) |
| 275 |
+the file <path>/etc/shadow</path> which is labeled shadow_t (= the target |
| 276 |
+resouce). It comes to no surprise then that the majority of SELinux |
| 277 |
+administration is (re)labeling the resources. |
| 278 |
+</p> |
| 279 |
+ |
| 280 |
</body> |
| 281 |
</subsection> |
| 282 |
</section> |
Archives