summaryrefslogtreecommitdiff
path: root/kernels/gradm/policy
blob: 55a5811c897d46bbdfbadde1d8bf2d1418d9cba3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
#sample default policy for grsecurity
#
# Role flags:
# A -> This role is an administrative role, thus it has special privilege normal
#      roles do not have.  In particular, this role bypasses the 
#      additional ptrace restrictions
# N -> Don't require authentication for this role.  To access
#      the role, use gradm -n <rolename>
# s -> This role is a special role, meaning it does not belong to a
#      user or group, and does not require an enforced secure policy
#      base to be included in the ruleset
# u -> This role is a user role
# g -> This role is a group role
# G -> This role can use gradm to authenticate to the kernel
#      A policy for gradm will automatically be added to the role
# T -> Enable TPE for this role
# l -> Enable learning for this role
# P -> Use PAM authentication for this role.
# R -> Enable persistence of special role.  Normal special roles will
#      be removed upon exit of the process that entered the role, or
#      upon unauth (this is what changes the apache process' role back 
#      to its normal role after being restarted from the admin role, for
#      instance).  Role persistence allows a special role to be used for
#      system shutdown, as the point at which the admin's shell/SSH 
#      session is terminated won't cause the rest of the shutdown 
#      sequence to execute with reduced privilege.  Do *NOT* use this 
#      flag with any role that does anything but shut the system down.
#      This role will also be transferred to the init process upon
#      writing to /dev/initctl.  This allows init to execute the rc 
#      scripts for shutdown with the necessary privilege.
#      For usability reasons, we allow the removal of persistence through
#      the normal unauth process (so persistence only survives exit).
#
# a role can only be one of user, group, or special
#
# role_allow_ip IP/optional netmask
# eg: role_allow_ip 192.168.1.0/24
# You can have as many of these per role as you want
# They restrict the use of a role to a list of IPs.  If a user
# is on the system that would normally get the role does not
# belong to those lists of IPs, the system falls back through
# its method of determining a role for the user
#
# Role hierarchy
# user -> group -> default
# First a user role attempts to match, if one is not found,
# a group role attempts to match, if one is not found,
# the default role is used.
#
# role_transitions <special role 1> <special role 2> ... <special role n>
# eg: role_transitions www_admin dns_admin
#
# role transitions specify which special roles a given role is allowed
# to authenticate to.  This applies to special roles that do not
# require password authentication as well.  If a user tries to
# authenticate to a role that is not within his transition table, he
# will receive a permission denied error
#
# Nested subjects
# subject /bin/su:/bin/bash:/bin/cat
#	  / rwx
#	  +CAP_ALL
# grant privilege to specific processes if they are executed
# within a trusted path.  In this case, privilege is
# granted if /bin/cat is executed from /bin/bash, which is
# executed from /bin/su.
#
# Configuration inheritance on nested subjects
# nested subjects inherit rules from their parents.  In the
# example above, the nested subject would inherit rules
# from the nested subject for /bin/su:/bin/bash,
# and the subject /bin/su
# View the 1.9.x documentation for more information on
# configuration inheritance
#
# new object modes:
# m -> allow creation of setuid/setgid files/directories
#      and modification of files/directories to be setuid/setgid
# M -> audit the setuid/setgid creation/modification
# c -> allow creation of the file/directory
# C -> audit the creation
# d -> allow deletion of the file/directory
# D -> audit the deletion
# p -> reject all ptraces to this object
# l -> allow a hardlink at this path
#	(hardlinking requires at a minimum c and l modes, and the target
#	 link cannot have any greater permission than the source file)
# L -> audit link creation
# f -> needed to mark the pipe used for communication with init
#      to transfer the privilege of the persistent role; only valid
#      within a persistent role.  Transfer only occurs when the file is 
#      opened for writing
#
# new subject modes:
# O -> disable "writable library" restrictions for this task
# t -> allow this process to ptrace any process (use with caution)
# r -> relax ptrace restrictions (allows process to ptrace processes
#      other than its own descendants)
# i -> enable inheritance-based learning for this subject, causing
#      all accesses of this subject and anything it executes to be placed
#      in this subject, and inheritance flags added to executable objects
#      in this subject
# a -> allow this process to talk to the /dev/grsec device
# s -> enable AT_SECURE when entering this subject
#      (enables the same environment sanitization that occurs in glibc
#	upon execution of a suid binary)
# x -> allows executable anonymous shared memory for this subject
#
# user/group transitions:
# You may now specify what users and groups a given subject can
# transition to.  This can be done on an inclusive or exclusive basis.
# Omitting these rules allows a process with proper privilege granted by
# capabilities to transition to any user/group.
#
# Examples:
# subject /bin/su
# user_transition_allow root spender
# group_transition_allow root spender
# subject /bin/su
# user_transition_deny evilhacker
# subject /bin/su
# group_transition_deny evilhacker1 evilhacker2
#
# Domains:
# With domains you can combine users that don't share a common
# GID as well as groups so that they share a single policy
# Domains work just like roles, with the only exception being that
# the line starting with "role" is replaced with one of the following:
# domain somedomainname u user1 user2 user3 user4 ... usern
# domain somedomainname g group1 group2 group3 group4 ... groupn
#
# Inverted socket policies:
# Rules such as
# connect ! www.google.com:80 stream tcp
# are now allowed, which allows you to specify that a process can connect to anything
# except to port 80 of www.google.com with a stream tcp socket
# the inverted socket matching also works on bind rules
#
# INADDR_ANY overriding
# You can now force a given subject to bind to a particular IP address on the machine
# This is useful for some chrooted environments, to ensure that the source IP they
# use is one of your choosing
# to use, add a line like:
# ip_override 192.168.0.1
#
# Per-interface socket policies:
# Rules such as
# bind eth1:80 stream tcp
# bind eth0#1:22 stream tcp
# are now allowed, giving you the ability to tie specific socket rules 
# to a single interface (or by using the inverted rules, all but one 
# interface).  Virtual interfaces are specified by the <ifname>#<vindex>
# syntax.  If an interface is specified, no IP/netmask or host may be
# specified for the rule.
#
# Allowing additional socket families:
# Before v2.2.1 of the RBAC system, a subject that specified
# connect/bind rules limited only the socket usage of IPv4, allowing
# any other socket families to be used.  Starting with v2.2.1 of the 
# RBAC system, when connect/bind rules are used, additional rules
# will be required to unlock the use of additional socket families 
# (outside of the common unix family).  Multiple families can be
# specified per line.
# To enable use of IPv6, add the line:
# sock_allow_family ipv6
# To enable use of netlink, add the line:
# sock_allow_family netlink
# To enable all other families, add the line:
# sock_allow_family all
#
# New learning system:
# To learn on a given subject: add l (the letter l, not the number 1)
# to the subject mode
# If you want to learn with the most restrictive policy, use the 
# following:
# subject /path/to/bin lo
#    / h
#    -CAP_ALL
#    connect disabled
#    bind disabled
# Resource learning is also supported, so lines like
#    RES_AS 0 0
# can be used to learn a particular resource
#
# To learn on a given role, add l to the role mode
# For both of these, to enable learning, enable the system like:
# gradm -L /etc/grsec/learning.logs -E
# and then generate the rules after disabling the system after the 
# learning phase with:
# gradm -L /etc/grsec/learning.logs -O /etc/grsec/policy
# To use full system learning, enable the system like:
# gradm -F -L /etc/grsec/learning.logs
# and then generate the rules after disabling the system after the 
# learning phase with:
# gradm -F -L /etc/grsec/learning.logs -O /etc/grsec/policy
#
# New PaX flag format (replaces PaX subject flags):
# PaX flags can be forced on or off, regardless of the flags on the 
# binary, by using + or - before the following PaX flag names:
# PAX_SEGMEXEC
# PAX_PAGEEXEC
# PAX_MPROTECT
# PAX_RANDMMAP
# PAX_EMUTRAMP
#
# New feature for easier policy maintenance:
# replace <variable name> <replace string>
# e.g.:
# replace CVSROOT /home/cvs
# now $(CVSROOT) can be used in any subject or object pathname, like:
# $(CVSROOT)/grsecurity r
# This will translate to /home/cvs/grsecurity r
# This feature makes it easier to update policies by naming specific
# paths by their function, then only having to update those paths once
# to have it affect a large number of subjects/objects.
#
# capability auditing / log suppression
# use of a capability can be audited by adding "audit" to the line, eg:
# +CAP_SYS_RAWIO audit
# log suppression for denial of a capbility can be done by adding "suppress":
# -CAP_SYS_RAWIO suppress
#
# Per-role umask enforcement:
# If you have a user that you want to be assured cannot accidentally
# create a file that others can read (a confidentiality issue)
# add the following under the role declaration:
# role_umask 077
# any normal octal umask may be specified
# Note that unlike the normal umask, this umask will also apply
# to the permissions one can chmod/fchmod a file to
#
# Note that the omission of any feature of a role or subject
# results in a default-allow
# For instance, if no capability rules are added, an implicit +CAP_ALL is used
#
# Commonly-used objects can be defined and used in multiple subjects
# As an example, we'll create a variable out of a list of objects
# and their associated permissions that RBAC enforces
define grsec_denied {
	/boot				h
	/dev/grsec			h
	/dev/kmem			h
	/dev/mem			h
	/dev/port			h
	/etc/grsec			h
	/proc/kcore			h
	/proc/slabinfo		h
	/proc/modules		h
	/proc/kallsyms		h
	# hide and suppress logs about accessing this path
	/usr/lib/modules 	hs
	/etc/ssh			h
}
# usage:
# $grsec_denied

