Mac OS X kernel sandbox system policy errors are back

[47ronin]

Mac OS X El Capitan v10.11.3 here. Log is spilling with these:
3/15/16 15:00:52.000 kernel[0]: Sandbox: htop(939) System Policy: deny(1) mach-priv-task-port 107 after running sudo htop 😢

htop --version
htop 2.0.1 - (C) 2004-2016 Hisham Muhammad
Released under the GNU GPL.

[hishamhm]

@mklein-de Do you have any idea? I thought the seteuid tweaks took care of this, but I may be misunderstanding it.

[47ronin]

With htop installed from Homebrew, reverting back to 2.0.0 eliminates the errors.

[hishamhm]

Oh. I just realized that to get detailed process information, htop 2.0.1 uses task_for_pid, which is a function that requires special permissions: http://os-tres.net/blog/2010/02/17/mac-os-x-and-task-for-pid-mach-call/

According to the above link, it seems I need to add a PropertyList file (which I haven't figured out what it is yet) and add some initialization code to the source to get proper capabilities. I can add the initialization code to the source, but it won't do much good unless the binaries are signed.

Paging @MikeMcQuaid: Does Homebrew ship signed binaries?

[hishamhm]

@47ronin I added a minor tweak now that makes it try only once per process. It's not yet a full solution but it should alleviate the issue. If possible, please try to build from current Git and let me know if it works better.

[MikeMcQuaid]

@hishamhm It does not, sorry.

[47ronin]

Removed all traces of the Homebrew htop versions 2.0.0 and 2.0.1, then installed from Git source (master)

$ cd htop-master/
htop-master$ ./autogen.sh && ./configure && make
…
$ make install

With sudo htop from Git source (master) the errors are occurring again. Detailed report:

htop(37683) System Policy: deny mach-priv-task-port

Process:         htop [37683]
Path:            /usr/local/bin/htop
Load Address:    0x102feb000
Identifier:      htop
Version:         ??? (???)
Code Type:       x86_64 (Native)
Parent Process:  sudo [37681]
User ID:         0

Date/Time:       2016-03-31 11:30:02.171 -0700
OS Version:      Mac OS X 10.11.4 (15E65)
Report Version:  8

Thread 0:
0   libsystem_kernel.dylib          0x00007fff9b30d002 task_for_pid + 10
1   htop                            0x0000000102ffca6f ProcessList_goThroughEntries + 415 (DarwinProcessList.c:176)
2   htop                            0x0000000102ff546a ProcessList_scan + 90 (ProcessList.c:329)
3   htop                            0x0000000102ff07c6 main + 1046 (htop.c:156)
4   libdyld.dylib                   0x00007fff8fd835ad start + 1

Binary Images:
       0x102feb000 -        0x102fffff3  htop (0) <9b14cef9-6876-3b71-bf5a-4ce1880da8d3> /usr/local/bin/htop
    0x7fff8fd80000 -     0x7fff8fd83ffb  libdyld.dylib (360.21) <8390e026-f7de-3c32-9486-3dff6bd131b0> /usr/lib/system/libdyld.dylib
    0x7fff9b2fc000 -     0x7fff9b31aff7  libsystem_kernel.dylib (3248.40.184) <88c17b7f-1cd8-3979-a1a9-f7bdb4fce789>     /usr/lib/system/libsystem_kernel.dylib

[hishamhm]

@47ronin does it keep appearing at the same rate? Or does it show a bunch of errors at start up and then stops? (This is what I'd expect)

[mklein-de]

Hi, this has nothing to do with the seteuid tweak, this only mitigates the risk when running htop setuid root.

I think you are right with the need for the .plist file and code signing requirement. I tried to hack this into the old htop-osx-fork before I found out that recent versions support Darwin out of the box ;-)

Regarding the try-only-once-per process hack:

With 2.0.1:

Apr  1 22:14:08 havorn sudo[12747] <Notice>:  michael : TTY=ttys000 ; PWD=/Volumes/Users/michael/Source/htop ; USER=root ; COMMAND=./htop
Apr  1 22:14:08 havorn kernel[0] <Notice>: Sandbox: htop(12748) System Policy: deny(1) mach-priv-task-port
--- last message repeated 334 times ---
Apr  1 22:14:08 havorn sandboxd[150] ([12748]) <Notice>: htop(12748) System Policy: deny mach-priv-task-port
--- last message repeated 7 times ---
Apr  1 22:14:08 havorn kernel[0] <Notice>: Sandbox: htop(12748) System Policy: deny(1) mach-priv-task-port
--- last message repeated 163 times ---
Apr  1 22:14:08 havorn kernel[0] <Notice>: *** kernel exceeded 500 log message per second limit  -  remaining messages this second discarded ***
Apr  1 22:14:10 havorn kernel[0] <Notice>: Sandbox: htop(12748) System Policy: deny(1) mach-priv-task-port
--- last message repeated 342 times ---
Apr  1 22:14:11 havorn kernel[0] <Notice>: Sandbox: htop(12748) System Policy: deny(1) mach-priv-task-port
--- last message repeated 342 times ---
Apr  1 22:14:13 havorn kernel[0] <Notice>: Sandbox: htop(12748) System Policy: deny(1) mach-priv-task-port
--- last message repeated 342 times ---
Apr  1 22:14:14 havorn kernel[0] <Notice>: Sandbox: htop(12748) System Policy: deny(1) mach-priv-task-port
--- last message repeated 342 times ---
Apr  1 22:14:16 havorn kernel[0] <Notice>: Sandbox: htop(12748) System Policy: deny(1) mach-priv-task-port
--- last message repeated 342 times ---
Apr  1 22:14:18 havorn kernel[0] <Notice>: Sandbox: htop(12748) System Policy: deny(1) mach-priv-task-port
--- last message repeated 342 times ---

With 306c5443ae0aec17c26f194ef624b6c4cc5b30de the errors appear only during startup, as expected:

Apr  1 22:15:00 havorn sudo[15792] <Notice>:  michael : TTY=ttys000 ; PWD=/Volumes/Users/michael/Source/htop ; USER=root ; COMMAND=./htop
Apr  1 22:16:11 havorn sudo[19127] <Notice>:  michael : TTY=ttys000 ; PWD=/Volumes/Users/michael/Source/htop ; USER=root ; COMMAND=./htop
Apr  1 22:16:11 havorn syslogd[52] <Notice>: ASL Sender Statistics
Apr  1 22:16:11 havorn kernel[0] <Notice>: Sandbox: htop(19128) System Policy: deny(1) mach-priv-task-port
--- last message repeated 77 times ---
Apr  1 22:16:11 havorn sandboxd[150] ([19128]) <Notice>: htop(19128) System Policy: deny mach-priv-task-port
--- last message repeated 7 times ---

[hishamhm]

@mklein-de Thanks for testing! So what's the situation with these permission errors?

Are we allowed to call task_for_pid for our own processes, at least? (If so, we could check that the process is ours before trying.)

Or if we get one failure we can assume that the htop binary can't call task_for_pid at all? (In the latter case, then we could move the taskAcess boolean into a static global, so we try it at most once.)

[mklein-de]

According to https://en.wikipedia.org/wiki/System_Integrity_Protection, the protection applies to executables residing in certain system directories like /usr/bin or /System, irrespective of the owner.

This is consistent with the observation that task_for_pid succeeds for e.g. /opt/local/bin/smartd (process owned by root, installed by myself), but always fails for e.g. /usr/bin/vi.

I guess the try-once-per-process approach is the best we can do here.

[axet]

Seems like you have to pay money to apple if you desier to develop 'process monitor' apps.

It is apple ps.c has entitlements.plist file, with 'task_for_pid-allow' parameter requires paid subscription.

http://opensource.apple.com/source/adv_cmds/adv_cmds-163/ps/

codesign -s - --entitlements entitlements.plist -f htop

This is only possible if you a paid developer. Which means it gives you no additional protection from 'hackers' but involves money. I think it is very bad move from Apple, 'bad' people always can find the way to infect your machine even with signed code, or leaked keys, but it just strip good people from using Apple hardware.

Console Log:
27/04/16 18:09:25,769 taskgated[102]: killed [pid 59201] because its use of the task_for_pid-allow entitlement is not allowed (error code -67050)

Crash Report:
Exception Type: EXC_CRASH (Code Signature Invalid)

[tlhunter]

Duplicate of #330, which is the first thing that comes up in a google search.

[47ronin]

@tlhunter not really a duplicate because this is from the official build that now supports OS X. It worked flawlessly in v2.0 but subsequent updates within the last month or two caused the errors to reoccur.

[tlhunter]

Just trying to help the googlers ;)

[hishamhm]

@47ronin the errors returned because htop is now trying to read more accurate info, and it only realizes whether it can read that data or not after it tries at least once. It's a tough situation.

2.0 was not working flawlessly — it didn't spill errors to the log, but it displayed incorrect data. Unfortunately it seems we can't have it all. :-\