1 |
One of the things I want to test out in the short-term future is to support |
2 |
a security model for domains, and one of the things I'm playing with is to |
3 |
optionally allow a domain full service administration (i.e. the _admin() |
4 |
interfaces). |
5 |
|
6 |
But that is not as easy as just granting all _admin() interfaces. I notice |
7 |
two problems: |
8 |
|
9 |
- Many (most) admin interfaces also put in place a role_transition call, |
10 |
which might already be in place for some systems, causing a build error |
11 |
(duplicate role transition) |
12 |
- Code inside a tunable_policy cannot contain optional_policy statements |
13 |
|
14 |
That makes it... challenging to create a setup like so: |
15 |
|
16 |
tunable_policy(`salt_manage_services',` |
17 |
optional_policy(` |
18 |
foo_admin(salt_minion_t) |
19 |
') |
20 |
optional_policy(` |
21 |
bar_admin(salt_minion_t) |
22 |
') |
23 |
') |
24 |
|
25 |
The duplicate role transition issue can perhaps be improved / worked around |
26 |
by updating checkmodule to ignore duplicate role transitions if they are the |
27 |
same as the one already defined. Or we separate the role_transition calls |
28 |
into different interfaces that are not part of the _admin() interface. |
29 |
|
30 |
The tunable/optional issue however is more difficult to fix. For a single |
31 |
domain, we can invert the calls, but I was hoping to support a single |
32 |
interface that contains all _admin() interfaces. Such an interface cannot be |
33 |
called from within a tunable_policy block. |
34 |
|
35 |
We can support this through USE flags if we want (use build-time definitions |
36 |
instead of run-time ones) but I was hoping to stick with the runtimes. |
37 |
|
38 |
I'm going to test out some alternative approaches this week, but if anyone |
39 |
has a particular idea or a brainfart that might push us somewhere I'm all |
40 |
ears ;-) |
41 |
|
42 |
Wkr, |
43 |
Sven Vermeulen |
44 |
|
45 |
See also: |
46 |
- Discussion on granting _admin() to sysadm |
47 |
http://oss.tresys.com/pipermail/refpolicy/2014-December/007498.html |