1 |
On Mon, May 09, 2011 at 09:25:25AM -0400, Chris PeBenito wrote: |
2 |
> I can't disagree with this more vehemently. This should not be made a |
3 |
> USE flag. If the user doesn't want role separations, then they should |
4 |
> be using unconfined users. Making this an option means users |
5 |
> unwittingly neuter the role separation by eliminating app, home |
6 |
> directory, temp directory, etc. separations. |
7 |
> |
8 |
> This is a wrong band-aid fix for the cron issue. It sounds like the |
9 |
> cron code needs to be fixed. |
10 |
|
11 |
With the current way of working, in my opinion it is a matter of |
12 |
documenting the differences when you run with SELinux (i.e. have information |
13 |
on Cron + SELinux, Postfix + SELinux, Apache + SELinux, ...). Not separate |
14 |
documents for each, but a general sum-up of those systems where additional |
15 |
information can be warranted (if not just to describe the types and perhaps |
16 |
booleans that users might be interested in). |
17 |
|
18 |
You're mentioning role separation, but the current method uses SELinux user |
19 |
separation. When role separation is in effect, I agree wholeheartedly - |
20 |
checking the file's role (sysadm_r then) and security context role (sysadm_r |
21 |
then too) will update the situation and makes a lot more sense. |
22 |
|
23 |
Fixing the code is not that obvious, but not impossible either. It depends a |
24 |
bit on what the requirements are that we have on vixie-cron with SELinux |
25 |
integration. Again, I prefer documenting these things, but there are also |
26 |
code-wise possibilities. |
27 |
|
28 |
With SELinux user separation, we can make separate crontabs depending on |
29 |
the SELinux user (so instead of "root" it could become "root+root" versus |
30 |
"root+staff_u", or make subdirectories based on the SELinux user) but that |
31 |
is not an obvious fix (it requires a lot more patches than we currently have |
32 |
in place for vixie-cron) which might not be necessary anymore when true |
33 |
role-based access controls can be put in place. |
34 |
|
35 |
Another possibility would be to set the default context from cron to the |
36 |
users' context (so for root, it would become root:sysadm_r:sysadm_t). As |
37 |
sysadm_t is exempt from UBAC, this would allow the root cronjobs to start. |
38 |
But then we're "circumventing" UBAC, which is not really what we are looking |
39 |
for. |
40 |
|
41 |
There are many other ways to handle this situation too - I'm leaving that to |
42 |
the colorful imagination of the developers ;-) |
43 |
|
44 |
Anyhow, about the USE="ubac" functionality. I'm personally never going to |
45 |
disable UBAC on my systems (never had any issues with it) but I can imagine |
46 |
that some people would like to disable it (just like some people might be |
47 |
interested in a non-hardened SELinux profile) so not providing the means to |
48 |
switch it off (refpolicy has it as a configurable setting, so why not) might |
49 |
be a bit harsh. But I wouldn't mind having USE="ubac" forced on by the |
50 |
SELinux profiles (so a user would need to use.force it in their local profile |
51 |
override location). Is that a situation you can live with? |
52 |
|
53 |
Wkr, |
54 |
Sven Vermeulen |