Mac OS X kernel sandbox system policy errors are back #449

Open
47ronin opened this Issue Mar 15, 2016 · 24 comments

Projects

None yet
@47ronin
47ronin commented Mar 15, 2016

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
Owner

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

@47ronin
47ronin commented Mar 30, 2016

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

@hishamhm
Owner

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
Owner

@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
47ronin commented Mar 31, 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
@hishamhm
Owner
hishamhm commented Apr 1, 2016

@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
Contributor

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
Owner
hishamhm commented Apr 3, 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.)

@mklein-de
Contributor

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
axet commented Apr 27, 2016 edited

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
47ronin commented May 3, 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.

@tlhunter
tlhunter commented May 3, 2016

Just trying to help the googlers ;)

@hishamhm
Owner
hishamhm commented May 4, 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. :-\

@lfaoro
lfaoro commented May 15, 2016

press ignore sender in the Console and you're done with that message :)

@wagnerand

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.

@hishamhm
Owner

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.

@dreness
dreness commented Jul 11, 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] : Sandbox: htop(51550) System Policy: allow(0) mach-priv-task-port
--- last message repeated 329 times ---
kernel[0] : Sandbox: htop(51550) System Policy: allow(0) mach-priv-task-port
--- 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 7f9c82f), it's a little better:

kernel[0] : Sandbox: htop(624) System Policy: allow(0) mach-priv-task-port
--- last message repeated 245 times ---
kernel[0] : Sandbox: htop(624) System Policy: allow(0) mach-priv-task-port
--- 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

@alanhoyle

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.

@hishamhm
Owner

A new release is coming soon, with the improved behavior that's already in Git.

@alanhoyle

Thanks for releasing 2.0.2. Brew picked it up and the console logs are now no longer completely insane. Much appreciated!

@doc-crowston
doc-crowston commented Nov 29, 2016 edited

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.

@hishamhm
Owner
hishamhm commented Dec 7, 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment