Denials for new instances of a process - what to do?
Posted: Wed Jul 16, 2014 7:15 amI'm currently running 3.15.3-hardened-r2, but will soon boot 3.15.5-hardened-r1.
I'm seeing denials in the logs, where the name of the process is appended by "#new". The denied access or capability is otherwise allowed for the binary in the policy and user running the process is as expected.
Here are some examples:
Jul 16 11:51:50 kernel: grsec: (root:U:/) use of CAP_SYS_ADMIN denied for /usr/lib64/systemd/systemd-journald#new[systemd-journal:331] uid/euid:0/0 gid/egid:0/0, parent /usr/lib64/systemd/systemd#new[systemd:1] uid/euid:0/0 gid/egid:0/0
Jul 16 11:51:13 kernel: grsec: (root:U:/) denied truncate of /var/log/journal/a650832eeba407dc74c567a350453962/system.journal by /usr/lib64/systemd/systemd-journald#new[systemd-journal:331] uid/euid:0/0 gid/egid:0/0, parent /usr/lib64/systemd/systemd#new[systemd:1] uid/euid:0/0 gid/egid:0/0
Jul 16 11:52:56 kernel: grsec: (root:U:/) denied access to hidden file /sys/fs/cgroup/systemd by /usr/lib64/systemd/systemd#new[systemd:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper/0:0] uid/euid:0/0 gid/egid:0/0
Jul 16 11:52:56 kernel: grsec: (root:U:/) denied connect() to the unix domain socket /run/systemd/journal/stdout by /usr/lib64/systemd/systemd#new[(tmpfiles):13408] uid/euid:0/0 gid/egid:0/0, parent /usr/lib64/systemd/systemd#new[systemd:1] uid/euid:0/0 gid/egid:0/0
Jul 16 12:35:49 kernel: grsec: (root:U:/) use of CAP_NET_ADMIN denied for /usr/lib64/systemd/systemd#new[(d-logind):13858] uid/euid:0/0 gid/egid:0/0, parent /usr/lib64/systemd/systemd#new[systemd:1] uid/euid:0/0 gid/egid:0/0
Of course, all the above mentioned access rights were given to systemd and logind in the policy for user root. These log entries were generated during a login attempt. The login succeeded, but it took long. Probably the system were busy dealing with these restrictions.
Is it and inherintace related symptom? I'm not sure if it is good to specify "i" for systemd as inherited processes would gain unnecessary privileges...
Where I should start solving these denials?
Thanks for any ideas:
Dw.
I'm seeing denials in the logs, where the name of the process is appended by "#new". The denied access or capability is otherwise allowed for the binary in the policy and user running the process is as expected.
Here are some examples:
Jul 16 11:51:50 kernel: grsec: (root:U:/) use of CAP_SYS_ADMIN denied for /usr/lib64/systemd/systemd-journald#new[systemd-journal:331] uid/euid:0/0 gid/egid:0/0, parent /usr/lib64/systemd/systemd#new[systemd:1] uid/euid:0/0 gid/egid:0/0
Jul 16 11:51:13 kernel: grsec: (root:U:/) denied truncate of /var/log/journal/a650832eeba407dc74c567a350453962/system.journal by /usr/lib64/systemd/systemd-journald#new[systemd-journal:331] uid/euid:0/0 gid/egid:0/0, parent /usr/lib64/systemd/systemd#new[systemd:1] uid/euid:0/0 gid/egid:0/0
Jul 16 11:52:56 kernel: grsec: (root:U:/) denied access to hidden file /sys/fs/cgroup/systemd by /usr/lib64/systemd/systemd#new[systemd:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper/0:0] uid/euid:0/0 gid/egid:0/0
Jul 16 11:52:56 kernel: grsec: (root:U:/) denied connect() to the unix domain socket /run/systemd/journal/stdout by /usr/lib64/systemd/systemd#new[(tmpfiles):13408] uid/euid:0/0 gid/egid:0/0, parent /usr/lib64/systemd/systemd#new[systemd:1] uid/euid:0/0 gid/egid:0/0
Jul 16 12:35:49 kernel: grsec: (root:U:/) use of CAP_NET_ADMIN denied for /usr/lib64/systemd/systemd#new[(d-logind):13858] uid/euid:0/0 gid/egid:0/0, parent /usr/lib64/systemd/systemd#new[systemd:1] uid/euid:0/0 gid/egid:0/0
Of course, all the above mentioned access rights were given to systemd and logind in the policy for user root. These log entries were generated during a login attempt. The login succeeded, but it took long. Probably the system were busy dealing with these restrictions.
Is it and inherintace related symptom? I'm not sure if it is good to specify "i" for systemd as inherited processes would gain unnecessary privileges...
Where I should start solving these denials?
Thanks for any ideas:
Dw.