enumerator4829

Look, I’m not saying BitLocker isn’t flawed. I’n m saying the alternatives on Linux are shit. All the primitives are there, and you can do it on Linux, with lots of work, testing and QC of all software updates on all your hardware (or else you’ll do manual entry of disaster recovery keys for the next decade). But on Windows it’s a checkbox to encrypt the entire fleet, along with management of recovery keys.

Also, on audits: for people doing checkbox security (i.e. most regulated industries), this is very easy to audit. You just smack in ”Bitlocker” and you are done. For some, the threat isn’t really information loss, it’s loss of compliance (and therefore revenue). Stupid, but here we are. If you mean actual security, then you are probably correct.

A smart cart only authenticates and identifies the user - it can’t do attestation of the boot chain. If we use a smart card for disk encryption, a malicious or compromised user can just pop out the SSD, mount and decrypt (using the smart card) on a separate machine and extract/modify data without a trace. If you use SB, the TPM and disk encryption as intended, you can trust both the user (via smart card) and the machine (probably via a Kerberos machine key). Basically, this method prevents the user from accessing or modifying data on their own machine.

Again, on Windows this is basic shit any Windows sysadmin can roll out easily following a youtube tutorial or something. Providing those same security controls on Linux will yield a world of pain.

We really need to make this easy on Linux. systemd-boot and UKIs are trying, but are not even close to enough.

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.

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.)

https://en.wikipedia.org/wiki/Cognitive_behavioral_therapy_for_insomnia

I’m not that well versed on anything Graphene, nor any related drama.

Trust is somewhat non-technical, personal, subjective and dependent on your threat model. You can greatly improve trust via technical means and processes, as well as distribute and communicate trust via technical means. In the end, you still need to trust one or more physical people.

Personally, my biggest issue with any software I use is future maintenance. Can I be certain this will keep working as I want it for the duration I want? Will I get security updates? There, the trust comes from the people and funding involved, seldom technology.

Canonicals non-LTS releases are basically shitty betas. No one sane uses them in production or on their desktop.

If you want to encode information into only the depth of your recursive identically named folders, you have 128 different depths, one character for the name, one for the slash, per level. Yields about 128 possible levels. Leave one off for the last filename, 127.

If we want to name our folders something longer than a single character, we can store less files. If we want to store our files on linux, by default we get 4096 characters to play with, so about 2k levels (unless we compile our own linux kernel with PATH_MAX set for this very specific purpose). If we run CIFS we may be able to reach up to 16k levels.

That was my interpretation of OPs (admittedly bad) idea. Personally, I try to avoid implementing inodes as Church numerals.

Who do you think pays for the bailouts in the end?

You can now have 128 files in your filesystem.

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

All connectors are compatible given enough violence.

The VGA connector is actually reversible! Once. given enough force. It also doesn’t actually work properly when installed upside down.