/etc/grsec2/policy is in gradm2 3.1~201701031918-2build1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
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 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 | #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 gradm2 -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 gradm2 to authenticate to the kernel
# A policy for gradm2 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
# Z -> tells gradm to ignore earlier object of the same name and use this
# one instead
#
# 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
# Z -> tells gradm to ignore earlier subject of the same path and use this
# one instead
# 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:
# gradm2 -L /etc/grsec2/learning.logs -E
# and then generate the rules after disabling the system after the
# learning phase with:
# gradm2 -L /etc/grsec2/learning.logs -O /etc/grsec2/policy
# To use full system learning, enable the system like:
# gradm2 -F -L /etc/grsec2/learning.logs
# and then generate the rules after disabling the system after the
# learning phase with:
# gradm2 -F -L /etc/grsec2/learning.logs -O /etc/grsec2/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 in a subject without
# policy inheritance ("o" in subject mode), an implicit +CAP_ALL is used
#
# Also note that policy inheritance does not exist for network policies, only
# file objects and capabilities inherit policy
#
# 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
# files, connect/bind rules, and capabilities can currently be added to a define
define grsec_denied {
/boot h
/dev/grsec h
/dev/kmem h
/dev/mem h
/dev/port h
/etc/grsec2 h
/proc/kcore h
/proc/slabinfo h
/proc/modules h
/proc/kallsyms h
# hide and suppress logs about accessing this path
/lib/modules hs
/lib32/modules hs
/lib64/modules hs
/etc/ssh h
}
# usage:
# $grsec_denied
role shutdown sARG
subject / rvka
/
/dev
/dev/urandom r
/dev/random r
/etc r
/bin rx
/sbin rx
/lib rx
/lib32 rx
/libx32 rx
/lib64 rx
/usr rx
/proc r
$grsec_denied
-CAP_ALL
connect disabled
bind disabled
subject /sbin/init rvkao
/ rwcdmlxi
subject /sbin/halt rvkao
/ rwcdmlxi
/dev/initctl rwf
/run/initctl rwf
/run/systemd/initctl/fifo rwf
subject /sbin/shutdown rvkao
/ rwcdmlxi
/dev/initctl rwf
/run/initctl rwf
/run/systemd/initctl/fifo rwf
# Make sure to unauthenticate with gradm2 -u from
# the admin role after restarting a service
# The service started will run with admin
# privileges until you run gradm2 -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
/run/systemd/initctl/fifo rw
/dev/fd0 r
/dev/cdrom r
/dev/sr0 r
/bin rx
/sbin rx
/lib rx
/lib32 rx
/libx32 rx
/lib64 rx
/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 gradm2 -u
/usr/sbin/sshd
-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
/run/systemd/journal/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/grsec2 h
/home
/home/*/.ssh/authorized_keys r
/home/*/.ssh/authorized_keys2 r
/lib rx
/lib32 rx
/libx32 rx
/lib64 rx
/root
/proc r
/proc/*/oom_adj rw
/proc/*/oom_score_adj rw
/proc/kcore h
/proc/sys h
/proc/sys/kernel/ngroups_max r
/sys/fs/selinux r
/usr/lib rx
/usr/lib32 rx
/usr/libx32 rx
/usr/lib64 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
+CAP_KILL
# to access user keys
+CAP_DAC_OVERRIDE
subject /usr/X11R6/bin/Xorg
/dev/mem rw
+CAP_SYS_ADMIN
+CAP_SYS_TTY_CONFIG
+CAP_SYS_RAWIO
subject /usr/X11R6/bin/XFree86
/dev/mem rw
+CAP_SYS_ADMIN
+CAP_SYS_TTY_CONFIG
+CAP_SYS_RAWIO
-PAX_SEGMEXEC
-PAX_PAGEEXEC
-PAX_MPROTECT
subject /usr/bin/ssh
/etc/ssh/ssh_config r
subject /usr/bin/postgres
/dev/log rw
/run/systemd/journal/dev-log rw
subject /usr/bin/exim
/dev/log rw
/run/systemd/journal/dev-log rw
subject /sbin/klogd
+CAP_SYS_ADMIN
subject /sbin/syslog-ng
+CAP_SYS_ADMIN
subject /usr/sbin/rsyslogd
+CAP_SYS_ADMIN
subject /usr/sbin/cron
/dev/log rw
/run/systemd/journal/dev-log rw
subject /usr/sbin/crond
/dev/log rw
/run/systemd/journal/dev-log rw
subject /bin/login
/dev/log rw
/run/systemd/journal/dev-log rw
/var/log/wtmp w
/var/log/faillog rwcd
subject /bin/su
/dev/log rw
/run/systemd/journal/dev-log rw
subject /usr/bin/sudo
/dev/log rw
/run/systemd/journal/dev-log rw
subject /sbin/getty
/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 /lib o
/ h
-CAP_ALL
connect disabled
bind disabled
subject /lib/ld-linux.so.2 o
/ h
-CAP_ALL
connect disabled
bind disabled
subject /lib64/ld-linux-x86-64.so.2 o
/ h
-CAP_ALL
connect disabled
bind disabled
|