#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 # 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 ... # 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 # # 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 # 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/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/*/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 /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/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/bin/syslog-ng +CAP_SYS_ADMIN subject /usr/bin/rsyslogd +CAP_SYS_ADMIN subject /usr/bin/cron /dev/log rw subject /usr/bin/crond /dev/log rw subject /usr/bin/login /dev/log rw /var/log/wtmp w /var/log/faillog rwcd subject /usr/bin/su /dev/log rw subject /usr/bin/sudo /dev/log rw subject /usr/bin/agetty /var/log/wtmp w subject /usr/bin/init /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