3 ms·

"in enterprises where Win/Mac are the only options." Why does that happen? It feels like the only reason WSL exists in the first place is to help sidestep the

"in enterprises where Win/Mac are the only options." Why does that happen? It feels like the only reason WSL exists in the first place is to help sidestep the monumental bureaucracy in fortune 100 companies that see Linux as nothing more than a risk. Its a methodone for companies that want devops, but are too calcified and encumbered to really do much besides lip service.

everforward 4y ago
Most distros have a poor security model for allowing partially-trusted users. The security model seems to have two modes: users/processes that are not trusted to do anything, and users/processes that are trusted to do nothing. E.g. try to find a sane and maintainable method for allowing non-root users to install Postgres. podman/Docker work for something like that, but what about VSCode? People can download a tarball, but I think the sandbox requires a setUID for some kind of security something. You can give people sudo rules, but sudo whitelisting is prone to ways to escape from the command and open a shell. WSL works because the company can control the hypervisor host strictly, and let the guest VM be more lax. The same would be true of a Linux VM inside a Linux host, but WSL lets the Windows people use Windows and the Linux people use Linux. It's not an unsolvable issue, but I can see why companies are interested in having a single device management suite that allows end users to use Windows or Linux (ish).
- DaiPlusPlus 4y ago
  I’m aware of the risks of a compromised machine, but if a company doesn’t trust its own software devs with local root/Administrator privileges (which are absolutely required for doing one’s job in SWE if you’re doing anything in drivers/hardware) then they don’t trust them to do their job. It boggles the mind.
  - everforward 4y ago
    There are reasons beyond compromised machines. Some companies have compliance/insurance concerns that require things to be set up a certain way, and to prevent users from undoing them. E.g. full disk encryption might be required, and users prevented from undoing that. Maybe there's some kind of audit agent that needs to run, and you don't want users removing it. Others don't want engineers breaking their desktops, or setting things up in a way where it's going to break the automation. E.g. systemd-networkd is centrally managed, but some user hates it so they're using network-manager instead, and now they can't connect to the network because network port control got turned on. Amortize that across several thousand engineers and you can waste a lot of man-hours because people aren't using the tools they're supposed to. I like having full root/admin permissions, but I don't really need or want 95% of the permissions it gives me. Linux makes it hard to delegate the 5% I actually want/need without giving me the other 95% that are basically only ever going to be problematic.
  - TristanBall 4y ago
    See.. my mind boggles that you think it has anything todo with personal trust. At a guess, you've been in that scenario, and it may well have been handled badly ( and i'll grant you it often is ), but you might also have taken it just a little bit personally? It's not my current job, but I've been doing various forms of sysadmin for a long, long time. Biggest security/outage risk in most companies I've work at? Me. My teams. Even after we've spent years and millions of dollars addressing those risks. But it's not about trusting your devs, even if somehow, you think you can trust all of them, and all your future hires, every day, forever (!?!?!) It's whether or not you trust all the software on their machine, everyday, forever. Which is just as ridiculous a statement. Isolated dev environments aren't that hard to setup if you really need HW access. Do it right and you might even end up with something better than local. And no, I don't have admin on my current work laptop either. Yes, it's occasionally annoying, and we have tighter controls than that, i cant do a bunch of things that most envs would allow without thought - and I occasionally set of alarms that trigger the security folks to have a word, which is also occasionally annoying. Reassuring too tho. And actually, slightly disappointed that's it's generally just a phonecall, and polite conversation, rather than black masked ninjas rappelling down from the ceiling yelling at me to step away from the keyboard, but you can't have everything I guess.
