top | item 34514656

Fun with macOS's Sip

88 points| signa11 | 3 years ago |metalbear.co

42 comments

order
[+] cobbal|3 years ago|reply
There are few miseries I deal with regularly that compare to SIP or the hardened runtime telling me I may not debug processes on a computer where I have root. If anything is going to make me abandon macOS (I've been using it since I was a child) it's the "security and privacy" features.
[+] sbuk|3 years ago|reply
The security and privacy features benefit the majority, of which you clearly are not, so there is an escape hatch for you; turn off SIP. Just don't disable it for typical users.
[+] lloeki|3 years ago|reply
Under "Security and Privacy" there's been "Developer Tools" for a while, within which I only ever saw Terminal.app (but any app could be added)

I'm not sure what it really does (could not find any docs, maybe someone can enlighten?) but the text made me think it could allow stuff like running unsigned debuggers:

    Allow the applications below to run software locally that does not meet the system's security policies
Again I'm really not sure, but maybe it can cover some use cases without going the nuclear route of fully disabling SIP?
[+] aviramha|3 years ago|reply
I totally feel you though I can understand that for Apple the average consumer's security > hackers :) I think Apple should remember that people debugging and working is important too, and make the documentation around the security features less obscure. (Attaching a debugger/ptrace on macOS is really evil to implement)
[+] madeofpalk|3 years ago|reply
You can just disable SIP, no?
[+] pseufaux|3 years ago|reply
> Killed! And it was so young.

This got far more of a chuckle from me than it should have. Must have had a long day or far to little sleep.

[+] WirelessGigabit|3 years ago|reply
While the explanation is super cool it makes me feel nervous. None of this did supported. APIs change without notice, as you don't have a contract. You're relying on the fact that there is an x64 version available.
[+] aviramha|3 years ago|reply
Most odds is when x64 binary will stop shipping, arm64e won't be in preview mode anymore and we will be able to just do the re-signing part. (Which is supported)
[+] ghostpepper|3 years ago|reply
It's pretty much expected that if you publish a method for working around a security feature it will be patched quickly. Cool research if that was the intention but if you're building a product around this... you're going to have a bad time.
[+] antihero|3 years ago|reply
This is interesting. I’m guessing just having a patched shell binary and forking stuff from within that wouldn’t work.
[+] aviramha|3 years ago|reply
You could patch a shell binary, but you'd ultimately want to use other binaries as well. The most common example we had is when people tried to run our software with `pyenv` which was a shell script that used other system binaries + shell scripts
[+] david2ndaccount|3 years ago|reply
This is a strange product they’re selling. You run your binary on on macOS but presumably your server is running linux. Why are you trying to run Darwin executables as if they were in the cloud when that is not what will actually be deployed? Shouldn’t the testing at least be done from a linux machine?
[+] eyalbukchin|3 years ago|reply
Ideally! And it can be run on a Linux machine if the user prefers. But if you code on a Mac, mirrord still lets you go through a good number of test iterations (by letting your process run with network input/output, file content and environment variables from the cloud) before having to deploy your code to a Linux machine for that (hopefully) final round of testing.
[+] pedrow|3 years ago|reply
Would it be an option to compile your own versions of `ls` et al., maybe from the Darwin source (if available, I don't know) or one of the BSDs? Does what you're trying to do depend on the specific implementation of Apple's utilities?
[+] eyalbukchin|3 years ago|reply
Maybe, we haven't looked into that option for the following reasons:

a. It would require that we maintain a potentially pretty big list of self-compiled binaries

b. It would be an alteration of what the user's running, which we try to keep to a minimum, as mirrord's commonly used as a testing tool

[+] jbverschoor|3 years ago|reply
I have no clue what this mirrord does. Is it some kind of API proxy? What if I don't have 'pods', also, shouldn't it be called redirect_api? mirror sounds like it's mirrorring.

Why would I need this? or whatever this does?

[+] aviramha|3 years ago|reply
mirrord is a tool for backend engineers that enables them to work on a remote environment without needing to deploy there or actually run there. It makes the iteration time (code -> test -> [review] -> deploy) faster since you don't replace the remote service also, which means many devs can work the same time.

You can read more about it here https://metalbear.co/blog/mirrord-3.0-is-out/