7 ms·

Adding network calls to syscalls like exec() is utterly insane. This road can lead to bricked laptops where you can't run anything to fix it (imagine an unexpec

Adding network calls to syscalls like exec() is utterly insane. This road can lead to bricked laptops where you can't run anything to fix it (imagine an unexpected network error that the code doesn't handle properly). And crackers will just use ways to overwrite running instruction text to avoid the exec(). The comments on the article are annoying: it good that there's a mini way to reproduce, but please, use some further debugging like tcpdump (it still exists on osx, right?). Last time I summarized osx debugging was https://www.slideshare.net/brendangregg/analyzing-os-x-systems-performance-with-the-use-method/38 https://www.slideshare.net/brendangregg/analyzing-os-x-syste... I'd also stress test it: generate scripts in a loop that include random numbers and execute them.

xvector 6y ago
There is no excuse for this except for sheer, utter incompetence. Everyone involved in writing and shipping this should be ashamed of themselves.
- will_pseudonym 6y ago
  Hey, malevolence can also play into this. Don't chalk everything up automatically to incompetence. /s
- drvdevd 6y ago
  This is what I scrolled all the way down this thread for - to see if anyone thinks this is a good design/security decision on Apples part. I’m trying to understand what the reasoning is for this particular decision and if it actually makes the OS more secure in any meaningful way? Or does it actually- just degrade performance with very limited benefits? Are there any real benefits to this VS current security design in popular Desktop Linux distros at this point?
  - HappyDreamer 6y ago
    Couldn't this have been a business decision? Not about security? (just what they say?) To make non-App-store apps annoyingly unusable, so the App store will sell more apps, instead of people downloading in other ways? Just like Apple cripples the Safari browser and PWA apps. Long term, maybe Apple wants to be able to remote-forbid apps if Apple is developing their own competing app? Whilst most developers working at Apple understands this, and don't like it? Maybe the developers even feel happy about people here at HN being disappointed, and think that "now the business people here at Apple notice that this causes disappointment" ?
    - saagarjha 6y ago
      I don't think the people at Apple are actively trying to make non-App Store apps unusable because they want to make more money from the App Store or anything. It's just that they want code to pass through them, and as a by product making code that has been vetted less or does things that could potentially be abused is made more annoying to run. Such a change is divisive, as you may have guessed.
      - michaelmrose 6y ago
        That vetting will come at the cost of 30% of money paid for your software and any money earned within the software.
        deleted 6y ago
        [deleted]
    - fluffything 6y ago
      Most of the apps that sell well originate from a developer solving a need they had, on the system they were using. If this drives developers from OSX to other OSes, chances are they will develop apps for those OSes first. Apple is too big to fail at this point, but driving developers away from your platform isn't a very clever strategy. You never know when you are going to hit a tipping point, and after you notice and people stop using macosx for development its already too late. It took me ~150 hours to migrate to Linux, but my user and developer experience on Linux is much better than on MacOSX (emacs daemon "just works"!!!), so after all that work I wouldn't consider switching to OSX in the next 5 years at least. I had a Macbook air 2012, and because Apple still hasn't released a laptop that isn't a downgrade from that in some sense (keyboard, magsafe, ...) I've went with a think pad instead. Tiny details, like having a webcam that doesn't suck now prevent me from going back to OSX.
  - saagarjha 6y ago
    It checks that executables have been notarized by Apple? I can't say I really think notarization is great, but I think it's clear from their perspective how it would be beneficial?
    - drvdevd 6y ago
      Sure. But as Brendan Gregg pointed out in his comment - doing this at the level of exec() on a UNIX-like OS is ... a questionable technical choice to say the least. What’s the Linux equivalent of “notarization”? I’m not sure. Of course there’s probably more than one answer to that - let’s just taking signing packages as an example. In theory Apple could put their weight behind vetting some of the popular open source packages perhaps? Or delegate that to the maintainers of those repositories and make them trusted? Like homebrew, for example (maybe a poor example, but you see how I’m trying to compare this with Linux...) This is after all, what actually makes macOS useful to people on the command line 99% of the time, anyway. So anyway, I agree on the surface it seems like this might be beneficial to Apple, but it doesn’t appear to be well considered. They could invest more time in better sandbox and/or container type features that let people define some of their own more granular security boundaries. But they aren’t I guess? What are they doing here?
      - john_alan 6y ago
        Watching the notarization video from WWDC last year they explicitly said it wouldn’t affect command line apps.
        saagarjha 6y ago
        I believe that some of the problems here have actually started affecting command line apps in Catalina.
        john_alan 6y ago
        Only if you don't specify your terminal as a dev tool
