Gentoo Archives: gentoo-hardened

From: Sven Vermeulen <swift@g.o>
To: gentoo-hardened@l.g.o
Subject: [gentoo-hardened] SELinux: testing out interface with full admin sets (in light of secmodel)
Date: Mon, 09 Feb 2015 18:49:44
Message-Id: 20150209184941.GA24179@gentoo.org
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