aboutsummaryrefslogtreecommitdiffstats
path: root/unmaintained/gradm/policy
blob: e5a3df439c54b11fbeb32b1323ae06309cc6c69f (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
# Base grsecurity policy for Alpine.
#
# If you want to use a custom policy, or add on local modifications to
# the system policy, edit below the include line or remove the include
# line to completely remove the system policy entirely from your setup.
#
# Documentation on the file format as provided in the sample policy file
# follow below for your reference:
## 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.
#
# 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
# 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
#
# 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.
#
# 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
#
# 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
#

#
# Default security policy provided by packages in Alpine are installed into
# /var/lib/grsec/policy.d as /var/lib/grsec/policy.d/$pkgname where $pkgname
# is the package name.  It is not recommended that you edit those definitions
# unless you know what you're doing, as the Alpine system may depend on the
# presence of those definitions.
#

include </var/lib/grsec/policy.d>

#
# If you wish to add any additions to the system policy, you may do so below
# this line.  As the configuration is read top-to-bottom, any changes you make
# here may override the default security policy.
#