lldb ...

[Rainer Müller]

On 2016-09-10 17:52, Jeremy Huddleston Sequoia wrote:
>> On OS X 10.10 Yosemite, signing only the ggdb binary was certainly 
>> enough. I cannot reproduce this on macOS 10.12 Sierra, so the
>> requirements might have changed.
> 
> 10.10 predates SIP and related hardening around ptrace().  That
> version is so far in my rearview that I forget the details there,
> sorry.  I'll have to dig into it, but it certainly seems wrong to me
> that a process could become privileged if it linked against unsigned
> libraries.

I would assume if we find a solution that passes the current
restrictions on Sierra that will also work for older releases with less
strict checking.

I got gdb to work now on Sierra now. In fact I did not even have to sign
any of the libraries it links to.


$ otool -L /opt/local/bin/ggdb |awk 'NR>1 {print $1}' \
    |grep '^/opt/local' | xargs -I{} codesign -d -v {}
/opt/local/lib/libintl.8.dylib: code object is not signed at all
/opt/local/lib/libncurses.6.dylib: code object is not signed at all
/opt/local/lib/libz.1.dylib: code object is not signed at all
/opt/local/lib/libiconv.2.dylib: code object is not signed at all
/opt/local/lib/libexpat.1.dylib: code object is not signed at all

$ /opt/local/bin/ggdb -q /opt/local/bin/curl
Reading symbols from /opt/local/bin/curl...(no debugging symbols
found)...done.
(gdb) r
Starting program: /opt/local/bin/curl
warning: unhandled dyld version (15)
curl: try 'curl --help' or 'curl --manual' for more information
[Inferior 1 (process 6964) exited with code 02]
(gdb) q


The main problem I encountered was that the setgid for the procmod group
seems to interfere with the validation now. Once I removed that by
changing the permissions to a regular 0755, I can use the code-signed
ggdb just fine to debug other programs.

By the way, as I did lots of trial and error, is there a way to get
debug output (from taskgated?) to see why task_for_pid() was denied?

Rainer