One of the things I want to test out in the short-term future is to support
a security model for domains, and one of the things I'm playing with is to
optionally allow a domain full service administration (i.e. the _admin()
interfaces).
But that is not as easy as just granting all _admin() interfaces. I notice
two problems:
- Many (most) admin interfaces also put in place a role_transition call,
which might already be in place for some systems, causing a build error
(duplicate role transition)
- Code inside a tunable_policy cannot contain optional_policy statements
That makes it... challenging to create a setup like so:
tunable_policy(`salt_manage_services',`
optional_policy(`
foo_admin(salt_minion_t)
')
optional_policy(`
bar_admin(salt_minion_t)
')
')
The duplicate role transition issue can perhaps be improved / worked around
by updating checkmodule to ignore duplicate role transitions if they are the
same as the one already defined. Or we separate the role_transition calls
into different interfaces that are not part of the _admin() interface.
The tunable/optional issue however is more difficult to fix. For a single
domain, we can invert the calls, but I was hoping to support a single
interface that contains all _admin() interfaces. Such an interface cannot be
called from within a tunable_policy block.
We can support this through USE flags if we want (use build-time definitions
instead of run-time ones) but I was hoping to stick with the runtimes.
I'm going to test out some alternative approaches this week, but if anyone
has a particular idea or a brainfart that might push us somewhere I'm all
ears ;-)
Wkr,
Sven Vermeulen
See also:
- Discussion on granting _admin() to sysadm
http://oss.tresys.com/pipermail/refpolicy/2014-December/007498.html
a security model for domains, and one of the things I'm playing with is to
optionally allow a domain full service administration (i.e. the _admin()
interfaces).
But that is not as easy as just granting all _admin() interfaces. I notice
two problems:
- Many (most) admin interfaces also put in place a role_transition call,
which might already be in place for some systems, causing a build error
(duplicate role transition)
- Code inside a tunable_policy cannot contain optional_policy statements
That makes it... challenging to create a setup like so:
tunable_policy(`salt_manage_services',`
optional_policy(`
foo_admin(salt_minion_t)
')
optional_policy(`
bar_admin(salt_minion_t)
')
')
The duplicate role transition issue can perhaps be improved / worked around
by updating checkmodule to ignore duplicate role transitions if they are the
same as the one already defined. Or we separate the role_transition calls
into different interfaces that are not part of the _admin() interface.
The tunable/optional issue however is more difficult to fix. For a single
domain, we can invert the calls, but I was hoping to support a single
interface that contains all _admin() interfaces. Such an interface cannot be
called from within a tunable_policy block.
We can support this through USE flags if we want (use build-time definitions
instead of run-time ones) but I was hoping to stick with the runtimes.
I'm going to test out some alternative approaches this week, but if anyone
has a particular idea or a brainfart that might push us somewhere I'm all
ears ;-)
Wkr,
Sven Vermeulen
See also:
- Discussion on granting _admin() to sysadm
http://oss.tresys.com/pipermail/refpolicy/2014-December/007498.html