grsecurity forums

Hi.
I'm using Ubuntu 12.04 amd64, kernel 3.2.26 patched with grsecurity-2.9.1-3.2.26-201208062017 and RBAC enabled.

I've encountered a problem with cups printing system. When trying to print cupsd fails to execute backend subprocess and grsec reports:

Code: Select all

grsec: (root:U:/usr/sbin/cupsd) denied ptrace of /usr/lib/cups/backend/ipp14 by /usr/lib/cups/backend/ipp14[cupsd:7659] uid/euid:0/0 gid/egid:7/7, parent /usr/sbin/cupsd[cupsd:7394] uid/euid:0/0 gid/egid:0/0


The strange thing is that cupsd is not doing any ptrace calls - just plain execve() of ipp14.

It gets even better - if I attach strace (running from admin role) to cupsd process everything works correctly - after detaching ptrace error comes back.

Adding 'r' subject flag to /usr/sbin/cupsd doesn't change anything.

I've seen this error before with different processes (e.g. udev executed from init), so it's not specific to cups, but it's a good reproducible test case.

Let me know if you need more info, I'll be more than happy to debug this further.

Hi,

Cupsd must have ptraced itself and then attempted to execute the ipp14 binary. This is the origin of the GR_PTRACE_EXEC_ACL_MSG you saw. When a binary is being actively ptraced, LSM_UNSAFE_PTRACE/LSM_UNSAFE_PTRACE_CAP can be set and are checked at exec time. As for why it's doing this, you'd have to consult the source to the apps involved. I disallow these execs when it allows one process to ptrace into another task (a violation of privilege boundaries). I do specifically allow it for subjects with the 't' mode (which allows them to ptrace any task) and also if the tracer is in the admin role (as you observed).

-Brad

Hi Brad.
I've already checked cups source and it's not using ptrace() at all. The only thing that I can think of regarding ptrace is upstart - it's using ptrace to monitor started jobs (including cups daemon). However it's mystery why those problems affect only a couple of apps instead of all daemons started from upstart.

Is the LSM_UNSAFE_PTRACE flag you mentioned inherited even across multiple fork()/execve()?

Also, could you please clarify the impact of 't' subject mode? Does 'allow them to ptrace any task' mean it grants the subject even the right to ptrace processes from different uids (equivalent to CAP_SYS_PTRACE under vanilla kernel) or does it just relax all additional grsec protections leaving cross-uid barrier enabled?

Best regards.

It just relaxes all grsecurity-imposed restrictions, leaving the normal Linux checks in place.

As long as a task remains ptraced, then the LSM_UNSAFE_PTRACE will be set for every exec.

If the tracer is upstart, then placing the 't' mode on upstart should resolve the issue.

-Brad