Htop: Mac OS X kernel sandbox system policy errors are back
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 :cry:
htop --version
htop 2.0.1 - (C) 2004-2016 Hisham Muhammad
Released under the GNU GPL.
47ronin
All 25 comments
@mklein-de Do you have any idea? I thought the seteuid tweaks took care of this, but I may be misunderstanding it.
hishamhm
on 24 Mar 2016
With htop installed from Homebrew, reverting back to 2.0.0 eliminates the errors.
47ronin
on 30 Mar 2016
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
on 31 Mar 2016
@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.
hishamhm
on 31 Mar 2016
@hishamhm It does not, sorry.
MikeMcQuaid
on 31 Mar 2016
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
@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)
hishamhm
on 1 Apr 2016
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 ---
mklein-de
on 1 Apr 2016
@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.)
hishamhm
on 3 Apr 2016
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.
mklein-de
on 11 Apr 2016
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)
axet
on 27 Apr 2016
Duplicate of #330, which is the first thing that comes up in a google search.
tlhunter
on 27 Apr 2016
@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.
47ronin
on 3 May 2016
Just trying to help the googlers ;)
tlhunter
on 3 May 2016
@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. :-\
hishamhm
on 4 May 2016
press ignore sender in the Console and you're done with that message :)
lfaoro
on 16 May 2016
Would it be possible to not try again after it realized that it cannot read the data instead of trying over and over again?
press ignore sender in the Console and you're done with that message :)
A pretty difficult advise, considering you are going to ignore _all_ kernel messages with that.
wagnerand
on 23 May 2016
Would it be possible to not try again after it realized that it cannot read the data instead of trying over and over again?
@wagnerand This is what htop is doing now in current Git. Though it tries at least once for each new process that comes up, because it doesn't know in advance if it will have permissions for that process or not.
hishamhm
on 24 May 2016
@hishamhm Indeed it's much better with this change, thanks! There are still some log messages at htop startup, and when new PIDs appear, but not continuously.
As a side note, _with rootless disabled_ ('csrutil status' says 'disabled'), task_for_pid access isn't restricted, _BUT_ the system will log EVERY SINGLE CALL anyway. Prior to updating htop to trunk (using the 2.0.1 build in Homebrew), running htop (with -d 5) as root resulted in:
kernel[0]
--- last message repeated 329 times ---
kernel[0]
--- last message repeated 329 times ---
... continuously. In that state on an otherwise idle system, syslogd is the busiest process on the system. In trunk (I'm on 7f9c82f28d8d1da1fa7ca8c2f5534ed0c41852ef), it's a little better:
kernel[0]
--- last message repeated 245 times ---
kernel[0]
--- last message repeated 122 times ---
I wrote some quick ASL rules that reduce syslogd CPU usage by about 50%, and eliminate the 'allowed mac-priv-task-port' log spam entirely.
# /etc/asl.conf rules, placed above 'Rules for /var/log/system.log'
? [= Sender kernel] [= Facility kern] [N= Level 5] [Z= Message allow(0) mach-priv-task-port] ignore
? [= Sender sandboxd] [= Facility com.apple.sandbox] [N= Level 5] [Z= Message allow mach-priv-task-port] ignore
Activate with: sudo pkill -HUP syslogd
dreness
on 11 Jul 2016
IMO, this should be a prioritized thing to fix. Since the OSX/macOS's top is awful, I had been using htop when I saw my CPU load going up unexplained. With htop making the syslogd go crazy too, it makes life worse to try to see what's wrong. For the moment, I'm back to using Activity Monitor. I don't know for sure, but in my gut I feel like a command-line app should be lighter-weight than a GUI one.
alanhoyle
on 20 Jul 2016
A new release is coming soon, with the improved behavior that's already in Git.
hishamhm
on 21 Jul 2016
Thanks for releasing 2.0.2. Brew picked it up and the console logs are now no longer completely insane. Much appreciated!
alanhoyle
on 23 Jul 2016
A partial solution is to sign the htop binary with a certificate present in the System keychain. The certificate can be self-signed. See https://sourceware.org/gdb/wiki/BuildingOnDarwin#Method_for_Mac_OS_X_10.5_.28Leopard.29_and_later for how this works with gdb. A subtlety is that the certificate must be in the System keychain, not the login keychain. However I have found that even so, htop will be denied permission to inspect many processes.
doc-crowston
on 29 Nov 2016
@doc-crowston Interesting! — which processes are you able to inspect with this option and which one you are not? Could you send a screenshot?
hishamhm
on 7 Dec 2016
For anyone running htop as root, you might need to move the rules @dreness gave us above to sit above
# save kernel [PID 0] and launchd [PID 1] messages
? [<= PID 1] store
genevera
on 13 Aug 2017
Related issues
kcgthb
·
8Comments
marcelpaulo
·
3Comments
brendangregg
·
8Comments
edouard-lopez
·
5Comments
RalfJung
·
4Comments
Most helpful comment
@hishamhm Indeed it's much better with this change, thanks! There are still some log messages at htop startup, and when new PIDs appear, but not continuously.
As a side note, _with rootless disabled_ ('csrutil status' says 'disabled'), task_for_pid access isn't restricted, _BUT_ the system will log EVERY SINGLE CALL anyway. Prior to updating htop to trunk (using the 2.0.1 build in Homebrew), running htop (with -d 5) as root resulted in:
kernel[0]: Sandbox: htop(51550) System Policy: allow(0) mach-priv-task-port: Sandbox: htop(51550) System Policy: allow(0) mach-priv-task-port
--- last message repeated 329 times ---
kernel[0]
--- last message repeated 329 times ---
... continuously. In that state on an otherwise idle system, syslogd is the busiest process on the system. In trunk (I'm on 7f9c82f28d8d1da1fa7ca8c2f5534ed0c41852ef), it's a little better:
kernel[0]: Sandbox: htop(624) System Policy: allow(0) mach-priv-task-port: Sandbox: htop(624) System Policy: allow(0) mach-priv-task-port
--- last message repeated 245 times ---
kernel[0]
--- last message repeated 122 times ---
I wrote some quick ASL rules that reduce syslogd CPU usage by about 50%, and eliminate the 'allowed mac-priv-task-port' log spam entirely.
Activate with:
sudo pkill -HUP syslogd