diff options
Diffstat (limited to 'main/gradm/policy')
| -rw-r--r-- | main/gradm/policy | 211 |
1 files changed, 211 insertions, 0 deletions
diff --git a/main/gradm/policy b/main/gradm/policy new file mode 100644 index 0000000000..e5a3df439c --- /dev/null +++ b/main/gradm/policy @@ -0,0 +1,211 @@ +# Base grsecurity policy for Alpine. +# +# If you want to use a custom policy, or add on local modifications to +# the system policy, edit below the include line or remove the include +# line to completely remove the system policy entirely from your setup. +# +# Documentation on the file format as provided in the sample policy file +# follow below for your reference: +## 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. +# +# 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 +# a -> allow this process to talk to the /dev/grsec device +# +# 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. +# +# 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 +# +# 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 +# + +# +# Default security policy provided by packages in Alpine are installed into +# /var/lib/grsec/policy.d as /var/lib/grsec/policy.d/$pkgname where $pkgname +# is the package name. It is not recommended that you edit those definitions +# unless you know what you're doing, as the Alpine system may depend on the +# presence of those definitions. +# + +include </var/lib/grsec/policy.d> + +# +# If you wish to add any additions to the system policy, you may do so below +# this line. As the configuration is read top-to-bottom, any changes you make +# here may override the default security policy. +# + |