summaryrefslogtreecommitdiff
path: root/kernels/gradm/policy
diff options
context:
space:
mode:
authorAndré Fabian Silva Delgado <emulatorman@parabola.nu>2014-01-04 16:15:54 -0200
committerAndré Fabian Silva Delgado <emulatorman@parabola.nu>2014-01-04 16:15:54 -0200
commit3d21be97935b2c7535275253c82bb425cb4406b6 (patch)
treee556f0f05d0cbfa520095b1509b76d5316331ef7 /kernels/gradm/policy
parent5d21ebe8f537afaeabdf588009e51907e13dc667 (diff)
downloadabslibre-3d21be97935b2c7535275253c82bb425cb4406b6.tar.gz
abslibre-3d21be97935b2c7535275253c82bb425cb4406b6.tar.bz2
abslibre-3d21be97935b2c7535275253c82bb425cb4406b6.zip
gradm: add new package to kernels repo
Diffstat (limited to 'kernels/gradm/policy')
-rw-r--r--kernels/gradm/policy487
1 files changed, 487 insertions, 0 deletions
diff --git a/kernels/gradm/policy b/kernels/gradm/policy
new file mode 100644
index 000000000..55a5811c8
--- /dev/null
+++ b/kernels/gradm/policy
@@ -0,0 +1,487 @@
+#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 /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
+#
+# 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
+#
+# 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:
+# 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, an implicit +CAP_ALL is used
+#
+# 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
+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/cdrom 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/sbin/sshd
+
+ /home/*/.gem/ruby/2.0.0/bin rx
+ /home/*/.rbenv/shims rx
+ /home/*/.rbenv/versions*/bin rx
+ /home/*/.cabal/bin rx
+ /home/*/dev/env rx
+
+ -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
+ /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/kcore h
+ /proc/sys h
+ /proc/sys/kernel/ngroups_max r
+ /selinux r
+ /usr/lib 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
+ # 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/sbin/syslog-ng
+ +CAP_SYS_ADMIN
+
+subject /usr/sbin/rsyslogd
+ +CAP_SYS_ADMIN
+
+subject /usr/sbin/cron
+ /dev/log rw
+
+subject /usr/sbin/crond
+ /dev/log rw
+
+subject /bin/login
+ /dev/log rw
+ /var/log/wtmp w
+ /var/log/faillog rwcd
+
+subject /bin/su
+ /dev/log rw
+
+subject /usr/bin/sudo
+ /dev/log rw
+
+subject /sbin/agetty
+ /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 /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