One unfortunate fact of my life is that I have to deal with an obscure database whose macOS drivers require the addition of a directory to
DYLD_LIBRARY_PATHfor their Python driver to find them. To make matters worse, Apple’s CLI tools strip that variable away as part of macOS’s System Integrity Protection (SIP) before running a command.Given that
DYLD_*environment variables are a known attack vector for Mac malware, that’s a good thing in general. However, sometimes one needs a workaround to get the job done.
Some of this made sense to me.
Regardless of whether apple is justified in deleting variables, I feel like apple should at least report an error message and have a mechanism to override it. After all, if they’re breaking legitimate code, then the user deserves to know. Also if they’ve genuinely blocked a malware loader, then the user also deserves to know so they can properly remove it. Silently stripping the user’s variables can cause users to spin their wheels for hours not realizing that apple is responsible for something not working.
Diagnosing what is and is not malware sounds very complicated and error prone process. Being consistent in stripping the variables sounds better.
Flatland_Spider,
I think you’ve misunderstood what I’m asking for. I didn’t mean to suggest they need to diagnose the malware, only to report the basic fact that they’re disobeying the requested command. This is reasonable regardless of what said command was intended to do whether it’s malware or not.
If I write a script that does X, but the environment does Y, then I strongly feel the user deserves to be alerted to the cause of this unexpected & buggy behavior. In the author’s case it was a broken build, but such bugs could have more dire consequences at a hospital or in a self driving car or whatever. I’m being a bit facetious, but what apple is doing is not good practice and silently altering user commands isn’t something that should be encouraged in general.
Generally the mistake people make with Apple devices is believing that they own the device they purchased and can make adult decisions about what they would like their device to accomplish. (Saying this as a frustrated m1 macbook owner that runs into random things that I have to play with stuff to get to work due to things like SIP…)
What have you run into?
I have an 2015 Macbook Pro, which will need to be replaced soon, and haven’t run into problems, minus the one which was the Ruby script which launches Emacsforosx Emacs binary needed perms when Catalina(?) first launched.
leech,
I absolutely agree with you when we’re talking about IOS, they’ve definitely gone on a power trip there. I know there’s fear of incremental restrictions on macos, but honestly I find it hard to gauge apple’s intentions since they’re not very transparent.
Personally I did experience trouble with SIP on macos and I was literally stuck until I could get help. I can chalk that up to my own unfamiliarity with the platform. Still, it makes me wonder how many normal users are experiencing trouble too. 3rd party software can be threatened by these barriers to owner control on their own machines, both with driverkit and normal applications.
https://developer.apple.com/forums/thread/79172
It’s one thing to do things in the name of security, but sometimes the gap between access mechanisms to protect owners versus access mechanism to control owners is uncomfortably thin. Have apple made any public commitments to macos owner control?
It seems like it’s a platform specific piece of knowledge. Like knowing the differences between BSD tools and GNU tools, or understanding the Windows network stack doesn’t work like the Linux network stack.
I fall on the side of it’s the scripts fault for not checking, and it should be some asserts at the start to make sure the environment is as expected.
Shell scripts are know to be horribly error prone since they will run through the commands regardless of errors. Getting the knowledge out about options to make bash scripts safer and fail faster is something people have been working on in the last few years.
I’m not sure if there are equivalent options in other shells, like sh/ash/dash, csh/tcsh, zsh, ksh/pdksh/oksh/mksh.
https://bash-prompt.net/guides/bash-set-options/
https://sipb.mit.edu/doc/safe-shell/
https://betterdev.blog/minimal-safe-bash-script-template/
https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html
Because my other reply is stuck in the mod queue…
It seems like it’s a platform specific piece of knowledge. Like knowing the differences between BSD tools and GNU tools, or understanding the Windows network stack doesn’t work like the Linux network stack.
I fall on the side of it’s the scripts fault for not checking, and it should have some error checking at the start to make sure the environment is as expected. The behavior is documented by Apple, and assumptions shouldn’t be made.
Plus, shell scripts are know to be horribly error prone since they will run through the commands regardless of errors. It’s another reason to use a full programming language.
Getting the knowledge out about options to make bash scripts safer and fail faster is something people have been working on in the last few years.
I’m not sure if there are equivalent options in other shells, like sh/ash/dash, csh/tcsh, zsh, ksh/pdksh/oksh/mksh.
sipb.mit.edu/doc/safe-shell/
bash-prompt.net/guides/bash-set-options/
betterdev.blog/minimal-safe-bash-script-template/
Flatland_Spider,
I don’t agree with this. Programmers should not be expected to second guess and babysit the OS on such fundamental operations like checking whether a variable will be equal to what we set it to. Think about how bloated and preposterous this would be. It’s simply not pragmatic or scalable.
Many developers like me don’t know when apple introduces bugs like this. I think what you are theoretically suggesting is this: “if platform=macos then do something different”. But this feels reminiscent of the hell which was programming javascript for IE. Not to make a mountain out of a molehill but we’ve moved beyond such bad practices on the web and IMHO apple’s approach here is bad.
Well, it affects more than just shells scripts. The author’s issue was with makefiles and I suspect high level languages like python are effected as well.
I’d reiterate the point that Carewolf made about malware already running on the machine. It IS useful to do this across a security boundary, such as switching users. However after searching cases of users experiencing these bugs it appears that apple is applying this restriction to applications running in the same security context. Security-wise it doesn’t make much sense.
I agree with you this is interesting. But what do you do when the shell itself is guilty of silently changing your commands and then not reporting it? Because that’s what apple is doing.
I hoped we could agree that at a minimum macos should print a warning so that users aren’t kept in the dark?
Ehmm. DYLD_LIBRARY_PATH is NOT an attack vector. Anything capably of setting that already has full control over your computer. At worst it is a way users can take control over software they own running on machines they own, against the interest of people that wants to own your computer (Apple).
Carewolf,
I was going to say something to this effect before truncating my comment. Obviously this changes resources used by the linker, but blocking the variable doesn’t solve the threat, malware having the ability to change the variable means you were already compromised.
It’s not often I have to change the library path, but sometimes it is necessary to run software with alternate resources and I wouldn’t appreciate apple blocking my instructions without a notification and an option to override the restriction. Of course this could go round in circles and someone might argue that malware could override the restriction too, however it comes back to your point that the system has already been compromised, this is treating the symptoms and not the cause.