archlinuxarm/PKGBUILDs
1
0
Fork 0
mirror of https://github.com/archlinuxarm/PKGBUILDs.git synced 2024-12-08 23:03:46 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
PKGBUILDs/community/gradm/policy
Kevin Mihelich 721849e71b added community/gradm
2014-04-18 01:55:37 +00:00

493 lines
14 KiB
Text
Raw Blame History

#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/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/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
# 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
Reference in a new issue View git blame Copy permalink