- pxc 4y ago
  > E.g. try to find a sane and maintainable method for allowing non-root users to install Postgres. podman/Docker work for something like that, but what about VSCode? The easiest way would be usermode package managers like Nix, Guix, or Homebrew. > People can download a tarball, but I think the sandbox requires a setUID for some kind of security something. I'm not sure what you mean, but you don't need root to use user namespaces (sandboxing) on any remotely recent Linux kernel. > Most distros have a poor security model for allowing partially-trusted users. [...] You can give people sudo rules, but sudo whitelisting is prone to ways to escape from the command and open a shell. The same product my employer just rolled out for managing this on Windows has a native Linux version. I assume it must have competitors. > WSL lets the Windows people use Windows and the Linux people use Linux No it does not. It lets the Windows people use Windows and the Linux people still have to use Windows, and a fucked up Linux VM that can't access their hardware, has to contend with Windows broken-ass networking stack, operates extemely slowly on files that are stored where the corporation wants people to store source code (i.e., on the Windows side), etc. > WSL works because the company can control the hypervisor host strictly, and let the guest VM be more lax. Why? Don't all of the material issues w/r/t endpoint management (data exfiltration, update management, anti-virus, idk) recur inside the VM anyway?
  - everforward 4y ago
    > The easiest way would be usermode package managers like Nix, Guix, or Homebrew. The insanity of the usermode packagers is that they're not popular enough to be easy to hire for (probably excepting Homebrew, though I've never seen it on Linux). I can grab a random resume from a stack and be almost positive that they know how to install and upgrade software with apt/yum. I would bet the percentage of candidates who can compile Postgres and use outweigh the number that can install and use Postgres from Nix. > I'm not sure what you mean, but you don't need root to use user namespaces (sandboxing) on any remotely recent Linux kernel. Nah, it's not user namespaces, it's some kind of Electron sandboxing that it wants setuid root for (I have no idea why). https://stackoverflow.com/questions/66816019/how-to-run-start-vscode-in-centos-7 https://stackoverflow.com/questions/66816019/how-to-run-star... has the error in question. > The same product my employer just rolled out for managing this on Windows has a native Linux version. I assume it must have competitors. I'd be curious how that works. I've seen things in the space that have tried via intercepting kernel syscalls (SELinux, AppArmor), but those seem like failed projects to me. I've never worked anywhere that has them turned on, though maybe that's sampling bias. > No it does not. It lets the Windows people use Windows and the Linux people still have to use Windows, and a fucked up Linux VM that can't access their hardware, has to contend with Windows broken-ass networking stack, operates extemely slowly on files that are stored where the corporation wants people to store source code (i.e., on the Windows side), etc. I'm not saying it's perfect, but I'll take it over being forced to use Windows or Mac natively. At least it's familiar, even if it is slow. > Why? Don't all of the material issues w/r/t endpoint management (data exfiltration, update management, anti-virus, idk) recur inside the VM anyway? Some do, some don't. You can prevent people from plugging in a 4G dongle to exfil data. You can force VM traffic to go through the host networking stack so it gets scanned by endpoint protection. For a lot of compliance stuff, it's enough that the software works on the physical host even if it can't do anything with the VM. E.g. compliance might say that all hosts have to run anti-virus, but the physical machine is the "host" so it's okay if the guest VM doesn't run anti-virus. Same with software auditing; it's enough for the procurement people that it runs on the Windows host. Most of the pragmatic issues recur inside the VM, but a lot of organizationally imposed ones go away. I'm not saying it's logical, but I've yet to win an argument with compliance.
CoolCold 4y ago
What can you recommend as good MDM (mobile device management) for Linux systems from your experience? I.e. https://www.manageengine.com/mobile-device-management/what-is-mdm.html https://www.manageengine.com/mobile-device-management/what-i... lists ChromeOS, but not "Linux" systems, while ManageEngine of the leading products as far as I know.

everforward 4y ago

Most distros have a poor security model for allowing partially-trusted users. The security model seems to have two modes: users/processes that are not trusted to do anything, and users/processes that are trusted to do nothing. E.g. try to find a sane and maintainable method for allowing non-root users to install Postgres. podman/Docker work for something like that, but what about VSCode? People can download a tarball, but I think the sandbox requires a setUID for some kind of security something. You can give people sudo rules, but sudo whitelisting is prone to ways to escape from the command and open a shell. WSL works because the company can control the hypervisor host strictly, and let the guest VM be more lax. The same would be true of a Linux VM inside a Linux host, but WSL lets the Windows people use Windows and the Linux people use Linux. It's not an unsolvable issue, but I can see why companies are interested in having a single device management suite that allows end users to use Windows or Linux (ish).

DaiPlusPlus 4y ago
I’m aware of the risks of a compromised machine, but if a company doesn’t trust its own software devs with local root/Administrator privileges (which are absolutely required for doing one’s job in SWE if you’re doing anything in drivers/hardware) then they don’t trust them to do their job. It boggles the mind.
- everforward 4y ago
  There are reasons beyond compromised machines. Some companies have compliance/insurance concerns that require things to be set up a certain way, and to prevent users from undoing them. E.g. full disk encryption might be required, and users prevented from undoing that. Maybe there's some kind of audit agent that needs to run, and you don't want users removing it. Others don't want engineers breaking their desktops, or setting things up in a way where it's going to break the automation. E.g. systemd-networkd is centrally managed, but some user hates it so they're using network-manager instead, and now they can't connect to the network because network port control got turned on. Amortize that across several thousand engineers and you can waste a lot of man-hours because people aren't using the tools they're supposed to. I like having full root/admin permissions, but I don't really need or want 95% of the permissions it gives me. Linux makes it hard to delegate the 5% I actually want/need without giving me the other 95% that are basically only ever going to be problematic.
