MacPorts has long had ports for llvm and clang which are very practical. Ports for lldb have been missing until now, so I've been trying to create one based on the existing clang port. That wasn't particularly difficult, except (who'd guess) for the codesigning bit.
Two questions:
- to what extent is it indeed (still) required to reboot after each attempt to (re)sign an executable? It doesn't appear to be the case for applications that just need to accept internet connections, for instance.
- does the debugserver application do anything which makes it a really bad idea to make it SETUID root?
And a bonus question: has it ever been tried to sign the debugserver file with the ad hoc identity ("-")? That identity works for accepting internet connections (= once signed like that applications no longer put up the deny/allow connection dialog each time they're started).
It listens on a tcp connection, and takes control of random applications.
debugserver is the ultimate remote code execution tool, and it does
not even try to hide it. I don't know whether it has any special
security safeguards on osx (there certainly aren't any on linux), but
I think having it installed that way is an open invitation to get
pwned.
security safeguards on osx (there certainly aren't any on linux), but
There's the codesigning bit. But that's just more a nuisance than a real protection, from what I can tell, at least against code you build and install yourself.
I think having it installed that way is an open invitation to get
pwned.
Looking at it that way, yes. That said, it looks like applications debugged as a regular user still run with that user's UID even if debugserver is running as root.
Don't forget that the debugger can attach to an already running
processes as well. without setuid, it could presumably attach only to
own processes, but if it's running as root...
Don't forget that the debugger can attach to an already running
processes as well. without setuid, it could presumably attach only to
own processes, but if it's running as root...
Good catch, you're right (on OS X, haven't tried on Linux yet).
Try a `killall -1 taskgated` before attempting a reboot. Wait a bit and then do `ps -axlww | fgrep taskgated`; if that doesn't show a running daemon you can always reboot after all, but if it does chances are the codesigning operation will work at once.
MacPorts has long had ports for llvm and clang which are very practical. Ports for lldb have been missing until now, so I've been trying to create one based on the existing clang port. That wasn't particularly difficult, except (who'd guess) for the codesigning bit.
Two questions:
- to what extent is it indeed (still) required to reboot after each attempt to (re)sign an executable? It doesn't appear to be the case for applications that just need to accept internet connections, for instance.
You don't have to reboot after every attempt to sign an executable. You only have to reboot after making the code signing identity and, doing the little command line trick to get the system to accept it. That still seems necessary, but then once you've done that you can keep using that identity either till it expires or you reinstall your OS.
- does the debugserver application do anything which makes it a really bad idea to make it SETUID root?
Apple goes to pretty great lengths to limit the harm a debugger can do as an attack vector. With SIP on, being root gives you many fewer permissions w.r.t. debugging than you might think, so I don't actually think this would help much. Suggesting people turn SIP off to use your debugger build seems like a bad idea to me.
And a bonus question: has it ever been tried to sign the debugserver file with the ad hoc identity ("-")? That identity works for accepting internet connections (= once signed like that applications no longer put up the deny/allow connection dialog each time they're started).
You don't have to reboot after every attempt to sign an executable. You only have to reboot after making the code signing identity and, doing the little command line trick to get the system to accept it. That still seems necessary, but then once you've done that you can keep using that identity either till it expires or you reinstall your OS.
Restarting the taskgated also seems to do that trick. If my understanding of the code signing doc is correct, the kernel doesn't cache new certificates until they're used for signing, or something of the sort, and if that's correct it doesn't seem required to reboot after creating a certificate.
Apple goes to pretty great lengths to limit the harm a debugger can do as an attack vector. With SIP on, being root gives you many fewer permissions w.r.t. debugging than you might think, so I don't actually think this would help much. Suggesting people turn SIP off to use your debugger build seems like a bad idea to me.
Yes, that wasn't my intention. I'm still running 10.9, so turning off SIP or not is somewhat of a nobrainer for me ^^
And a bonus question: has it ever been tried to sign the debugserver file with the ad hoc identity ("-")?
I doubt that would work.
It's a pity that there is so little information about what is and what isn't possible with ad-hoc signing.
Anyway, why does codesign or possibly even the Security framework underlying Keychain functionality use the HOME env. variable to determine a user's home directory instead of using one of the available APIs to get this information?