Comment on What the Linux desktop really needs to challenge Windows

• vacuumflower@lemmy.sdf.org ⁨1⁩ ⁨day⁩ ago

  I think you can:

  1. set up something like Fedora Silverblue,
  2. disallow root,
  3. disallow sysrq and such,
  4. allow sudo only for select few things,
  5. refresh configuration centrally.

  I’m not sure it’s much more work than what I’ve seen in corporate environments with Windows.

  source

  • enumerator4829@sh.itjust.works ⁨1⁩ ⁨day⁩ ago

    I’ve managed Linux desktop fleets in enterprise-like environments. I’ll modify your list a bit:

    1. Use Rocky or RHEL (because the commercial software you want to use only has support for RHEL and/or Ubuntu)
    2. disallow root completely without exception
    3. do additional hardening
    4. don’t allow sudo for fucking anything
    5. run centrally controlled configuration management (most likely Puppet)
    6. Ironically - disallow any use of Flatpak, Snap and AppImage. They don’t play that well with Kerberized NFS-mounted home directories, which you absofuckinglutely will be required to use. (Might have improved since I tried last time, but probably not. Kerberos and network mounted directories,home or otherwise, are usually a hard requirement.)
    7. Install and manage all software via configuration management (again, somewhat ironically, this works very well with RPMs and DEBs, but not with Flatpak/Snap/Appimage). Update religiously, but controlled (i.e. Snap is out).
    8. A full reprovision of everything fairly regularly.
    9. You most likely want TPM-based unlocking of your LUKS encrypted drives, with SecureBoot turned on. This is very fun to get working properly in a Linux environment, but super simple to do on Windows.

    And as you have guessed, on Windows this requires a bit of point and click in SCCM to do decently.

    On Linux, you’ll wanna start by getting a few really good sysadmins to write a bunch of Puppet for a year or so.

    (If we include remote desktop capabilities in the discussion, I’ll do my yearly Wayland-rant.)

    source

    • VirtuePacket@lemmy.zip ⁨1⁩ ⁨day⁩ ago

      The other thing you’ll need is for compliance and risk management frameworks (e.g. CMMC, ISO27001, CIS, etc.) to fully embrace Linux controls and environments. As of right now, it’s a patchwork full of holes and if you need to demonstrate compliance, it’s likely to be a lot more challenging running Linux workstations.

      source
    • vacuumflower@lemmy.sdf.org ⁨1⁩ ⁨day⁩ ago

      1. OK. I agree, but personally hate RHEL.
      2. Yes.
      3. Suppose so.
      4. Brightness and sound controls too?..
      5. Yep, meant that.
      6. I thought of something like company-issued laptops, which might be good to have functional without Internet connectivity sometimes, if it’s remote work.
      7. Dependent on the role some users might need to regularly install software you haven’t thought about.
      8. Yes.
      9. Well, disagree about SecureBoot, there’s nothing secure about MS signing your binaries. It’s just proof they are signed by MS. Setting TPM under Linux is, eh, something I’ve never done.

      source

      • enumerator4829@sh.itjust.works ⁨1⁩ ⁨day⁩ ago

        You need to have secure boot in order to have the disk decrypt without user input, otherwise the chain is untrusted. You can (and probably should) load your own keys into the firmware and sign everything yourself. MS has nothing to do with it, except that BitLocker is much better than anything any Linux distro has to offer today.

        You need to have the disk decrypt without user input, and you can’t have the secret with the user. (As the user is untrusted - could be someone stealing the laptop.) The normal Linux user mantra of ”I own the machine” does not apply here. In this threat model, the corporation owns the machine, and in particular any information on it.

        As for sudo, this is why we have polkit. (Yes, technically root, but you get my point)

        And as for number 7 - this is why most Windows fleets use ”Software Center” or similar. No reason you can’t do the same on Linux, just that no one has done it yet. (I mean, you can, with pull requests into a puppet repo, but that’s not very user friendly)

        Hate RHEL all you want, but first take a look at what distros have any kind of commercial support at all from software vendors. This is the complete list: RHEL, sometimes Rocky, sometimes Ubuntu. Go ask your vendor about Fedora Silverblue and see what happens. The primary reason to run Linux like this is usually to use a specific (and probably very expensive) software that works best on Linux, so distro choice is usually very limited to what that software vendor supports. (And when they say Linux, they are really saying ”the oldest still supported RHEL.)

        Basically, corporate requirements go completely against the requirements of enthusiasts and power users. You don’t need Secure Boot to protect your machine from thieves, but a corporation needs Secure Boot to protect the machine from you.

        source

        • -> View More Comments
      • WhyJiffie@sh.itjust.works ⁨1⁩ ⁨day⁩ ago

        Well, disagree about SecureBoot, there’s nothing secure about MS signing your binaries. It’s just proof they are signed by MS. Setting TPM under Linux is, eh, something I’ve never done.

        that’s the difficult part of SecureBoot: you need to set up MOK and somehow sign the bootloader, kernel, modules with it.
        but against small scale intrusions even the MS signed things could work

        source