role shutdown sARG
subject / rvka
	/
	/dev
	/dev/urandom	r
	/dev/random		r
	/etc			r
	/usr			rx
	/proc			r
	$grsec_denied
	-CAP_ALL
	connect disabled
	bind disabled

subject /usr/lib/systemd/systemd rvkao
	/ rwcdmlxi
subject /usr/bin/systemctl rvkao
	/ rwcdmlxi
	/dev/initctl rwf
	/run/initctl rwf

# Make sure to unauthenticate with gradm -u from
# the admin role after restarting a service
# The service started will run with admin
# privileges until you run gradm -u or your shell exits

role admin sA
subject / rvka
	/ rwcdmlxi

role default G
role_transitions admin shutdown
subject /
	/		r
	/opt		rx
	/home		rwxcd
	/mnt		rw
	/dev
	/dev/urandom	r
	/dev/random	r
	/dev/zero	rw
	/dev/input	rw
	/dev/psaux	rw
	/dev/null	rw
	/dev/tty?	rw
	/dev/console	rw
	/dev/tty	rw
	/dev/pts	rw
	/dev/ptmx	rw
	/dev/dsp	rw
	/dev/mixer	rw
	/dev/initctl	rw
	/dev/fd0	r
	/dev/cdrom	r
	/usr		rx
