Jump to content

Grsecurity/Appendix/Role Attributes

From Wikibooks, open books for an open world
Grsecurity/Appendix
Role Modes Role Attributes Subject Modes


role_transitions

[edit | edit source]

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. A common mistake when creating a new special role is forgetting to create a role_transitions rule for the role that will transition to the special role, which a user confuses with having entered an incorrect password. The role_transitions rule is added below the declaration of a role, but before any subject declaration.

Usage:

 role_transitions <special role 1> <special role 2> ... <special role n>

Example:

 role person u
 role_transitions www_admin dns_admin
 subject /
 ...

role_allow_ip

[edit | edit source]

This rule restricts the use of a role to a list of IPs. If a user is on the system who would normally get the rule does not belong to the specified list of IPs, the system falls back through its method of determining a role for the user (checking for an applicable group role then falling back to the default role). This rule can be specified multiple times for a role. Like role_transitions, it should be added below the declaration of a role, but before any subject declaration.

Usage:

 role_allow_ip <IP>/<optional netmask>

Example:

 role person u
 role_allow_ip 192.168.1.0/24
 subject /
 ...

A netmask of 0.0.0.0/32 permits use of the role only by local processes that haven't been used by remote clients [1].

role_umask

[edit | edit source]

This rule can, depending on the mode specified, ensure a number of security properties on files under the control of a given user. One use case is to ensure that a user cannot accidentally or intentionally create a file that others can read (a confidentiality issue). Another is to ensure a user cannot accidentally or intentionally create a file that can be written by others (an integrity issue). Like previous role attributes, it should be added below the declaration of a role, but before any subject declaration.

Usage:

 role_umask <mask>

Example:

 role person u
 role_umask 077
 subject /
 ...
Next Page: Subject Modes | Previous Page: Role Modes
Home: Grsecurity/Appendix