Gentoo Archives: gentoo-hardened

From: Sven Vermeulen <swift@g.o>
To: gentoo-hardened@l.g.o
Subject: [gentoo-hardened] SELinux support principles discussion
Date: Tue, 15 Jul 2014 18:02:37
Message-Id: 20140715180232.GA2227@gentoo.org
1 Hi guys
2
3 As I'm preparing for my yearly vacation, I would like to initiate a quick
4 poll (or discussion) regarding a principle that I'd like to finish up with.
5
6 As some of you are aware, I'm a big proponent for principles in development.
7 For SELinux, a high-level principle document is available at
8 https://wiki.gentoo.org/wiki/Project:SELinux/Development_policy but after my
9 holidays I want to document this further. Whenever a decision needs to be
10 made with respect to SELinux policies, I try to use the principles
11 documented there to make the choice.
12
13 But I'm not going to ask right now for rewrites on the documentation, but to
14 focus on some decisions that we should do right now in order to give our
15 policy a good "general direction" sense.
16
17 I hope to get some good feedback on this, so that after my holidays I can
18 jump into the proper changes (together with perfinion and other developers),
19 as we have a lot of work to work through this year ;-)
20
21 Role segregation
22 ================
23
24 Right now, our policy only provides a limited set of roles: sysadm_r (for
25 system administration tasks), staff_r and user_r (for regular user
26 activities, where staff_r is the only one allowed to switch to other roles
27 as well). And of course "unconfined_r" for only very lightly-restricted
28 domains.
29
30 Which roles to make available?
31 ------------------------------
32
33 Do we want to include more roles in our policy? "Popular" roles are:
34
35 auditadm_r :: Audit administration
36 Used for a highly privileged, but generally read-only
37 administration role. Meant not just to "manage audit logs", but
38 instead to grant to IT Auditors that want to take a look on the
39 system without granting them any change privileges (except for
40 managing the audit logs apparently).
41
42 This one is available through refpolicy
43
44 logadm_r :: Log administration
45 Used for managing system logging.
46
47 This one is available through refpolicy
48
49 secadm_r :: Security administration
50 Used for managing the SELinux policy. If used, the question
51 that follows is if sysadm_r should still be allowed to manage
52 the SELinux policy as well (if not, this will be a challenge to
53 implement, but not impossible)
54
55 This one is available through refpolicy
56
57 dbadm_r :: Database administration
58 Used for database administrators
59
60 This one is not available through refpolicy
61
62 webadm_r :: Web (Application/Server) administration
63 Used for web administrators (Apache, nginx, Tomcat, ...)
64
65 This one is not available through refpolicy
66
67 guest_r :: More restricted role than user_r
68 Used to grant a minimum set of privileges, requiring the
69 (security) administrator to grant specific application
70 privileges. If used, then we would grant most/all application
71 privileges to the staff_r and user_r as "counter-example" role
72
73 This one is not available through refpolicy
74
75 xguest_r :: Like guest_r, but with X11 support
76 Used for implementations such as Kiosk mode, requiring the
77 (security) administrator to grant specific application
78 privileges.
79
80 This one is not available through refpolicy
81
82 My opinion: I don't mind to support them all (i.e. document the use and the
83 principles behind them and making these roles available through the base
84 policy). I have most of them (except logadm_r) running on all my production
85 systems anyway so I might as well support them through Gentoo Linux.
86
87 Differentiation between staff_r and user_r?
88 -------------------------------------------
89
90 The staff_r is meant as the "unprivileged" role for the administrator,
91 whereas user_r is meant for the "unprivileged" role for users with no
92 specific role(s) assigned otherwise. This would mean that staff_r == user_r,
93 but with newrole_t (and other role switching domains) support.
94
95 Depending on the outcome of the previous question, there are two approaches
96 to take between staff_r and user_r:
97
98 1. Have staff_r and user_r remain "in sync" with just the newrole_t
99 difference, or
100 2. Only support "less risky" domains in staff_r and reduce user domain
101 privileges
102
103 The idea behind option (2.) is that many users will have their daily tasks
104 run as staff_r, and perhaps enable password-less role switching. If application
105 vulnerabilities would result in account hijacking on staff_r, then these
106 might jeopardise the system.
107
108 To counter-act this, we could only grant well restricted application domains
109 to staff_r (those that are needed for administrators to do their
110 "unprivileged" jobs), such as running browsers and so, but not to (just to
111 name something) run rtorrent (personally, I wouldn't like my admins to run
112 rtorrent through their administrative account, even in an unprivileged
113 role).
114
115 The problem with (2.) however is to decide what to allow on staff_r and what
116 not. Something to think about.
117
118 Init script support
119 ===================
120
121 Transparent full system administration?
122 ---------------------------------------
123
124 Do we want the sysadm_r role (by default assigned to system administrators)
125 to be able to run all possible init scripts on the system (/etc/init.d/*)
126 without requiring the user to prepend the commands with "run_init"?
127
128 So not this: ~# run_init rc-service nfs start
129 But this: ~# rc-service nfs start
130
131 If so, then we can either make sure that sysadm_t is always allowed to do
132 this policy-wise (which might be as simple as enabling the DIRECT_INITRC
133 option in the build), or through the integrated run_init support of OpenRC.
134
135 The base premise however is to set this as a principle, so that we know what
136 to aim for (and let us decide on the "how").
137
138 Advantages: works out-of-the-box, "system administration role" is a somewhat
139 fully privileged role which is what many users expect.
140
141 Disadvantages: no strict role separation (users who want more role
142 separation will need to create their own roles)
143
144
145 sysadm_r for System operational administration only?
146 ----------------------------------------------------
147
148 If not then perhaps we want to allow sysadm_r to manage true system
149 operational services (those needed to boot the system) but not those that
150 are "hosted on" the system. So the NFS service might not be assigned to the
151 sysadm_r role by default (okay, this is debatable - take tor then as an
152 example), whereas sysctl is.
153
154 Users that want to extend the privileges of sysadm_r will always be allowed
155 to, but this does mean that "run_init" would not be allowed anymore for the
156 sysadm_r role (as run_init in its current form allows the user to invoke any
157 service).
158
159 If this is selected, then we'll improve our documentation to inform users
160 how to assign additional privileges to the sysadm_r role (for those that
161 want to manage their system fully) while staying quite strict in the default
162 policy.
163
164 Advantages: minimal privileges, users tweak the system further to the extend
165 they want
166
167 Disadvantages: new users will notice things don't work out-of-the-box
168
169 Follow the Gentoo-is-about-choice paradigm and support both through USE?
170 ------------------------------------------------------------------------
171
172 We can implement a situation where we focus on the strict implementation,
173 but where users can build the policy differently using a USE flag that
174 enables the other support as well. I don't think we can do it with a SELinux
175 boolean (due to limitations of what can be within a conditional statement)
176 though.
177
178 Advantages: best of both worlds
179
180 Disadvantages: implementation possibilities are reduced (but hey, what do
181 you care, right?)

Replies

Subject Author
Re: [gentoo-hardened] SELinux support principles discussion Jason Zaman <jason@×××××××××.com>