- TristanBall 4y ago
  See.. my mind boggles that you think it has anything todo with personal trust. At a guess, you've been in that scenario, and it may well have been handled badly ( and i'll grant you it often is ), but you might also have taken it just a little bit personally? It's not my current job, but I've been doing various forms of sysadmin for a long, long time. Biggest security/outage risk in most companies I've work at? Me. My teams. Even after we've spent years and millions of dollars addressing those risks. But it's not about trusting your devs, even if somehow, you think you can trust all of them, and all your future hires, every day, forever (!?!?!) It's whether or not you trust all the software on their machine, everyday, forever. Which is just as ridiculous a statement. Isolated dev environments aren't that hard to setup if you really need HW access. Do it right and you might even end up with something better than local. And no, I don't have admin on my current work laptop either. Yes, it's occasionally annoying, and we have tighter controls than that, i cant do a bunch of things that most envs would allow without thought - and I occasionally set of alarms that trigger the security folks to have a word, which is also occasionally annoying. Reassuring too tho. And actually, slightly disappointed that's it's generally just a phonecall, and polite conversation, rather than black masked ninjas rappelling down from the ceiling yelling at me to step away from the keyboard, but you can't have everything I guess.
pxc 4y ago
> E.g. try to find a sane and maintainable method for allowing non-root users to install Postgres. podman/Docker work for something like that, but what about VSCode? The easiest way would be usermode package managers like Nix, Guix, or Homebrew. > People can download a tarball, but I think the sandbox requires a setUID for some kind of security something. I'm not sure what you mean, but you don't need root to use user namespaces (sandboxing) on any remotely recent Linux kernel. > Most distros have a poor security model for allowing partially-trusted users. [...] You can give people sudo rules, but sudo whitelisting is prone to ways to escape from the command and open a shell. The same product my employer just rolled out for managing this on Windows has a native Linux version. I assume it must have competitors. > WSL lets the Windows people use Windows and the Linux people use Linux No it does not. It lets the Windows people use Windows and the Linux people still have to use Windows, and a fucked up Linux VM that can't access their hardware, has to contend with Windows broken-ass networking stack, operates extemely slowly on files that are stored where the corporation wants people to store source code (i.e., on the Windows side), etc. > WSL works because the company can control the hypervisor host strictly, and let the guest VM be more lax. Why? Don't all of the material issues w/r/t endpoint management (data exfiltration, update management, anti-virus, idk) recur inside the VM anyway?
- everforward 4y ago
  > The easiest way would be usermode package managers like Nix, Guix, or Homebrew. The insanity of the usermode packagers is that they're not popular enough to be easy to hire for (probably excepting Homebrew, though I've never seen it on Linux). I can grab a random resume from a stack and be almost positive that they know how to install and upgrade software with apt/yum. I would bet the percentage of candidates who can compile Postgres and use outweigh the number that can install and use Postgres from Nix. > I'm not sure what you mean, but you don't need root to use user namespaces (sandboxing) on any remotely recent Linux kernel. Nah, it's not user namespaces, it's some kind of Electron sandboxing that it wants setuid root for (I have no idea why). https://stackoverflow.com/questions/66816019/how-to-run-start-vscode-in-centos-7 https://stackoverflow.com/questions/66816019/how-to-run-star... has the error in question. > The same product my employer just rolled out for managing this on Windows has a native Linux version. I assume it must have competitors. I'd be curious how that works. I've seen things in the space that have tried via intercepting kernel syscalls (SELinux, AppArmor), but those seem like failed projects to me. I've never worked anywhere that has them turned on, though maybe that's sampling bias. > No it does not. It lets the Windows people use Windows and the Linux people still have to use Windows, and a fucked up Linux VM that can't access their hardware, has to contend with Windows broken-ass networking stack, operates extemely slowly on files that are stored where the corporation wants people to store source code (i.e., on the Windows side), etc. I'm not saying it's perfect, but I'll take it over being forced to use Windows or Mac natively. At least it's familiar, even if it is slow. > Why? Don't all of the material issues w/r/t endpoint management (data exfiltration, update management, anti-virus, idk) recur inside the VM anyway? Some do, some don't. You can prevent people from plugging in a 4G dongle to exfil data. You can force VM traffic to go through the host networking stack so it gets scanned by endpoint protection. For a lot of compliance stuff, it's enough that the software works on the physical host even if it can't do anything with the VM. E.g. compliance might say that all hosts have to run anti-virus, but the physical machine is the "host" so it's okay if the guest VM doesn't run anti-virus. Same with software auditing; it's enough for the procurement people that it runs on the Windows host. Most of the pragmatic issues recur inside the VM, but a lot of organizationally imposed ones go away. I'm not saying it's logical, but I've yet to win an argument with compliance.

CoolCold 4y ago

What can you recommend as good MDM (mobile device management) for Linux systems from your experience? I.e. https://www.manageengine.com/mobile-device-management/what-is-mdm.html https://www.manageengine.com/mobile-device-management/what-i... lists ChromeOS, but not "Linux" systems, while ManageEngine of the leading products as far as I know.