path: root/unmaintained/gradm/policy

# 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.
#