# compilation of kernel code should be done within the admin role	
	/usr/src	h
	/etc		rx
	/proc		rwx
	/proc/sys	r
	/sys		h
	/root		r
	/run		r
	/tmp		rwcd
	/var		rwxcd
	/var/tmp	rwcd
	/var/log	r
# hide the kernel images and modules
	$grsec_denied

# if sshd needs to be restarted, it can be done through the admin role
# restarting sshd should be followed immediately by a gradm -u
	/usr/sbin/sshd

	/home/*/.gem/ruby/2.0.0/bin		rx
	/home/*/.rbenv/shims			rx
	/home/*/.rbenv/versions*/bin	rx
	/home/*/.cabal/bin				rx
	/home/*/dev/env					rx

	-CAP_KILL
	-CAP_SYS_TTY_CONFIG
	-CAP_LINUX_IMMUTABLE
	-CAP_NET_RAW
	-CAP_MKNOD
	-CAP_SYS_ADMIN
	-CAP_SYS_RAWIO
	-CAP_SYS_MODULE
	-CAP_SYS_PTRACE
	-CAP_NET_ADMIN
	-CAP_NET_BIND_SERVICE
	-CAP_NET_RAW
	-CAP_SYS_CHROOT
	-CAP_SYS_BOOT
	-CAP_SETFCAP
	-CAP_SYSLOG

