#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 /usr/bin/su:/usr/bin/bash:/usr/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 /usr/bin/cat is executed from /usr/bin/bash, which is
# executed from /usr/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 /usr/bin/su:/usr/bin/bash,
# and the subject /usr/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 /usr/bin/su
# user_transition_allow root spender
# group_transition_allow root spender
# subject /usr/bin/su
# user_transition_deny evilhacker
# subject /usr/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 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/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/sr0	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/bin/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/bin/sshd dpo
	/
	/*		h
	/usr/bin/bash	x
	/dev		h
	/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/*/oom_score_adj rw
	/proc/kcore	h
	/proc/sys	h
	/proc/sys/kernel/ngroups_max r
	/selinux	r
	/usr/lib	rx
	/usr/lib32	rx
	/usr/libx32	rx
	/usr/share/zoneinfo r
	/var/log
	/var/spool/mail
	/var/log/lastlog	rw
	/var/log/wtmp		w
	/var/run
	/run
	/run/systemd/journal/dev-log	rw
	/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
	/run/systemd/journal/dev-log	rw

subject /usr/bin/exim
	/run/systemd/journal/dev-log	rw

subject /usr/bin/syslog-ng
	+CAP_SYS_ADMIN

subject /usr/bin/rsyslogd
	+CAP_SYS_ADMIN

subject /usr/bin/cron
	/run/systemd/journal/dev-log	rw

subject /usr/bin/crond
	/run/systemd/journal/dev-log	rw

subject /usr/bin/login
	/run/systemd/journal/dev-log	rw
	/var/log/wtmp w
	/var/log/faillog rwcd

subject /usr/bin/su
	/run/systemd/journal/dev-log	rw

subject /usr/bin/sudo
	/run/systemd/journal/dev-log	rw

subject /usr/bin/agetty
	/var/log/wtmp w

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

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

# many distros clutter up /usr/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