- pmarreck 6y ago
  There’s going to be a big exodus of open source developers going to Linux-powered platforms instead of the standard Mac laptop because of this ridiculousness
  - cageface 6y ago
    This is happening at my company already because docker performance on Macs is terrible.
    - millstone 6y ago
      On the one hand, of course it is, because Macs are slow at running Linux stuff in the same way that Linux is slow at running non-Linux stuff. On the other hand, Apple should decide if they care about Docker performance. The answer seems to be "a little" (Hypervisor.framework) but much less than, say, Microsoft. Apple doesn't talk about their future plans. Today we see stagnation, YET with spikes of exotic ideas (e.g. L4, which would permit efficient L4 Linux). Per Apple's style, a big kernel change on the Mac side would absolutely be tied to a hardware change, to break things once and not twice. Build a new Mac with a Linux-friendly kernel (perhaps Linux, perhaps modified L4, or something new), put it on their beastly ARM CPUs, and I'm drooling. Then again I don't work at Apple.
    - pmarreck 6y ago
      Is that slowness possibly related to the OP's issue? And possibly might benefit from the same workarounds posted here?
  - jfkebwjsbx 6y ago
    > the standard Mac laptop There is nothing standard about a Mac laptop, both technically and in market share.
    - saagarjha 6y ago
      At Silicon Valley technology companies? A Mac is generally the computer that you're likely to get.
saagarjha 6y ago
> And crackers will just use ways to overwrite running instruction text to avoid the exec(). This would require breaking your code signature and as such requires extra entitlements in the hardened runtime.
ridiculous_fish 6y ago
The kernel sources are available. https://opensource.apple.com/source/xnu/xnu-6153.81.5/ https://opensource.apple.com/source/xnu/xnu-6153.81.5/
- saagarjha 6y ago
  …with everything to do with the sandbox left out.
  - ridiculous_fish 6y ago
    Fair point. These tarballs may be, err, editorialized. If exec is blocking in the kernel on IPC to some daemon, that should be observable (e.g. Instruments with kernel traces enabled).
    - saagarjha 6y ago
      Yeah, I'm sure a good spindump would be able to find what the code is blocked on. Sadly I run with SIP disabled so I can attach to things, so I probably cannot reproduce the issue…
- m463 6y ago
  Most of the important parts are left out. at this point opensource and apple are sort of on life support.
millstone 6y ago
Well NFS and SMB exist, you can exec() on such mounts.
xenadu02 6y ago
That's not quite correct. If network access is unavailable or fails then the exec is allowed. The behavior has been improved over time, putting stricter limits on how long the check is allowed to take before giving up. The Mac remains a Mac: if you turn off SIP it also disables this behavior. You are free to choose less security for more convenience if that is your preference.

xvector 6y ago

There is no excuse for this except for sheer, utter incompetence. Everyone involved in writing and shipping this should be ashamed of themselves.

will_pseudonym 6y ago
Hey, malevolence can also play into this. Don't chalk everything up automatically to incompetence. /s
drvdevd 6y ago
This is what I scrolled all the way down this thread for - to see if anyone thinks this is a good design/security decision on Apples part. I’m trying to understand what the reasoning is for this particular decision and if it actually makes the OS more secure in any meaningful way? Or does it actually- just degrade performance with very limited benefits? Are there any real benefits to this VS current security design in popular Desktop Linux distros at this point?
- HappyDreamer 6y ago
  Couldn't this have been a business decision? Not about security? (just what they say?) To make non-App-store apps annoyingly unusable, so the App store will sell more apps, instead of people downloading in other ways? Just like Apple cripples the Safari browser and PWA apps. Long term, maybe Apple wants to be able to remote-forbid apps if Apple is developing their own competing app? Whilst most developers working at Apple understands this, and don't like it? Maybe the developers even feel happy about people here at HN being disappointed, and think that "now the business people here at Apple notice that this causes disappointment" ?
  - saagarjha 6y ago
    I don't think the people at Apple are actively trying to make non-App Store apps unusable because they want to make more money from the App Store or anything. It's just that they want code to pass through them, and as a by product making code that has been vetted less or does things that could potentially be abused is made more annoying to run. Such a change is divisive, as you may have guessed.
    - michaelmrose 6y ago
      That vetting will come at the cost of 30% of money paid for your software and any money earned within the software.
      - deleted 6y ago
        [deleted]
  - fluffything 6y ago
    Most of the apps that sell well originate from a developer solving a need they had, on the system they were using. If this drives developers from OSX to other OSes, chances are they will develop apps for those OSes first. Apple is too big to fail at this point, but driving developers away from your platform isn't a very clever strategy. You never know when you are going to hit a tipping point, and after you notice and people stop using macosx for development its already too late. It took me ~150 hours to migrate to Linux, but my user and developer experience on Linux is much better than on MacOSX (emacs daemon "just works"!!!), so after all that work I wouldn't consider switching to OSX in the next 5 years at least. I had a Macbook air 2012, and because Apple still hasn't released a laptop that isn't a downgrade from that in some sense (keyboard, magsafe, ...) I've went with a think pad instead. Tiny details, like having a webcam that doesn't suck now prevent me from going back to OSX.
