1 |
I've read the SELinux x86 Handbook (parts of which are returning HTTP |
2 |
500 errors at the moment, particularly Chapter 4 pages), and there are |
3 |
some aspects of system adminstration with SELinux I'm not yet |
4 |
completely comfortable with. |
5 |
|
6 |
In general, there are three ways you can go about doing system adminstration: |
7 |
|
8 |
1) Log in as root. |
9 |
|
10 |
2) Log in as another user and then use su to become root. |
11 |
|
12 |
3) Log in as another user and then run commands as root with sudo. |
13 |
|
14 |
(There are probably other options, like webmin, which are variations |
15 |
on one of the above.) |
16 |
|
17 |
Options 1 and 2 require that the administrator use the root password. |
18 |
Option 3 does not. |
19 |
|
20 |
When SELinux is thrown into the mix, an additional precondition is |
21 |
added to all of these options: The user must be in the sysadm_r role, |
22 |
which you can choose at login, or select with newrole. |
23 |
|
24 |
Note that sudo does not have SELinux support, and it is a setuid-root |
25 |
binary, so I adapted the su policy to sudo, and it works fine, |
26 |
provided that you have the sysadm_r role. |
27 |
|
28 |
What still bothers me a bit is that there are two main features to sudo: |
29 |
|
30 |
1) You can run things as another user (particularly root). |
31 |
|
32 |
2) You can grant fairly fine-grained access control and allow certain |
33 |
users to only run certain things. |
34 |
|
35 |
SELInux itself seems to be designed to primarily do #2, although it is |
36 |
based around roles, rather than users or groups. |
37 |
|
38 |
Consider a system with ordinary users, staff, and system |
39 |
administrators. These happen to fit nicely with the SELinux users_r, |
40 |
staff_r, and sysadm_r. |
41 |
|
42 |
There are certain day-to-day tasks that the staff needs to do: Add new |
43 |
users, reset passwords, edit e-mail aliases, and so. However, the |
44 |
staff should definitely not being doing general system adminstration, |
45 |
so under no circumstances should they have a root password. |
46 |
|
47 |
Additionally, it is preferred that the system adminstrators not have |
48 |
the root password either; it is a long string generated from |
49 |
/dev/random that nobody knows and is stored in a secure location for |
50 |
emergency use. |
51 |
|
52 |
Certain tasks have to be run as root, even with SELinux, and even if |
53 |
you have the sysadm_r role. sudo could fix this problem, but the |
54 |
current policy (adapted from su) requires sysadm_r. I expect I could |
55 |
change the policy to allow staff_r to run sudo, maybe. Or, is using |
56 |
sudo at all the wrong approach? For example, should the policy be |
57 |
changed (locally) to allow staff_t to run useradd? |
58 |
|
59 |
In other words, what's the right (and wrong) way to do it? |
60 |
-- |
61 |
Computer interfaces should never be made of meat. |
62 |
|
63 |
Using GMail? Setting Reply-to address to <> disables this annoying feature. |
64 |
|
65 |
-- |
66 |
gentoo-hardened@g.o mailing list |