#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 polciy for gradm2 will automatically be added to the role
# T -> Enable TPE for this role
# l -> Enable learning 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
#
# 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.
# 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
#
# New learning system:
# To learn on a given subject: add l (the letter l, not the number 1)
# to the subject mode
# 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/grsec/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/grsec/policy

role admin sA
subject / rvk
	/ rwcdmlxi

role default G
role_transitions admin
subject /
	/		r
	/opt		rx
	/home		rwxcd
	/mnt		rw
	/dev
	/dev/grsec	h
	/dev/urandom	r
	/dev/random	r
	/dev/zero	rw
	/dev/input	rw
	/dev/psaux	rw
	/dev/null	rw
	/dev/tty0	rw
	/dev/tty1	rw
	/dev/tty2	rw
	/dev/tty3	rw
	/dev/tty4	rw
	/dev/tty5	rw
	/dev/tty6	rw
	/dev/tty7	rw
	/dev/tty8	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
	/dev/mem	h
	/dev/kmem	h
	/dev/port	h
	/bin		rx
	/sbin		rx
	/lib		rx
	/usr		rx
	/etc		rx
	/proc		rwx
	/proc/kcore	h
	/proc/sys	r
	/root		r
	/tmp		rwcd
	/var		rwxcd
	/var/tmp	rwcd
	/var/log	r
	/boot		r
	/etc/grsec2	h
	/etc/ssh	h

# if sshd needs to be restarted, it can be done through the admin role
	/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_SYS_CHROOT
	-CAP_SYS_BOOT

#	RES_AS 100M 100M

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

subject /sbin/klogd dpo {
	/		h
	/dev		h
	/dev/log	rw
	/etc/grsec	h
	/etc/grsec2	h
	/etc/ssh	h
	/proc		h
	/proc/kmsg	r
	-CAP_ALL
	+CAP_SYS_ADMIN
	bind	disabled
	connect	disabled
}

subject /usr/sbin/cron dpo {
	/				h
	/bin				h
	/bin/sh				rx
	/dev				h
	/dev/log			rw
	/etc				r
	/etc/grsec			h
	/etc/grsec2			h
	/etc/ssh			h
	/lib				h
	/lib/security/pam_env.so	rx
	/lib/security/pam_unix.so	rx
	/lib/tls			h
	/lib/tls/libcrypt-*.so		rx
	/root
	/var				h
	/var/spool/cron/crontabs
	-CAP_ALL
	+CAP_SETGID
	+CAP_SETUID
	bind	disabled
	connect	disabled
}

# 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/grsec2	h
	/home
	/lib		rx
	/root
	/proc
	/proc/kcore	h
	/proc/sys	h
	/usr/lib	rx
	/usr/share/zoneinfo r
	/var/log
	/var/mail
	/var/log/lastlog	rw
	/var/log/wtmp		w
	/var/run/sshd
	/var/run/utmp		rw

	-CAP_ALL
	+CAP_CHOWN
	+CAP_SETGID
	+CAP_SETUID
	+CAP_SYS_CHROOT
	+CAP_SYS_RESOURCE
	+CAP_SYS_TTY_CONFIG

subject /usr/X11R6/bin/XFree86
	/dev/mem	rw

	+CAP_SYS_ADMIN
	+CAP_SYS_TTY_CONFIG
	+CAP_SYS_RAWIO

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

subject /sbin/klogd
	+CAP_SYS_ADMIN

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