- saagarjha 6y ago
  It checks that executables have been notarized by Apple? I can't say I really think notarization is great, but I think it's clear from their perspective how it would be beneficial?
  - drvdevd 6y ago
    Sure. But as Brendan Gregg pointed out in his comment - doing this at the level of exec() on a UNIX-like OS is ... a questionable technical choice to say the least. What’s the Linux equivalent of “notarization”? I’m not sure. Of course there’s probably more than one answer to that - let’s just taking signing packages as an example. In theory Apple could put their weight behind vetting some of the popular open source packages perhaps? Or delegate that to the maintainers of those repositories and make them trusted? Like homebrew, for example (maybe a poor example, but you see how I’m trying to compare this with Linux...) This is after all, what actually makes macOS useful to people on the command line 99% of the time, anyway. So anyway, I agree on the surface it seems like this might be beneficial to Apple, but it doesn’t appear to be well considered. They could invest more time in better sandbox and/or container type features that let people define some of their own more granular security boundaries. But they aren’t I guess? What are they doing here?
    - john_alan 6y ago
      Watching the notarization video from WWDC last year they explicitly said it wouldn’t affect command line apps.
      - saagarjha 6y ago
        I believe that some of the problems here have actually started affecting command line apps in Catalina.
        john_alan 6y ago
        Only if you don't specify your terminal as a dev tool
pmarreck 6y ago
There’s going to be a big exodus of open source developers going to Linux-powered platforms instead of the standard Mac laptop because of this ridiculousness
- cageface 6y ago
  This is happening at my company already because docker performance on Macs is terrible.
  - millstone 6y ago
    On the one hand, of course it is, because Macs are slow at running Linux stuff in the same way that Linux is slow at running non-Linux stuff. On the other hand, Apple should decide if they care about Docker performance. The answer seems to be "a little" (Hypervisor.framework) but much less than, say, Microsoft. Apple doesn't talk about their future plans. Today we see stagnation, YET with spikes of exotic ideas (e.g. L4, which would permit efficient L4 Linux). Per Apple's style, a big kernel change on the Mac side would absolutely be tied to a hardware change, to break things once and not twice. Build a new Mac with a Linux-friendly kernel (perhaps Linux, perhaps modified L4, or something new), put it on their beastly ARM CPUs, and I'm drooling. Then again I don't work at Apple.
  - pmarreck 6y ago
    Is that slowness possibly related to the OP's issue? And possibly might benefit from the same workarounds posted here?
- jfkebwjsbx 6y ago
  > the standard Mac laptop There is nothing standard about a Mac laptop, both technically and in market share.
  - saagarjha 6y ago
    At Silicon Valley technology companies? A Mac is generally the computer that you're likely to get.

saagarjha 6y ago

> And crackers will just use ways to overwrite running instruction text to avoid the exec(). This would require breaking your code signature and as such requires extra entitlements in the hardened runtime.

ridiculous_fish 6y ago

The kernel sources are available. https://opensource.apple.com/source/xnu/xnu-6153.81.5/ https://opensource.apple.com/source/xnu/xnu-6153.81.5/

saagarjha 6y ago
…with everything to do with the sandbox left out.
- ridiculous_fish 6y ago
  Fair point. These tarballs may be, err, editorialized. If exec is blocking in the kernel on IPC to some daemon, that should be observable (e.g. Instruments with kernel traces enabled).
  - saagarjha 6y ago
    Yeah, I'm sure a good spindump would be able to find what the code is blocked on. Sadly I run with SIP disabled so I can attach to things, so I probably cannot reproduce the issue…
m463 6y ago
Most of the important parts are left out. at this point opensource and apple are sort of on life support.

millstone 6y ago

Well NFS and SMB exist, you can exec() on such mounts.

xenadu02 6y ago

That's not quite correct. If network access is unavailable or fails then the exec is allowed. The behavior has been improved over time, putting stricter limits on how long the check is allowed to take before giving up. The Mac remains a Mac: if you turn off SIP it also disables this behavior. You are free to choose less security for more convenience if that is your preference.