1 |
Hi guys |
2 |
|
3 |
As I'm preparing for my yearly vacation, I would like to initiate a quick |
4 |
poll (or discussion) regarding a principle that I'd like to finish up with. |
5 |
|
6 |
As some of you are aware, I'm a big proponent for principles in development. |
7 |
For SELinux, a high-level principle document is available at |
8 |
https://wiki.gentoo.org/wiki/Project:SELinux/Development_policy but after my |
9 |
holidays I want to document this further. Whenever a decision needs to be |
10 |
made with respect to SELinux policies, I try to use the principles |
11 |
documented there to make the choice. |
12 |
|
13 |
But I'm not going to ask right now for rewrites on the documentation, but to |
14 |
focus on some decisions that we should do right now in order to give our |
15 |
policy a good "general direction" sense. |
16 |
|
17 |
I hope to get some good feedback on this, so that after my holidays I can |
18 |
jump into the proper changes (together with perfinion and other developers), |
19 |
as we have a lot of work to work through this year ;-) |
20 |
|
21 |
Role segregation |
22 |
================ |
23 |
|
24 |
Right now, our policy only provides a limited set of roles: sysadm_r (for |
25 |
system administration tasks), staff_r and user_r (for regular user |
26 |
activities, where staff_r is the only one allowed to switch to other roles |
27 |
as well). And of course "unconfined_r" for only very lightly-restricted |
28 |
domains. |
29 |
|
30 |
Which roles to make available? |
31 |
------------------------------ |
32 |
|
33 |
Do we want to include more roles in our policy? "Popular" roles are: |
34 |
|
35 |
auditadm_r :: Audit administration |
36 |
Used for a highly privileged, but generally read-only |
37 |
administration role. Meant not just to "manage audit logs", but |
38 |
instead to grant to IT Auditors that want to take a look on the |
39 |
system without granting them any change privileges (except for |
40 |
managing the audit logs apparently). |
41 |
|
42 |
This one is available through refpolicy |
43 |
|
44 |
logadm_r :: Log administration |
45 |
Used for managing system logging. |
46 |
|
47 |
This one is available through refpolicy |
48 |
|
49 |
secadm_r :: Security administration |
50 |
Used for managing the SELinux policy. If used, the question |
51 |
that follows is if sysadm_r should still be allowed to manage |
52 |
the SELinux policy as well (if not, this will be a challenge to |
53 |
implement, but not impossible) |
54 |
|
55 |
This one is available through refpolicy |
56 |
|
57 |
dbadm_r :: Database administration |
58 |
Used for database administrators |
59 |
|
60 |
This one is not available through refpolicy |
61 |
|
62 |
webadm_r :: Web (Application/Server) administration |
63 |
Used for web administrators (Apache, nginx, Tomcat, ...) |
64 |
|
65 |
This one is not available through refpolicy |
66 |
|
67 |
guest_r :: More restricted role than user_r |
68 |
Used to grant a minimum set of privileges, requiring the |
69 |
(security) administrator to grant specific application |
70 |
privileges. If used, then we would grant most/all application |
71 |
privileges to the staff_r and user_r as "counter-example" role |
72 |
|
73 |
This one is not available through refpolicy |
74 |
|
75 |
xguest_r :: Like guest_r, but with X11 support |
76 |
Used for implementations such as Kiosk mode, requiring the |
77 |
(security) administrator to grant specific application |
78 |
privileges. |
79 |
|
80 |
This one is not available through refpolicy |
81 |
|
82 |
My opinion: I don't mind to support them all (i.e. document the use and the |
83 |
principles behind them and making these roles available through the base |
84 |
policy). I have most of them (except logadm_r) running on all my production |
85 |
systems anyway so I might as well support them through Gentoo Linux. |
86 |
|
87 |
Differentiation between staff_r and user_r? |
88 |
------------------------------------------- |
89 |
|
90 |
The staff_r is meant as the "unprivileged" role for the administrator, |
91 |
whereas user_r is meant for the "unprivileged" role for users with no |
92 |
specific role(s) assigned otherwise. This would mean that staff_r == user_r, |
93 |
but with newrole_t (and other role switching domains) support. |
94 |
|
95 |
Depending on the outcome of the previous question, there are two approaches |
96 |
to take between staff_r and user_r: |
97 |
|
98 |
1. Have staff_r and user_r remain "in sync" with just the newrole_t |
99 |
difference, or |
100 |
2. Only support "less risky" domains in staff_r and reduce user domain |
101 |
privileges |
102 |
|
103 |
The idea behind option (2.) is that many users will have their daily tasks |
104 |
run as staff_r, and perhaps enable password-less role switching. If application |
105 |
vulnerabilities would result in account hijacking on staff_r, then these |
106 |
might jeopardise the system. |
107 |
|
108 |
To counter-act this, we could only grant well restricted application domains |
109 |
to staff_r (those that are needed for administrators to do their |
110 |
"unprivileged" jobs), such as running browsers and so, but not to (just to |
111 |
name something) run rtorrent (personally, I wouldn't like my admins to run |
112 |
rtorrent through their administrative account, even in an unprivileged |
113 |
role). |
114 |
|
115 |
The problem with (2.) however is to decide what to allow on staff_r and what |
116 |
not. Something to think about. |
117 |
|
118 |
Init script support |
119 |
=================== |
120 |
|
121 |
Transparent full system administration? |
122 |
--------------------------------------- |
123 |
|
124 |
Do we want the sysadm_r role (by default assigned to system administrators) |
125 |
to be able to run all possible init scripts on the system (/etc/init.d/*) |
126 |
without requiring the user to prepend the commands with "run_init"? |
127 |
|
128 |
So not this: ~# run_init rc-service nfs start |
129 |
But this: ~# rc-service nfs start |
130 |
|
131 |
If so, then we can either make sure that sysadm_t is always allowed to do |
132 |
this policy-wise (which might be as simple as enabling the DIRECT_INITRC |
133 |
option in the build), or through the integrated run_init support of OpenRC. |
134 |
|
135 |
The base premise however is to set this as a principle, so that we know what |
136 |
to aim for (and let us decide on the "how"). |
137 |
|
138 |
Advantages: works out-of-the-box, "system administration role" is a somewhat |
139 |
fully privileged role which is what many users expect. |
140 |
|
141 |
Disadvantages: no strict role separation (users who want more role |
142 |
separation will need to create their own roles) |
143 |
|
144 |
|
145 |
sysadm_r for System operational administration only? |
146 |
---------------------------------------------------- |
147 |
|
148 |
If not then perhaps we want to allow sysadm_r to manage true system |
149 |
operational services (those needed to boot the system) but not those that |
150 |
are "hosted on" the system. So the NFS service might not be assigned to the |
151 |
sysadm_r role by default (okay, this is debatable - take tor then as an |
152 |
example), whereas sysctl is. |
153 |
|
154 |
Users that want to extend the privileges of sysadm_r will always be allowed |
155 |
to, but this does mean that "run_init" would not be allowed anymore for the |
156 |
sysadm_r role (as run_init in its current form allows the user to invoke any |
157 |
service). |
158 |
|
159 |
If this is selected, then we'll improve our documentation to inform users |
160 |
how to assign additional privileges to the sysadm_r role (for those that |
161 |
want to manage their system fully) while staying quite strict in the default |
162 |
policy. |
163 |
|
164 |
Advantages: minimal privileges, users tweak the system further to the extend |
165 |
they want |
166 |
|
167 |
Disadvantages: new users will notice things don't work out-of-the-box |
168 |
|
169 |
Follow the Gentoo-is-about-choice paradigm and support both through USE? |
170 |
------------------------------------------------------------------------ |
171 |
|
172 |
We can implement a situation where we focus on the strict implementation, |
173 |
but where users can build the policy differently using a USE flag that |
174 |
enables the other support as well. I don't think we can do it with a SELinux |
175 |
boolean (due to limitations of what can be within a conditional statement) |
176 |
though. |
177 |
|
178 |
Advantages: best of both worlds |
179 |
|
180 |
Disadvantages: implementation possibilities are reduced (but hey, what do |
181 |
you care, right?) |