task_for_pid failed on mac osx 10.11 el capitan

[linshuai2012]

In the function initprocesstree_sysdep (file sysdep_DARWIN.c) it uses task_for_pid to gather the information (e.g. cpu/mem resources) of all processes in the system.

In OSX 10.11 the new "system integrity protection" feature made this call to task_for_pid always failing. In system logs there are logs like this (one line for each pid being checked):

Oct 17 22:03:49 MacBook-Pro kernel[0]: Sandbox: monit(57901) System Policy: deny(1) mach-priv-task-port 1

One possible solution is mentioned in the second reference link.

Reference links:

• https://developer.apple.com/library/watchos/documentation/Security/Conceptual/System_Integrity_Protection_Guide/System_Integrity_Protection_Guide.pdf
• http://os-tres.net/blog/2010/02/17/mac-os-x-and-task-for-pid-mach-call/

[linshuai2012]

Currently I modified /etc/asl.conf (config for apple syslog) to ignore these logs to avoid /var/log/system.log being constantly flooded by these messages:

> sandbox-monit.log mode=0640 format=bsd rotate=seq compress file_max=5M all_max=50M
? [S= Message monit] [S= Message mach-priv-task-port] ignore

[Tildeslash]

Thank you. From this WWDC video we can see that task_for_pid and possibly other calls that Monit needs to monitor a system are restricted or limited in El Capitan. We’ll certainly look into this and see if Monit, despite the new security framework, can find a useful place in El Capitan.

[linshuai2012]

:+1:

[Tildeslash]

Fixed issue #266 On OS X El Capitan, do not call task_for_pid if System Integrity Protection is enabled (which is the default)

→ <<cset 47960037062b>>

[Tildeslash]

Fixed issue #266: On OS X El Capitan, do not call task_for_pid if System Integrity Protection is enabled (which is the default)

→ <<cset 2fbf24563b88>>

[t.koenig]

Hmm, this seems to work as expected if System Integrity Protection is enabled.

But with System Integrity Protection disabled (via csrutil disable) it seems that task_for_pid will still fail:

Nov 25 11:24:07 app-staging kernel[0] <Notice>: Sandbox: monit(46) System Policy: allow(0) mach-priv-task-port 64
Nov 25 11:24:07 app-staging kernel[0] <Notice>: Sandbox: monit(46) System Policy: allow(0) mach-priv-task-port 63
Nov 25 11:24:07 app-staging kernel[0] <Notice>: Sandbox: monit(46) System Policy: allow(0) mach-priv-task-port 62
Nov 25 11:24:07 app-staging kernel[0] <Notice>: Sandbox: monit(46) System Policy: allow(0) mach-priv-task-port 59
Nov 25 11:24:07 app-staging kernel[0] <Notice>: Sandbox: monit(46) System Policy: allow(0) mach-priv-task-port 58
Nov 25 11:24:07 app-staging kernel[0] <Notice>: Sandbox: monit(46) System Policy: allow(0) mach-priv-task-port 56
Nov 25 11:24:07 app-staging kernel[0] <Notice>: Sandbox: monit(46) System Policy: allow(0) mach-priv-task-port 51
Nov 25 11:24:07 app-staging kernel[0] <Notice>: Sandbox: monit(46) System Policy: allow(0) mach-priv-task-port 50

I guess this is not the expected behavior?

[Tildeslash]

Removing version: 5.15 (automated comment)