Let me show myself being an old man yelling at clouds, but this looks like way too much complexity including a totally unintended change to what binaries run for a service that accomplishes the same thing a VPN would do which also is very bad practice from my viewpoint wearing the security hat - direct transparent access to remote machines which could very easily be confused with local development machines.
Also, I’m pretty sure this hack is going to stop working soon as Apple is showing signs to prevent copies of SIP protected binaries from outside of SIP protected locations.
And here’s my final old-man advice: if your product introduces an abstraction by hackily bypassing OS security features, then you are doing something wrong and you might need to reconsider your product from the ground up.
Also, I’m pretty sure this hack is going to stop working soon as Apple is showing signs to prevent copies of SIP protected binaries from outside of SIP protected locations.
Aside from this being effectively impossible, there’s no real reason to do this. SIP is just a layered mechanism that is intended to prevent the system install being compromised by wholesale replacement of system files, especially for data files where there’s no code signature enforcement mechanism. The real hack, and the core issue of the rest of this article, is bypassing that all system binaries are configured to used the “hardened runtime” which disallows LD_PRELOAD-type injections, and these can’t be removed without violating code signature enforcement.
The thing is that those “system binaries” are usually used as a workaround, for example in most cases it’s an interpreter script running #!/usr/bin/env which entitlements really do not matter (when running pyenv,npm etc)
We could replace those binaries with a nix like solution but this is fairly simple to just use what’s available locally, stripped out of the high privilege entitlements.
This prevents the copying of protected binaries for execution outside SIP protected areas while keeping entitlements intact. But the approach in the OP already doesn’t care about keeping entitlements intact because it needs to remove the hardened runtime requirements.
There’s no way to prevent stripping entitlements and stubsigning, and then executing that code, because you can just arbitrarily remove those restrictions from the file once copied. This is about protecting the trusted system copies of binaries with privileged capabilities so that their address space is locked down.
Let me show myself being a young rebel, who thinks we can do better and not let existing messy ecosystem impact our lives.
Accomplishes the same thing a VPN would do
Not really.
I urge you to try out the alternatives, then try out ours and see for yourself that the experience is 100x better. People have a magical moment when they use ours since it doesn’t install root daemon (to use VPN), it doesn’t alter their system configurations (to run VPN), it lets them have the effect only on process level, and not for the whole system, and this way you can run many services at the same time, having different context for each.
And here’s my final old-man advice: if your product introduces an abstraction by hackily bypassing OS security features, then you are doing something wrong and you might need to reconsider your product from the ground up.
I would have agreed if such mechanism downgrades or impacts the machine’s security, but this is even less intrusive and more secure than most VPN solutions that require root permissions, so besides security mechanism being involved, we don’t actually do the thing they don’t want us to do (leverage entitlements of existing binaries).
Not everything that can be done should be done
That’s a true statement, but if the alternatives aren’t as good (VPN, VM, Docker) then we should make better ones.
Messing with OS vendor binaries and transparently running them in an emulated different architecture is not what I would call less intrusive.
MacOS comes with a built-in VPN client which works without any additional install. That’s the minimum of intrusiveness.
That said, while this product is not interesting to me, I’m sure you will find customers for your solution and I wish you the best of luck for the future in light of Apple locking things down (and eventually removing Rosetta - like they have in the past and very quickly)
Oh. And thinking about this: have you tried an approach where you are a local-only VPN or a network extension to do the same thing? That would rely on OS vendor sanctioned API which is much more likely to stay useable into the future.
MacOS comes with a built-in VPN client which works without any additional install. That’s the minimum of intrusiveness.
The VPN is one part, what about file system access? That’d require mounts ;) - and still, you’d run into the other problems I mentioned.
That said, while this product is not interesting to me, I’m sure you will find customers for your solution and I wish you the best of luck for the future in light of Apple locking things down (and eventually removing Rosetta - like they have in the past and very quickly)
Highly appreciate it! Also appreciate the feedback, sorry if I came out defensive - that’s what happens when you comment at 6 am as your first thing in the morning. I like hearing contrary thoughts and staying in my echo chamber isn’t as productive.
and eventually removing Rosetta - like they have in the past and very quickly
I believe that once they’re ready to remove Rosetta, they will also make arm64e ABI stable, thus letting us run non-emulated :)
Oh. And thinking about this: have you tried an approach where you are a local-only VPN or a network extension to do the same thing? That would rely on OS vendor sanctioned API which is much more likely to stay useable into the future.
I am well aware of those approaches, even implemented some of those APIs in the past (not my first rodeo going low level with Apple..) Network Extensions are very limited and require high permissions. One of the killer features in our solution is that you can just install it from VS Code marketplace.
I am not afraid of Apple shutting down stuff, because in the end, as @ceph mentioned - running arbitrary binaries is a basic feature for the operating system, and that’s not what Apple is trying to avoid.
Let me show myself being an old man yelling at clouds, but this looks like way too much complexity including a totally unintended change to what binaries run for a service that accomplishes the same thing a VPN would do which also is very bad practice from my viewpoint wearing the security hat - direct transparent access to remote machines which could very easily be confused with local development machines.
Also, I’m pretty sure this hack is going to stop working soon as Apple is showing signs to prevent copies of SIP protected binaries from outside of SIP protected locations.
And here’s my final old-man advice: if your product introduces an abstraction by hackily bypassing OS security features, then you are doing something wrong and you might need to reconsider your product from the ground up.
Not everything that can be done should be done.
Aside from this being effectively impossible, there’s no real reason to do this. SIP is just a layered mechanism that is intended to prevent the system install being compromised by wholesale replacement of system files, especially for data files where there’s no code signature enforcement mechanism. The real hack, and the core issue of the rest of this article, is bypassing that all system binaries are configured to used the “hardened runtime” which disallows
LD_PRELOAD-type injections, and these can’t be removed without violating code signature enforcement.The thing is that those “system binaries” are usually used as a workaround, for example in most cases it’s an interpreter script running
#!/usr/bin/envwhich entitlements really do not matter (when running pyenv,npm etc) We could replace those binaries with a nix like solution but this is fairly simple to just use what’s available locally, stripped out of the high privilege entitlements.Apparently it is possible at least to some extent https://theevilbit.github.io/posts/amfi_launch_constraints/
ATM it’s to protect binaries with privileged entitlements from being coerced into doing things they were not intended for
This prevents the copying of protected binaries for execution outside SIP protected areas while keeping entitlements intact. But the approach in the OP already doesn’t care about keeping entitlements intact because it needs to remove the hardened runtime requirements.
There’s no way to prevent stripping entitlements and stubsigning, and then executing that code, because you can just arbitrarily remove those restrictions from the file once copied. This is about protecting the trusted system copies of binaries with privileged capabilities so that their address space is locked down.
Let me show myself being a young rebel, who thinks we can do better and not let existing messy ecosystem impact our lives.
Not really. I urge you to try out the alternatives, then try out ours and see for yourself that the experience is 100x better. People have a magical moment when they use ours since it doesn’t install root daemon (to use VPN), it doesn’t alter their system configurations (to run VPN), it lets them have the effect only on process level, and not for the whole system, and this way you can run many services at the same time, having different context for each.
I would have agreed if such mechanism downgrades or impacts the machine’s security, but this is even less intrusive and more secure than most VPN solutions that require root permissions, so besides security mechanism being involved, we don’t actually do the thing they don’t want us to do (leverage entitlements of existing binaries).
That’s a true statement, but if the alternatives aren’t as good (VPN, VM, Docker) then we should make better ones.
Messing with OS vendor binaries and transparently running them in an emulated different architecture is not what I would call less intrusive.
MacOS comes with a built-in VPN client which works without any additional install. That’s the minimum of intrusiveness.
That said, while this product is not interesting to me, I’m sure you will find customers for your solution and I wish you the best of luck for the future in light of Apple locking things down (and eventually removing Rosetta - like they have in the past and very quickly)
Oh. And thinking about this: have you tried an approach where you are a local-only VPN or a network extension to do the same thing? That would rely on OS vendor sanctioned API which is much more likely to stay useable into the future.
The VPN is one part, what about file system access? That’d require mounts ;) - and still, you’d run into the other problems I mentioned.
Highly appreciate it! Also appreciate the feedback, sorry if I came out defensive - that’s what happens when you comment at 6 am as your first thing in the morning. I like hearing contrary thoughts and staying in my echo chamber isn’t as productive.
I believe that once they’re ready to remove Rosetta, they will also make arm64e ABI stable, thus letting us run non-emulated :)
I am well aware of those approaches, even implemented some of those APIs in the past (not my first rodeo going low level with Apple..) Network Extensions are very limited and require high permissions. One of the killer features in our solution is that you can just install it from VS Code marketplace. I am not afraid of Apple shutting down stuff, because in the end, as @ceph mentioned - running arbitrary binaries is a basic feature for the operating system, and that’s not what Apple is trying to avoid.