{
	"id": "d53fa164-83fb-40c1-a0ff-eaf6010b3f7c",
	"created_at": "2026-04-06T00:14:23.924791Z",
	"updated_at": "2026-04-10T03:35:21.57082Z",
	"deleted_at": null,
	"sha1_hash": "fd349ea92882be4865ac41e962eba514af0eda06",
	"title": "Grsecurity/The RBAC System - Wikibooks, open books for an open world",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 125746,
	"plain_text": "Grsecurity/The RBAC System - Wikibooks, open books for an\r\nopen world\r\nArchived: 2026-04-05 13:10:59 UTC\r\nA role-based access control (RBAC) system is an approach to restricting system access to authorized users. You\r\nneed an RBAC system if you want to restrict access to files, capabilities, resources, or sockets to all users,\r\nincluding root. This is similar to a Mandatory Access Control (MAC) model. The other features of grsecurity are\r\nonly effective at fending off attackers trying to gain root, so the RBAC system is used to fill in this gap. Least\r\nprivilege can be granted to processes, which, in turn, forces attackers to reevaluate their methods of attack, since\r\ngaining access to the root account no longer means that they have full access to the system. Access can be\r\nexplicitly granted to processes that need it, in such a way that root acts as any other user. Though grsecurity and its\r\nRBAC system are in no means perfect security, they greatly increase the difficulty of successfully compromising\r\nthe system.\r\nIn grsecurity, the RBAC system is managed through a policy file which is essentially a system-wide set of rules.\r\nWhen the RBAC system is activated with gradm, the policy file is parsed and checked for security holes, such as\r\ngranting the default role access to certain sensitive devices and files like the policy file itself. If a security hole is\r\nfound, gradm will refuse to enable the RBAC system, and will give the user a list of things that need to be fixed.\r\nThe policy file is protected when the RBAC system is active, and only the admin role may access it during that\r\ntime. To make it easier to create a secure policy, gradm has the ability to learn how the system functions, and build\r\na least-privilege policy based on the collected data (see Learning Mode).\r\nSo as not to contribute further to the false sense of security many have regarding access control systems (whether\r\nthey be grsecurity's RBAC, SELinux, RSBAC, SMACK, TOMOYO, AppArmor, etc.) it's important first to\r\ndescribe the limitations of any access control system.\r\nThere is a fundamental architectural limitation to the kind of guarantees an access control system can provide\r\nwhen the policy decision-making code resides alongside the Operating System's kernel. A compromise of the\r\nOperating System can easily result in compromise of the access control system, and it is common practice for\r\nexploits which compromise the kernel to disable any active security systems.\r\nGrsecurity is in no way immune to this fundamental limitation, though it does contain several features to help\r\nprevent exploitation of the kernel in the first place and furthermore to make the kernel a more hostile environment\r\nto an attacker if they do manage to exploit certain types of bugs. The project will continue to make adding similar\r\nprotections one of its main goals.\r\nSpecifically, the following features are involved in kernel self-protection and increasing the difficulty of kernel\r\nexploitation:\r\nGRKERNSEC_MODHARDEN\r\nGRKERNSEC_HIDESYM\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 1 of 18\n\nGRKERNSEC_RANDSTRUCT\r\nGRKERNSEC_KSTACKOVERFLOW\r\nPAX_MEMORY_SANITIZE\r\nPAX_MEMORY_UDEREF\r\nPAX_MEMORY_STACKLEAK\r\nPAX_MEMORY_STRUCTLEAK\r\nPAX_CONSTIFY_PLUGIN\r\nPAX_SIZE_OVERFLOW\r\nPAX_KERNEXEC\r\nPAX_RANDKSTACK\r\nPAX_USERCOPY\r\nPAX_REFCOUNT\r\nPAX_RAP\r\nThere also exist some features of grsecurity which are always active (and thus have no configure-time option)\r\nwhich aid in the above goals. These include the read-only and non-executable vsyscall page (and its shadow page)\r\non amd64, hardening of the BPF interpreter buffers, and many more.\r\nThough these features have been successful at preventing previous vulnerabilities from being exploited (and\r\nsurely will continue to do so) there have still been many vulnerabilities it did nothing to prevent exploitation of,\r\nand there are entire classes of vulnerabilities (such as missing capability checks, some race conditions, etc.) that it\r\ncan likely never do anything to prevent exploitation of.\r\nIt's partially due to this fundamental limitation of any access control system that grsecurity's RBAC system was\r\ndesigned as it was: to be as automated as possible, to provide a sufficient level of access control, to have easily\r\neditable human-readable configurations, and to enforce secure base policies to eliminate some administrator error.\r\nNeither grsecurity's RBAC system nor any other access control system should be used to separate classified\r\ninformation from unclassified information on the same machine. There is no virtual replacement for a physical air-gap.\r\nThe policy is made up of roles, subjects and objects. Role is an abstraction that encompasses traditional users and\r\ngroups that exist in Linux distributions and special roles, that are specific to grsecurity. Subjects are processes or\r\ndirectories, and objects are files, capabilities, resources, PaX flags, and IP ACLs. The location of the main policy\r\nfile is /etc/grsec/policy.\r\nTo see a small example policy, look at the default /etc/grsec/policy file that is installed with gradm. In a nutshell,\r\nRBAC policies have the following structure:\r\n role \u003crole1\u003e \u003crolemode\u003e\r\n \u003crole attributes\u003e\r\n subject / \u003csubject mode\u003e\r\n \u003csubject attributes\u003e\r\n / \u003cobject mode\u003e\r\n \u003cextra objects\u003e\r\n \u003ccapability rules\u003e\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 2 of 18\n\n\u003cIP ACLs\u003e\r\n \u003cresource restrictions\u003e\r\n subject \u003cextra subject\u003e \u003csubject mode\u003e\r\n \u003csubject attributes\u003e\r\n / \u003cobject mode\u003e\r\n \u003cextra objects\u003e\r\n ...\r\n role \u003crole2\u003e \u003crolemode\u003e\r\n...\r\nUsing the default policy as an example:\r\n role admin sA\r\n subject / rvka\r\n / rwcdmlxi\r\n role default G\r\n role_transitions admin\r\n subject /\r\n / r\r\n /opt rx\r\n /home rwxcd\r\n /mnt rw\r\n /dev\r\n /dev/grsec h\r\n...\r\nThere exist some features of the RBAC system to aid in simplification and generalization of policies. One of these\r\nis the recently added \"replace\" rule. The replace rule allows you to assign a string to a variable, and then use that\r\nvariable within any subject or object pathname to have it replaced with the string. The syntax of replace rules are:\r\n replace \u003cvariable name\u003e \u003creplace string\u003e\r\nSo for example:\r\n replace CVSROOT /home/cvs\r\nThe defined variable can then be used as follows:\r\n replace CVSROOT /home/cvs\r\n replace PUBHTML public_html\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 3 of 18\n\nsubject $(CVSROOT)/bin/test o\r\n $(CVSROOT)/grsecurity r\r\n /home/spender/$(PUBHTML) r\r\n ...\r\nThe variables defined with replace rules can be reassigned at any location in the policy. All rules in the policy until\r\nanother redefinition of the variable will use that new assigned value for the variable. For example:\r\n replace CVSROOT /home/cvs\r\n $(CVSROOT)/grsecurity r\r\n replace CVSROOT /var/cvs\r\n $(CVSROOT)/test r\r\nwould cause the following object rules to be created:\r\n /home/cvs/grsecurity r\r\n /var/cvs/test r\r\nThere are some special cases you should know about when writing policies for the RBAC system.\r\nThere exist some unique accesses to filesystem objects that require specific object modes. For instance, a process\r\nthat connects to a unix domain socket (/dev/log for example) will need \"rw\" set as the object mode for that socket.\r\nAdding the setgid or setuid flag to a path requires the \"m\" object mode.\r\nCreating a hard-link requires at minimum a \"cl\" object mode. The remaining object flags must match on the target\r\nand the source. So for instance, if a process is creating a hard-link from /bin/bash to /bin/bash2, example rules\r\nwould be:\r\n /bin/bash rx\r\n /bin/bash2 rxcl\r\nCreating a symlink requires the \"wc\" object mode.\r\nOne very useful feature of the RBAC system is the support of wildcards in objects. The \"*\" character matches\r\nzero or more characters, \"?\" matches exactly one character, and \"[]\" can be used to specify an inclusive or\r\nexclusive list or range of characters to match. Depending on how these wildcard characters are used, they have\r\ndifferent effects. Here are four examples of the use of wildcards:\r\n/dev/tty* rw\r\n/home/*/bin rwx\r\n/dev/tty[0-9] rw\r\n/dev/tty? rw\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 4 of 18\n\nThe first example would match /dev/ttya, /dev/tty0, /dev/ttyS0, etc. Since a '*' at the end of a path can match the '/'\r\ncharacter as well, if a '/dev/tty/somefile' path existed, the first example would match it also.\r\nThe second example would match /home/user1/bin, /home/user2/bin, etc. Note that this rule would not match the\r\npath /home/user1/test/bin as the wildcard characters will not match '/' unless it appears at the end of a path. To use\r\nthe particular wildcarded object for this example, a /home object must exist as an \"anchor\" for the wildcarded\r\nobject. If you forget to add one, gradm will remind you.\r\nThe third example would match /dev/tty0, /dev/tty1,..., /dev/tty9 and nothing else.\r\nThe fourth example would match /dev/ttya and /dev/tty0 just like the first example, but would not match /dev/ttyS0\r\nsince only one character can match the '?' wildcard.\r\nWildcards are evaluated at run-time, providing a powerful way of specifying and simplifying policy. Since\r\nwildcard matching is based off pathnames and not inode/device pairs though, they aren't intended to be used for\r\nobjects which are known to be hardlinked at policy enable time.\r\nRoles exist essentially as a container for a set of subjects, put to use in specific scenarios. There exist user roles,\r\ngroup roles, a default role, and special roles. See Flow of Matches to see how a role gets matched with a particular\r\nprocess.\r\nIn a simplified form, user roles are roles that are automatically applied when a process either is executed by a user\r\nof a particular UID or the process changes to that particular UID. In the RBAC system, the name of a user role\r\nmust match up with the name of an actual user on the system.\r\nA user role looks like:\r\nrole user1 u\r\nAs with user roles, group roles pertain to a particular GID. The name of the group role must match up with the\r\nname of an actual group on the system. Note that this is tied only to the GID of a process, not to any supplemental\r\ngroups a process may have. Group roles are applied for a given process only if a user role does not match the\r\nprocess' UID.\r\nA group role looks like:\r\nrole group1 g\r\nIf neither a user or group role match a given process, then it is assigned the default role. The default role should\r\nideally be a role with nearly no access to the system. It is configured in such a way if full system learning is used.\r\nA default role looks like:\r\nrole default\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 5 of 18\n\nSpecial roles are to be used for granting extra privilege to normal user accounts. Some example uses of special\r\nroles are to provide an \"admin\" role that can restart services and edit system configuration files. Special roles can\r\nalso be provided for regular users to keep their accounts more secure. If they have their own public_html directory,\r\nthe user role for the user could keep this directory read-only, while a special role to which the user is allowed to\r\ntransition could allow modification of the files in the directory.\r\nSpecial roles come in two flavors, ones that require authentication, and ones that do not. On the side of special\r\nroles that require authentication, the RBAC system supports a flag that allows PAM authentication to be used for\r\nthe special role. See Role Modes for a list of all these flags.\r\nSpecial roles by themselves won't do anything unless there exist non-special (user, group, or default) roles that can\r\ntransition to them. This transitioning is defined by the role_transitions rule, described in the Role Attributes page.\r\nTo authenticate to a special role, use gradm -a \u003crolename\u003e. To authenticate with PAM to a special role, use\r\ngradm -p \u003crolename\u003e. To transition to a special role that requires no authentication, use gradm -n \u003crolename\u003e.\r\nSpecial roles look like:\r\nrole specialauth s\r\nrole specialnoauth sN\r\nrole specialpamauth sP\r\nWith domains you can combine users that don't share a common group ID as well as groups so that they share a\r\nsingle policy. Domains work just like roles, with the only exception being that the line starting with \"role\" is\r\nreplaced with one of the following:\r\ndomain somedomainname u user1 user2 user3 user4... usern\r\ndomain somedomainname g group1 group2 group3 group4... groupn\r\nExample:\r\ndomain somedomain u daemon bin www-data\r\nsubject /\r\n / h\r\nAs it is with user and group roles, all domain members must exist, and if they're not, an error is raised.\r\nSubjects can describe directories, binaries or scripts. Regular expressions are currently not permitted for subjects.\r\nThe ability to place a subject on a script is unique, as it permits one to grant privilege to a specific script instead of\r\ngenerally to the associated script's interpreter. For this to function properly, make sure the script's interpreter\r\ndirective does not use #!/usr/bin/env but rather the full path to the interpreter.\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 6 of 18\n\nWhen no capability restriction rules are used for a given subject, all capabilities that the system grants normally to\r\nprocesses within that subject are allowed to be used. An exception to this is if the subject involved uses policy\r\ninheritance. In that case, the capability restrictions would come from the subject(s) being inherited from.\r\nCapability rules have the form +CAP_NAME or -CAP_NAME. CAP_ALL is a pseudo-capability meant to\r\ndescribe the entire list of capabilities. It's mainly used to remove all capability usage for a subject, or in\r\nconjunction with a small number of rules granting the ability to use individual capabilities. Provided below are\r\nsome example scenarios of capability restriction usage, along with an explanation of how the policy is interpreted.\r\nScenario #1: In this scenario, we're removing all capabilities from su but CAP_SETUID and CAP_SETGID.\r\n ...\r\n subject /bin/su o\r\n ...\r\n -CAP_ALL\r\n +CAP_SETUID\r\n +CAP_SETGID\r\nScenario #2: In this scenario, we're making use of policy inheritance. Note that the default subject allows\r\nCAP_NET_BIND_SERVICE and CAP_NET_RAW. In our ping subject, we're removing\r\nCAP_NET_BIND_SERVICE, but since we're inheriting from the default subject (note the lack of the o subject\r\nmode on the ping subject), we are still allowed CAP_NET_RAW. Granting important capabilities to default\r\nsubjects is not something allowed by the RBAC system, so this is just an example.\r\n ...\r\n subject /\r\n ...\r\n -CAP_ALL\r\n +CAP_NET_RAW\r\n +CAP_NET_BIND_SERVICE\r\n subject /bin/ping\r\n ...\r\n -CAP_NET_BIND_SERVICE\r\nAuditing and Suppression: Auditing of attempted capability use and suppression of denied capability usage is\r\npossible as well. Capability auditing and suppression supports the same policy inheritance rules as normal\r\ncapability rules. The below example demonstrates auditing the use of CAP_NET_RAW and the suppression of\r\nCAP_NET_BIND_SERVICE denials:\r\n ...\r\n subject /\r\n ...\r\n -CAP_ALL\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 7 of 18\n\n-CAP_NET_BIND_SERVICE suppress\r\n +CAP_NET_RAW audit\r\nFor a full listing of the capabilities available, see: Capability Names and Descriptions. Note that not all of the\r\ncapabilities listed may be supported by your particular version of the Linux kernel.\r\nOne of the features of grsecurity's ACL system is process–based resource restrictions. Using this feature allows\r\nyou to restrict things like how much memory a process can take up, how much CPU time, how many files it can\r\nopen, and how many processes it can execute. Also in this section, we will discuss a \"fake\" resource implemented\r\nin grsecurity's ACL system called \"RES_CRASH\" that helps guard against bruteforce exploit attempts, which is\r\nnecessary if you're using PaX.\r\nA single resource rule follows the following syntax:\r\n\u003cresource name\u003e \u003csoft limit\u003e \u003chard limit\u003e\r\nAn example of this syntax would be:\r\nRES_NOFILE 3 3\r\nThis would allow the process to open a maximum of 3 files (all processes have 3 open file descriptors at some\r\npoint: stdin (standard input), stdout (standard output), and stderr (standard error output)).\r\nTo clarify what the soft limit and hard limit are, the soft limit is the limit assigned to the process when it is run.\r\nThe hard limit is the maximum point to which a process can raise the limit via setrlimit(2), unless they have\r\nCAP_SYS_RESOURCE. In the case of RES_CPU, when the soft limit is overstepped, a special signal is sent to\r\nthe process continuously. When the hard limit is overstepped, the process is killed.\r\nA person who is less familiar with Linux should stick to setting limits on the number of files, the address space\r\nlimit, and number of processes. Of course, you can always use the learning mode of grsecurity to set the resource\r\nlimits for you. The RES_CPU resource is the only one that accepts time as limits. The time defaults to units of\r\nmilliseconds. You can also append a case sensitive unit to your limit.\r\nSome examples would be:\r\n100s – 100 seconds\r\n25m – 25 minutes\r\n65h – 65 hours\r\n2d – 2 days\r\nThe other resources either operate on a number itself or on a size, in bytes. For these you can use the following\r\nunits: K, M, and G, like:\r\n2G – 2 billion\r\n25M – 25 million\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 8 of 18\n\n100K – 100 thousand\r\nIf you don't want any restriction for the soft or hard limit for a resource, you can use \"unlimited\" as the limit. Here\r\nare some more examples to help you understand how this works:\r\nsubject /bin/bash\r\n / r\r\n /opt rx\r\n /home rwxcd\r\n /mnt rw\r\n /dev\r\n /dev/grsec h\r\n RES_CPU 25m 30m\r\n RLIMIT_AS 5M 5M\r\n RLIMIT_NPROC 2 2\r\n RLIMIT_FSIZE 5K 10K\r\n...\r\nFor a list of accepted resource names and units, see System Resources.\r\nThis \"fake\" resource limit is expressed by using the name \"RES_CRASH\" and has the following syntax:\r\nRES_CRASH \u003cnumber of crashes\u003e \u003camt. of time\u003e\r\nFor example, if you wanted to allow the program to crash once every 30 minutes, you would use the following:\r\nRES_CRASH 1 30m\r\nWhat happens when this threshold is reached? Well, the only way to ensure that the process won't crash again is to\r\nkeep it from being executed. If the process is a suid/sgid binary run by a regular user, we kill all processes of that\r\nregular user and keep them from logging in for the amount of time, specified as the second parameter to the\r\nRES_CRASH resource. So for the above example, the user would be locked out of the system for 30 minutes. If\r\nthe process is not a suid/sguid binary, we simply keep the binary from being run again for the amount of time\r\nspecified as the second parameter to the RES_CRASH resource, after killing all processes of that binary.\r\nThe RBAC system supports policies on what local IP addresses and ports can be reserved on the machine, as well\r\nas what remote hosts and ports can be communicated with. These two different accesses are abstracted to bind and\r\nconnect rules, respectively. The syntax for the rules is:\r\n connect \u003cIP/host\u003e/\u003cnetmask\u003e:\u003cport/portrange\u003e \u003csocket type 1\u003e... \u003csocket type n\u003e \u003cproto 1\u003e... \u003cproto\r\n bind \u003cIP/host\u003e/\u003cnetmask\u003e:\u003cport/portrange\u003e \u003csocket type 1\u003e... \u003csocket type n\u003e \u003cproto 1\u003e... \u003cproto n\u003e\r\n or:\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 9 of 18\n\nconnect disabled\r\n bind disabled\r\n\"proto\" can be any of the protocol names listed in /etc/protocol or \"any_proto\" to denote any protocol. \"socket\r\ntype\" is most commonly \"ip\", \"dgram\", or \"stream\", but can also be \"raw_sock\", \"rdm\", or \"any_sock\" to denote\r\nany socket type. Most of the parameters for these rules are optional, particularly the netmask and port or port\r\nrange. If a port is supplied, then at least an IP address of 0.0.0.0/0 needs to be supplied.\r\nAs with capability restrictions, resource restrictions, and many other RBAC features, if the socket policies are\r\nomitted for a given subject, then the subject is allowed to bind or connect to anything normally allowed by the\r\nsystem. Note though that if a connect rule is given, then at least one bind rule must also be specified. Older\r\nversions of gradm (before the 9/16/09 2.1.14 release) will treat the unspecified rule as a \"disabled\" rule, whereas\r\nnew versions will generate an error on such policies.\r\nUnlike with file objects and capabilities, policy inheritance has not been implemented for socket\r\npolicies. Therefore, the socket policies for a given subject are solely determined by that subject alone.\r\nHere are some example rules:\r\n subject /usr/bin/ssh o\r\n ...\r\n connect 192.168.0.0/24:22 stream tcp\r\n connect ourdnsserver.com:53 dgram udp\r\nIn this example, ssh is allowed to connect to ssh servers anywhere on the class C 192.168.0.X network. It is also\r\nallowed to do DNS lookups through the host specified. The hostname is resolved at the time the RBAC system is\r\nenabled.\r\n subject /usr/bin/nc o\r\n ...\r\n bind 0.0.0.0/0:1024-65535 stream tcp\r\n connect 22.22.22.22:5190 stream tcp\r\nIn this example, netcat is allowed to listen on ports 1024 through 65535 on any local interface for TCP\r\nconnections. It is also able to connect to TCP port 5190 of the 22.22.22.22 host.\r\n subject /bin/strange o\r\n ...\r\n bind disabled\r\n connect 192.168.1.5:6000-6006 stream tcp\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 10 of 18\n\nThis example illustrates how you can have bind disabled but still specify connect rules, or conversely, have\r\nconnect disabled and only specify bind rules.\r\nAs you can see from the examples above, you can have as many socket policies as you wish for a given subject,\r\nand as you'll read below there are some powerful extensions to the socket policies.\r\nRules such as:\r\nbind eth1:80 stream tcp\r\nbind eth0#1:22 stream tcp\r\nare allowed, giving you the ability to tie specific socket rules to a single interface (or by using the inverted rules\r\nmentioned below, all but one interface). Virtual interfaces are specified by the \u003cifname\u003e#\u003cvindex\u003e syntax. If an\r\ninterface is specified, no IP/netmask or host may be specified for the rule.\r\nRules such as:\r\nconnect! www.google.com:80 stream tcp\r\nare allowed, which allows you to specify that a process can connect to anything except to port 80 of\r\nwww.google.com with a stream TCP socket. The inverted socket matching also works on bind rules.\r\nIn more recent versions of the RBAC system, PaX flags have been changed from single-letter subject modes to\r\nmore closely resemble how capabilities are handled within the policy. Therefore, PaX flags can now be fully\r\ncontrolled on or off for any given subject by adding +PAX_\u003cfeature\u003e or -PAX_\u003cfeature\u003e within the scope of a\r\nsubject. For a full listing of the PaX flags available, see: PaX Flags.\r\nEach process on the system has a role and a subject attached to it. This section describes how a process is matched\r\nto a role and subject, and how matches are calculated against the objects and capabilities they use. Understanding\r\nthe flow of matches is necessary for manually creating policies.\r\nWhen determining a role for a process, the RBAC system matches based on the following role hierarchy, from\r\nmost specific to least specific:\r\n user -\u003e group -\u003e default\r\nBoth user and group roles are permitted to have the role_allow_ip attributes. When checking the UID or GID\r\nagainst the user or group role, respectively, the role_allow_ip attributes come into play. Imagine the following\r\npolicy:\r\nrole user1 u\r\nrole_allow_ip 192.168.1.5\r\n...\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 11 of 18\n\nIf someone attempted to log in to the machine as user1 from any IP address other than 192.168.1.5, they would not\r\nbe assigned the user1 role. The matching system would then fall back on trying to find an acceptable group role,\r\nor if one could not be found, fall back to the default role.\r\nHierarchy for subjects and objects involves matching a most specific pathname over a less specific pathname. So,\r\nif a /bin object exists, and a /bin/ping object exists, and a process is attempting to read /bin/ping, the /bin/ping\r\nobject would be the one matching. If /bin/su were being accessed instead, then /bin would match.\r\nThe path from most specific to least specific pathname isn't linear however, particularly in the case of subjects\r\nusing policy inheritance. Imagine the following policy:\r\nrole user1 u\r\n subject /\r\n / r\r\n /tmp rwcd\r\n /usr/bin rx\r\n /root r\r\n /root/test/blah r\r\n ...\r\n subject /usr/bin/specialbin\r\n /root/test rw\r\n ...\r\nIf /root/test/blah was being accessed by /usr/bin/specialbin, it would not be able to write to it. The reason for this\r\nis that when going from most specific to least specific for a given path (which involves stripping off each trailing\r\npath component and attempting a match for the resulting pathname), the matching algorithm will look (in order\r\nfrom most specific to least specific) in each of the subjects the current subject inherits from. In this case, the\r\nalgorithm saw that no object existed for /root/test/blah in the /usr/bin/specialbin subject, so upon checking the\r\nsubject for / it found a /root/test/blah object, thus resulting in the read-only permission.\r\nWhen going from most specific to least specific, a globbed object such as /home/* is treated as less specific than\r\n/home/blah (if the requested access is for /home/blah). Globbed objects are matched in the order in which they're\r\nlisted in the RBAC policy. So in the following example:\r\nrole user1 u\r\n subject /\r\n / r\r\n /home r\r\n /home/* r\r\n /home/test* rw\r\n ...\r\nIf a process were accessing /home/testing/somefile it would only be allowed to read it, since the /home/* rule was\r\nlisted first. It was likely that the policy writer didn't intend this behavior (because the /home/test* rule would never\r\nmatch) so the /home/test* object should be swapped to the line the /home/* object is on.\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 12 of 18\n\nWhen determining whether a capability is granted or not, the RBAC system works from most specific subject to\r\nleast specific (in the case of policy inheritance). The first subject along that path that mentions the capability in\r\nquestion is the one that matches. To illustrate:\r\nrole user1 u\r\n subject /\r\n ...\r\n -CAP_ALL\r\n +CAP_NET_BIND_SERVICE\r\n subject /bin\r\n ...\r\n -CAP_NET_BIND_SERVICE\r\n subject /bin/su\r\n ...\r\n +CAP_SETUID\r\n +CAP_SETGID\r\nIn this example, /bin/su is able to use only CAP_SETUID and CAP_SETGID. A lookup on\r\nCAP_NET_BIND_SERVICE would fall back to the /bin subject, since /bin/su inherits from it and did not\r\nexplicitly list a rule for CAP_NET_BIND_SERVICE. The /bin subject specifies that CAP_NET_BIND_SERVICE\r\nbe disallowed. Matching against another capability, CAP_SYS_ADMIN for instance, would end up falling back to\r\nthe / subject, where it would match -CAP_ALL and be denied.\r\nTry to remove as many capabilities from default subjects as possible. The more you remove, the closer root comes\r\nto acting as a regular user. The more capabilities you remove, however, the more subjects you will have to create\r\nfor programs that need those capabilities. The RBAC system will enforce that a minimum level of capabilities be\r\nremoved from all default subjects.\r\nUse full system learning. It will generate a better policy than you would have generated by hand. Make sure you're\r\nmaking full use of the /etc/grsec/learn_config file to specify the files and directories particular to your system that\r\nyou want protected. gradm will do all the heavy lifting of creating privilege boundaries for processes that access or\r\nmodify important data.\r\nAdministrative programs, such as shutdown or reboot, should require authentication instead of giving everyone\r\nthe capabilities to run them.\r\nAlways inspect your kernel logs. The RBAC system provides a great amount of human-readable information in\r\nevery kernel log. Of particular importance is what role and subject were assigned to the process causing an alert. If\r\nyou think that the alert doesn't match up with what you expect from your policy, make sure that the role and\r\nsubject actually match. If they don't, then you may have issues with a role_allow_ip rule that's preventing the\r\nproper role from being applied.\r\nFamiliarize yourself with Linux’s capabilities and what they cover. A full listing of them is available here:\r\nCapability Names and Descriptions.\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 13 of 18\n\nAvoid using policy inheritance until you understand fully how it forms the policy for a given subject. Even then,\r\nuse it sparingly, reserving it generally for cases where a default subject is configured least privilege, with no\r\nreadable/writable/executable objects and no capabilities.\r\nWherever possible, avoid granting both write and execute permission to objects. This gives a potential attacker the\r\nability to execute arbitrary code. Similar to how PaX prevents arbitrary code execution within a given process'\r\naddress space, one of your goals in creating policies is to prevent this on the file system as well.\r\nBe careful using the suppression ('s') object flag, especially when applying it to / to ignore accesses a program\r\ndoes not really need to operate correctly. A change in glibc or another library the subject uses could cause the\r\napplication to fail in a way that will be difficult to debug (unless your first step is to remove the suppression flag).\r\nBelow is the sample policy provided with a gradm installation:\r\nrole admin sA\r\nsubject / rvka\r\n / rwcdmlxi\r\nrole default G\r\nrole_transitions admin\r\nsubject /\r\n / r\r\n /opt rx\r\n /home rwxcd\r\n /mnt rw\r\n /dev\r\n /dev/grsec h\r\n /dev/urandom r\r\n /dev/random r\r\n /dev/zero rw\r\n /dev/input rw\r\n /dev/psaux rw\r\n /dev/null rw\r\n /dev/tty? rw\r\n /dev/console rw\r\n /dev/tty rw\r\n /dev/pts rw\r\n /dev/ptmx rw\r\n /dev/dsp rw\r\n /dev/mixer rw\r\n /dev/initctl rw\r\n /dev/fd0 r\r\n /dev/cdrom r\r\n /dev/mem h\r\n /dev/kmem h\r\n /dev/port h\r\n /bin rx\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 14 of 18\n\n/sbin rx\r\n /lib rx\r\n /usr rx\r\n# compilation of kernel code should be done within the admin role\r\n /usr/src h\r\n /etc rx\r\n /proc rwx\r\n /proc/slabinfo h\r\n /proc/kcore h\r\n /proc/modules h\r\n /proc/sys r\r\n /root r\r\n /tmp rwcd\r\n /var rwxcd\r\n /var/tmp rwcd\r\n /var/log r\r\n# hide the kernel images and modules\r\n /boot h\r\n /lib/modules h\r\n /etc/grsec h\r\n /etc/ssh h\r\n# if sshd needs to be restarted, it can be done through the admin role\r\n# restarting sshd should be followed immediately by a gradm -u\r\n /usr/sbin/sshd\r\n -CAP_KILL\r\n -CAP_SYS_TTY_CONFIG\r\n -CAP_LINUX_IMMUTABLE\r\n -CAP_NET_RAW\r\n -CAP_MKNOD\r\n -CAP_SYS_ADMIN\r\n -CAP_SYS_RAWIO\r\n -CAP_SYS_MODULE\r\n -CAP_SYS_PTRACE\r\n -CAP_NET_ADMIN\r\n -CAP_NET_BIND_SERVICE\r\n -CAP_NET_RAW\r\n -CAP_SYS_CHROOT\r\n -CAP_SYS_BOOT\r\n# RES_AS 100M 100M\r\n# connect 192.168.1.0/24:22 stream tcp\r\n# bind 0.0.0.0 stream dgram tcp udp\r\n# the d flag protects /proc fd and mem entries for sshd\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 15 of 18\n\n# all daemons should have 'p' in their subject mode to prevent\r\n# an attacker from killing the service (and restarting it with trojaned\r\n# config file or taking the port it reserved to run a trojaned service)\r\nsubject /usr/sbin/sshd dpo\r\n / h\r\n /bin/bash x\r\n /dev h\r\n /dev/log rw\r\n /dev/random r\r\n /dev/urandom r\r\n /dev/null rw\r\n /dev/ptmx rw\r\n /dev/pts rw\r\n /dev/tty rw\r\n /dev/tty? rw\r\n /etc r\r\n /etc/grsec h\r\n /home\r\n /lib rx\r\n /root\r\n /proc r\r\n /proc/kcore h\r\n /proc/sys h\r\n /usr/lib rx\r\n /usr/share/zoneinfo r\r\n /var/log\r\n /var/mail\r\n /var/log/lastlog rw\r\n /var/log/wtmp w\r\n /var/run/sshd\r\n /var/run/utmp rw\r\n -CAP_ALL\r\n +CAP_CHOWN\r\n +CAP_SETGID\r\n +CAP_SETUID\r\n +CAP_SYS_CHROOT\r\n +CAP_SYS_RESOURCE\r\n +CAP_SYS_TTY_CONFIG\r\nsubject /usr/X11R6/bin/XFree86\r\n /dev/mem rw\r\n +CAP_SYS_ADMIN\r\n +CAP_SYS_TTY_CONFIG\r\n +CAP_SYS_RAWIO\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 16 of 18\n\n-PAX_SEGMEXEC\r\n -PAX_PAGEEXEC\r\n -PAX_MPROTECT\r\nsubject /usr/bin/ssh\r\n /etc/ssh/ssh_config r\r\nsubject /sbin/klogd\r\n +CAP_SYS_ADMIN\r\nsubject /sbin/syslog-ng\r\n +CAP_SYS_ADMIN\r\nsubject /usr/sbin/cron\r\n /dev/log rw\r\nsubject /bin/login\r\n /dev/log rw\r\n /var/log/wtmp w\r\n /var/log/faillog rwcd\r\nsubject /sbin/getty\r\n /var/log/wtmp w\r\nsubject /sbin/init\r\n /var/log/wtmp w\r\nBelow is a full user role policy that covers the behavior of cvs-pserver when run as the non-root cvs user,\r\nproviding anonymous read-only CVS repository access.\r\nrole cvs u\r\n subject /\r\n / h\r\n -CAP_ALL\r\n connect disabled\r\n bind disabled\r\n subject /usr/bin/cvs\r\n /\r\n /etc/fstab r\r\n /etc/mtab r\r\n /etc/passwd r\r\n /proc/meminfo r\r\n /dev/urandom r\r\n /dev/log rw\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 17 of 18\n\n/dev/null rw\r\n /home/cvs r\r\n /home/cvs/CVSROOT/val-tags rw\r\n /home/cvs/CVSROOT/history ra\r\n /tmp rwcd\r\n /var/lock/cvs rwcd\r\n /var/run/.nscd_socket rw\r\n /proc/sys/kernel r\r\n /var/run\r\nHere's all that's needed for an unprivileged sshd account:\r\nrole sshd u\r\n subject /\r\n / h\r\n /var/run/sshd r\r\n -CAP_ALL\r\n bind disabled\r\n connect disabled\r\nSource: https://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nhttps://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System"
	],
	"report_names": [
		"The_RBAC_System"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "2864e40a-f233-4618-ac61-b03760a41cbb",
			"created_at": "2023-12-01T02:02:34.272108Z",
			"updated_at": "2026-04-10T02:00:04.97558Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "ETDA:WildCard",
			"tools": [
				"RustDown",
				"SysJoker"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "256a6a2d-e8a2-4497-b399-628a7fad4b3e",
			"created_at": "2023-11-30T02:00:07.299845Z",
			"updated_at": "2026-04-10T02:00:03.484788Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "MISPGALAXY:WildCard",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434463,
	"ts_updated_at": 1775792121,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fd349ea92882be4865ac41e962eba514af0eda06.pdf",
		"text": "https://archive.orkl.eu/fd349ea92882be4865ac41e962eba514af0eda06.txt",
		"img": "https://archive.orkl.eu/fd349ea92882be4865ac41e962eba514af0eda06.jpg"
	}
}