1 |
On Sun, Jul 20, 2014 at 04:28:58PM +0400, Jason Zaman wrote: |
2 |
> > Role segregation |
3 |
> > ================ |
4 |
> > |
5 |
> > Which roles to make available? |
6 |
> > ------------------------------ |
7 |
> > |
8 |
> > My opinion: I don't mind to support them all (i.e. document the use and the |
9 |
> > principles behind them and making these roles available through the base |
10 |
> > policy). I have most of them (except logadm_r) running on all my production |
11 |
> > systems anyway so I might as well support them through Gentoo Linux. |
12 |
> |
13 |
> The ones that are in refpolicy are probably not hard to support. The issue is |
14 |
> more of what type of machine it is. My things are all mostly personal machines |
15 |
> so I dont want to have 10 different accounts and keep changing between for |
16 |
> single commands. For companies tho I can definitely see them using all the |
17 |
> roles for different people in the company. Currently if people want to use all |
18 |
> of them they will need a lot of work because we dont provide much for it. |
19 |
> |
20 |
> Do we happen to have any information about big installations that use |
21 |
> gentoo and selinux and what their use-cases are? |
22 |
|
23 |
I asked around some time ago on the G+ community but didn't get much |
24 |
feedback. What I know professionally is (not counting the "all our users are |
25 |
unconfined_t" deployments) that most struggle with the users conceptually, |
26 |
because they don't have a clear definition to fall back on. |
27 |
|
28 |
Most deployments tend to follow the distribution choice, or customize. The |
29 |
ones that customize we don't really need to cater much for (beyond to make |
30 |
sure that these customizations aren't broken), and the ones that follow the |
31 |
distribution should have a clear, well-documented approach on things. |
32 |
|
33 |
Considering work-load, our user base, etc. I think the best way forward is |
34 |
to support a bit more roles, but also make sure that their purpose remains |
35 |
focused: auditadm_r, logadm_r, secadm_r, dbadm_r, webadm_r, guest_r, |
36 |
xguest_r. |
37 |
|
38 |
For those that aren't refpolicy-supported, I think they are useful for |
39 |
various reasons: |
40 |
|
41 |
- dbadm_r and webadm_r are two "example" user domains which serve a |
42 |
particular administrative purpose. It can be used by others to learn how |
43 |
to manage administrative user domains. The focus on databases (dbadm_r) |
44 |
and web services (webadm_r) is that these are the two most popular |
45 |
middleware services around which can be easily tested. |
46 |
|
47 |
- guest_r and xguest_r would provide a very limited ("empty") user domain |
48 |
for users with basic privileges. I would like to support these (using this |
49 |
principle) as they are also available in RHEL and Fedora. |
50 |
|
51 |
Because of these four additional domains, we can have |
52 |
|
53 |
- staff_r and user_r similar (i.e. keep them in sync, except for the ability |
54 |
to use sudo/su and roleswitching which is only available for staff_r) as |
55 |
users who want a more "closed-down" user domain can either enhance the |
56 |
xguest_r role, or copy and make their own implementation |
57 |
|
58 |
- sysadm_r be a full-administrative domain, as users can then look at |
59 |
dbadm_r and webadm_r to see how to make more "closed-down" administrator |
60 |
domains |
61 |
|
62 |
> > Differentiation between staff_r and user_r? |
63 |
> > ------------------------------------------- |
64 |
> > |
65 |
> > Depending on the outcome of the previous question, there are two approaches |
66 |
> > to take between staff_r and user_r: |
67 |
> > |
68 |
> > 1. Have staff_r and user_r remain "in sync" with just the newrole_t |
69 |
> > difference, or |
70 |
> > 2. Only support "less risky" domains in staff_r and reduce user domain |
71 |
> > privileges |
72 |
> |
73 |
> I personally use staff_r as my main account and do not use user_r at all |
74 |
> so I just end up having an extra policy which enables things that are |
75 |
> in user but not staff (wine, dropbox etc) on my laptop. Im not sure what |
76 |
> the right way to do things for this is. I think having most of the |
77 |
> things the same in staff/user is not that big of a deal since if you |
78 |
> dont have sec-policy/selinux-dropbox installed, the optional() block |
79 |
> just disappears. Although if someone can install packages then it |
80 |
> suddenly gets enabled but I think at that point it is already game over. |
81 |
|
82 |
The point is more about the applications that still run in the user domain |
83 |
rather than their own domain. Vulnerabilities in firefox (mozilla_t) |
84 |
shouldn't be able to impact the system much beyond what mozilla_t can do |
85 |
(and with our own support for XDG directories, even user content can be |
86 |
properly protected), but applications that /do/ run in the user domain might |
87 |
have more impact to the system if they run in staff_t, as they can "try" to |
88 |
elevate their privileges (depending on the system configuration, this might |
89 |
be possible) whereas user_t wouldn't allow that much. |
90 |
|
91 |
But given the user domains above, having staff_t and user_t be very similar |
92 |
and keep on focusing on confining the user applications, I think we are |
93 |
taking a safe route here. The worst risks aren't within the domains, but in |
94 |
the applications that would still run in the user domains. |
95 |
|
96 |
> > Init script support |
97 |
> > =================== |
98 |
> > |
99 |
> > Transparent full system administration? |
100 |
> > --------------------------------------- |
101 |
> > |
102 |
> > So not this: ~# run_init rc-service nfs start |
103 |
> > But this: ~# rc-service nfs start |
104 |
> |
105 |
> This is sort of annoying honestly, Im in favour of removing run_init in |
106 |
> front and make it just happen automatically. That said, I do like that |
107 |
> it can authenticate (I like it on my server since I dont restart things |
108 |
> much but dislike it on my laptop where I have less running and start |
109 |
> them manually when I need them. I think we should integrate this into |
110 |
> openrc directly but ideally i'd like to be able to keep the pam |
111 |
> authentication parts of it so that people can choose if they want to |
112 |
> type the password or not. |
113 |
> |
114 |
> I also saw someone having issues with puppet or one of those cuz it just |
115 |
> ran the script and adding run_init in front was complicated. |
116 |
|
117 |
Indeed. I think we should definitely remove the need for calling run_init |
118 |
directly in any case. |
119 |
|
120 |
> > sysadm_r for System operational administration only? |
121 |
> > ---------------------------------------------------- |
122 |
> |
123 |
> This seems like it would be a big hurdle for most new (and old?) users. |
124 |
> If we enable more of the roles from above then perhaps there can be some |
125 |
> roles that are disallowed it but I think changing the current behavior |
126 |
> is a little strange. |
127 |
|
128 |
Ok, I can live with that. And indeed, if we were to remove lots of |
129 |
privileges from sysadm_r users would be severely impacted. |
130 |
|
131 |
I'll see if the system operational code and "the rest" can be properly |
132 |
documented in the policy files instead, so that /if/ someone would like to |
133 |
instantiate a system operational role (like sysoper_r) they can copy the |
134 |
sysadm_r information and remove the non-critical stuff themselves. |
135 |
|
136 |
> > Follow the Gentoo-is-about-choice paradigm and support both through USE? |
137 |
> > ------------------------------------------------------------------------ |
138 |
> |
139 |
> There is currently a use-flag for unconfined, making similar useflags |
140 |
> (or a use_expand?) for how the roles should be used sounds like the |
141 |
> easiest way. If people install with the defaults they get staff/sysadm |
142 |
> like exist currently but if they enable some of the other roles then |
143 |
> maybe sysadm would lose some of its privs to that other role. (eg enable |
144 |
> secadm and sysadm is no longer able to change the policy) |
145 |
|
146 |
I think maintaining an expanded USE flag would become a maintenance burden, |
147 |
but I'm not saying "no" here. We can do this in a second phase if the |
148 |
sysadm_r role can be properly documented (cfr. paragraphs above) as we can |
149 |
then include the proper ifdef() statements. |
150 |
|
151 |
The reason I'm not in favor of taking this up right now is that we need to |
152 |
support this throughout the future as well, and I don't know how to do this |
153 |
with CIL in the future. Not saying it won't be possible though, just |
154 |
something we might want to implement later. |
155 |
|
156 |
> > Disadvantages: implementation possibilities are reduced (but hey, what do |
157 |
> > you care, right?) |
158 |
> |
159 |
> How are they reduced? You mean ways to implement the policy or ways to |
160 |
> use it as a user? How much more complicated would this become for the |
161 |
> policy? |
162 |
|
163 |
Policy-wise. The discussion was about the run_init support. We can make |
164 |
sysadm_r support everything without needing run_init and without needing to |
165 |
"integrate" run_init in OpenRC (or other init systems) by plain policy |
166 |
rules. |
167 |
|
168 |
However, the moment we make this optional, or at least user-defined through |
169 |
USE flags, then the implementations must focus on at least two things: |
170 |
run_init support in OpenRC (with the ability to discern calling run_init |
171 |
based on USE flag settings, or based on interrogating the SELinux policy to |
172 |
see if it is wanted) and policy. |
173 |
|
174 |
Basically, if we integrate run_init in OpenRC, how do we make sure it |
175 |
doesn't call it when it shouldn't (user domain has no run_init_t privileges, |
176 |
but transitions to sysadm_r/initrc_t directly)? |
177 |
|
178 |
If sysadm_r is "system operational only", then OpenRC shouldn't call |
179 |
run_init except for the init scripts that are initrc_exec_t (and not say |
180 |
tor_initrc_exec_t), and also not if the policy has direct_sysadm support. |
181 |
|
182 |
But considering the ideas above, having sysadm_t be an all-encompassing |
183 |
administrative domain, we only need to have OpenRC call run_init if the user |
184 |
domain is sysadm_t. Other domains can be made to transition when needed |
185 |
policy-wise. I think. I still need to get my head around it ;-) |
186 |
|
187 |
|
188 |
|
189 |
I'll document the idea on the wiki (somewhere in the Project:SELinux |
190 |
namespace) and expand on it some more to see if we don't have any loose |
191 |
strings. |
192 |
|
193 |
Thanks for the feedback! |