grsecurity forums

Due to some recent changes in the configuration of my machines, I see that the processes on the systems doesn't have the right to access file descriptors and some other elements of /proc/PID. For example I frequently see logs of failed access of standard out, while sshd tried to access /proc/PID/oom_score_adj and /proc/PID/loginuid.
I can handle these case by specifying /proc/*/whatever for the respective process in the policy, but I would rather let an arbitrary process access its standard file descriptors and some other stuff under /proc/PID by default. So how I should properly define these for a role? Defining /proc/*/whatever at the role level has questionable meaning, since the PID directories are created run-time. By the time loading the policy they may not exist. I may also try to define /proc/self/whatever, but I receive warnings, since that is a symlink to /proc/PID. I'm not sure how these symlinks are treated, when they get resolved? Specifying /proc/self for a role also raises questions and warning, since for example there is another symlink /proc/self/root pointing to /.

So what would be a proper policy rule to let processes of a role access their standard FDs (and possibly some other /proc stuff) by default, without changing the configuration?

Thx:
Dw.

Defining /proc/*/whatever at the role level has questionable meaning, since the PID directories are created run-time

It is not questionable, wildcards in policy are evaluated at runtime:
see http://en.wikibooks.org/wiki/Grsecurity ... ed_Objects


Note that there is no support for template variables in grsec policy (although it would be nice if one could do things with policy allowing access only for stuff like /home/$USERNAME/xxxx or /proc/$PID/yyyy or /tmp/$UID/ etc)

so I think you should just go ahead and use "/proc/*/loginuid".