How do nested subjects work?

[mnalis]

error is:
grsec: (default:D:/) use of CAP_SYS_TTY_CONFIG denied for /usr/bin/chrt[chrt:3841] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0

under default role I have specified:

subject /sbin/init
/usr/bin/chrt rx
/dev/log rw
+CAP_SYS_TTY_CONFIG

subject /sbin/init:/usr/bin/chrt
+CAP_SYS_TTY_CONFIG

(ignoring for the moment the fact I have no idea why chrt(1) would need such capability in the first place)
kernel is 2.6.32.16 with grsecurity-2.2.0-2.6.32.16-201007162107.patch

[spender]

For the nested subject to work, the RBAC system has to see the execution of the binary involved in the nesting. In this case, that doesn't seem to have happened, so the process has been given the default subject. I'll look into the use of CAP_SYS_TTY_CONFIG: has this just appeared in a recent patch?

-Brad

[spender]

BTW I should mention that it may not be the case that chrt necessarily needs CAP_SYS_TTY_CONFIG. The kernel developers seemingly don't care about checking for the existence of the capability regardless of whether it will actually be used or not. When I find this to be the case, I reorder the checks so that non-capability-based security checks are performed first, move the check to where it's actually going to request access, or suppress the logging of the denial if neither change is possible.

-Brad

[mnalis]

I didn't use chrt under grsec before, so I can't say if it is due to latest patch, but I think I recall seeing spurious CAP_SYS_TTY_CONFIG being logged before on other programs in grsec previous versions...
As for the main problem, if I understand you correctly, I could just add empty:

Code: Select all

subject /usr/bin/chrt

(to grant no additional permissions), and then the:

Code: Select all

subject /sbin/init:/usr/bin/chrt
  +CAP_SYS_TTY_CONFIG

would work correctly ?

[spender]

That will work if /sbin/init is the process that executed /usr/bin/chrt and the execution was done after the RBAC system was enabled with gradm -E. I don't know that to be the case. In some situations, a process can be re-parented to init if its parent terminates itself. You could use exec auditing from within the default subject of the default role:
/usr/bin/chrt rxX

And this will log the parent of chrt at exec time. Whether this actually be /sbin/init or something else, it's what you want to use in place of /sbin/init in the nested subject line. Also, it's not /usr/bin/chrt that needs an additional subject, but /sbin/init, or whatever the real parent happens to be. This is because for any nested subject to be reached for that parent, the subject for that parent must first be applied (nested subjects are attached to the associated subject).

I'll try to update the wiki soon with some examples of nested subjects.

-Brad