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