Page 1 of 1

iproute2's ss utility tries to use CAP_SYS_PTRACE

PostPosted: Fri Oct 07, 2011 11:13 am
by Undine
Having trouble using ss with RBAC.
ss tries to use CAP_SYS_PTRACE and learning reports that this capability must be set in order to successful program operation (resolving program names). I have read capability description and denied this capability in subject. The question is: why it requires this capability if it does not use it (grepping with 'ptrace' on iproute2 sources give not any results)? It just uses /proc. readlink also requires this capability. Is there a reason for panic or this is normal behavior?
version of iproute2 is iproute2-2.6.39.
Thanks.

Re: iproute2's ss utility tries to use CAP_SYS_PTRACE

PostPosted: Fri Oct 07, 2011 9:18 pm
by spender
CAP_SYS_PTRACE is required for more things than just ptrace. Access to certain /proc entries for processes not owned by you can sometimes require this capability (for instance, access to /proc/pid/maps when the vanilla kernel's maps restriction is enabled).

-Brad

Re: iproute2's ss utility tries to use CAP_SYS_PTRACE

PostPosted: Sat Oct 08, 2011 2:03 am
by Undine
spender wrote:CAP_SYS_PTRACE is required for more things than just ptrace. Access to certain /proc entries for processes not owned by you can sometimes require this capability (for instance, access to /proc/pid/maps when the vanilla kernel's maps restriction is enabled).

-Brad

If so, will grsecurity reject ptrace of other processes for example even if CAP_SYS_PTRACE is set (but ptrace is not enabled in subject modes)?

Re: iproute2's ss utility tries to use CAP_SYS_PTRACE

PostPosted: Sat Oct 08, 2011 2:26 am
by spender
Yes, the built-in ptrace restrictions (the same ones in the separate harden ptrace option) will still apply, as will the policy that cross-role/cross-subject ptraces are disallowed.

-Brad