Comment by mcv
1 month ago
Good point. The current security model of desktop OSs sucks. I was recently reminded of this by an issue at work. I'm used to devs having admin rights on their laptops, but here they closed that down: you have to request admin rights for a specific purpose, and then you get them for a week.
I recently requested those rights again because I needed to install something new for a PoC I was working on, and that wasn't allowed anymore. But during onboarding I had those rights and installed homebrew to more easily install dev tools, and homebrew keeps its admin rights to install stuff in a directory owned by admin. So that circumvents this whole security model (and I did, for my PoC).
The problem is that it's all or nothing. Homebrew should have the right only to install in a specific directory. Apps shouldn't automatically get access to potentially sensitive data. Mobile OSs handle that sort of thing more granularly. Desktop OSs should too.
Because the overly restrictive security rules at my work are little more than security theatre when it's so easy to circumvent.
There is software that does exactly that. You install a software kiosk were users can pick from and users don't get admin rights.
Won't satisfy developers for long though because it cannot work.
The problem is that mobile OS security systems isn't fit to develop anything but shit. It is simply no solution for desktop.
Well, one issue with the app store solution at my workplace is that you can still download anything, even if you can't install it. And executables can still be executed even from your downloads folder. Or your personal bin folder. So preventing people from executing unknown apps is not going to work that way.
But then again, we write and execute our own code, so of course we have to be able to execute unknown code.
The whole thing feels like an exercise in futility to me. It would make more sense to specify what rights a specific application should have. Let me approve the external urls it wants to visit, the folders it wants to access, etc. Shield everything else off.
It's not theater, your IT department just isn't implementing it correctly. I recently switched jobs and gave up one macbook pro for another (work issued).
Company A gave me sudo access and I could do anything I wanted.
Company B locks down everything, no sudo, no brew, nothing. But I do get a big VM with root to do anything I want. There is an approved "appstore" of many different varieties of IDEs/tools.
TLDR: Not having brew is not a problem, and /can be/ a better experience if done right.
It took a couple weeks to shift the mental model but I have no problems. The dev experience is quite good because they provide all the libraries you need to do your job.
Interesting. If you don't mind, I have a few questions:
1. Is the "big VM with root" running macOS itself, or a different OS?
2. Do you do any work on the bare metal version of macOS, or do you just start the VM in the morning and do everything from there?
3. How do you experience the performance/UX of the VM?
4. Do you know why Company B IT has set up this VM solution, instead of a plain old MacBook locked down with Apple's enterprise management tools?
5. Can you explain more about the App Store? Is it the actual Apple App Store but restricted to a curated set of apps, or is it a different system? If so, is the store a custom in-house thing or is it provided by a vendor?
There are multiple choices of OS but it's mostly Windows or Linux. Note, we don't do any mac/arm development.
It's funny because some 25 years ago we did the exact opposite. Corporate IT insisted on some Windows software, so we each ran a Windows VM that the corporate could pretend to remote manage.
(This was at a branch office where every employee worked on very low-level Linux kernel code, so yeah everyone ran their favorite Linux distro.)
There is an app store here too, but lots of vital dev tools simply aren't in there. We should probably make sure they get added.