#	RES_AS 100M 100M

#	connect 192.168.1.0/24:22 stream tcp
#	bind	0.0.0.0 stream dgram tcp udp

# the d flag protects /proc fd and mem entries for sshd
# all daemons should have 'p' in their subject mode to prevent
# an attacker from killing the service (and restarting it with trojaned
# config file or taking the port it reserved to run a trojaned service)

subject /usr/sbin/sshd dpo
	/
	/*		h
	/bin/bash	x
	/dev		h
	/dev/log	rw
	/dev/random	r
	/dev/urandom	r
	/dev/null	rw
	/dev/ptmx	rw
	/dev/pts	rw
	/dev/tty	rw
	/dev/tty?	rw
	/etc		r
	/etc/grsec	h
	/home
	/home/*/.ssh/authorized_keys r
	/root
	/proc		r
	/proc/*/oom_adj rw
	/proc/kcore	h
	/proc/sys	h
	/proc/sys/kernel/ngroups_max r
	/selinux	r
	/usr/lib	rx
	/usr/share/zoneinfo r
	/var/log
	/var/mail
	/var/log/lastlog	rw
	/var/log/wtmp		w
	/var/run
	/run
	/var/run/sshd
	/var/run/utmp		rw
	/var/run/utmpx		rw
	/var/run/.nscd_socket	rw

	-CAP_ALL
	+CAP_CHOWN
	+CAP_SETGID
	+CAP_SETUID
	+CAP_SYS_CHROOT
	+CAP_SYS_RESOURCE
	+CAP_SYS_TTY_CONFIG
	+CAP_AUDIT_WRITE
	# to access user keys
	+CAP_DAC_OVERRIDE

subject /usr/bin/Xorg
	/dev/mem	rw

	+CAP_SYS_ADMIN
	+CAP_SYS_TTY_CONFIG
	+CAP_SYS_RAWIO

subject /usr/bin/ssh
	/etc/ssh/ssh_config r

subject /usr/bin/postgres
	/dev/log rw

subject /usr/bin/exim
	/dev/log rw

subject /usr/sbin/syslog-ng
	+CAP_SYS_ADMIN

subject /usr/sbin/rsyslogd
	+CAP_SYS_ADMIN

subject /usr/sbin/cron
	/dev/log rw

subject /usr/sbin/crond
	/dev/log rw

subject /bin/login
	/dev/log rw
	/var/log/wtmp w
	/var/log/faillog rwcd

subject /bin/su
	/dev/log rw

subject /usr/bin/sudo
	/dev/log rw

subject /sbin/agetty
	/var/log/wtmp w

subject /sbin/init
	/var/log/wtmp w

subject /usr/bin/xauth
	/home r
	/home/*/.Xauthority-* rwcdl

# prevent ld.so breakouts of subjects with /lib rx

# many distros clutter up /lib with shell scripts
# that can be easily hijacked for malicious purposes
subject /usr/lib o
	/ h
	-CAP_ALL
	connect disabled
	bind disabled

subject /usr/lib32 o
	/ h
	-CAP_ALL
	connect disabled
	bind disabled

subject /usr/lib/ld-linux.so.2 o
	/ h
	-CAP_ALL
	connect disabled
	bind disabled

subject /usr/lib/ld-linux-x86-64.so.2 o
	/ h
	-CAP_ALL
	connect disabled
	bind disabled