Comment by esafak

7 hours ago

> ...so make it its own security principal, distinct from the human user?

That presumes the existence of a security context, which this product provides. Where do you configure the security principal otherwise?

7 comments

esafak

Reply
freeone3000  7 hours ago

Windows already has a multi-user security context, with file- and API-level permissioning. We often call it “Users” or “RBAC”. I’ve read it and I’m still not sure what I can do now that I couldn’t a week ago.

  • eddythompson80  5 hours ago

    The same-machine-multi-user security paradigm has been dead for a long time. Even on linux, you pretty much assume root or non-root and leave it at that. You then use other layers (namespacing, kvm, etc) to enforce actual security isolation and controls.

    root/non-root split is almost entirely used as a "don't let people accidentally shoot themselves in the foot" mechanism these days. Like you don't want your point-of-sale operator to accidentally disable the network or mess up the firewall rules effectively bricking the machine. Requiring an IT person to make the trip to fix it for them. But you would never "trust" the separate user profile on that POS machine as something keeping a purposefully malicious employee out of a secure system. The entire machine, regardless of the user profile, is the same security context. The uid/gid concept is an antique from the 80s that stopped working a long time ago. It's just an organizational primitive now for the most part.

    I remember the fun days of the 90s and early 2000s when there were shared machines that a ton of people would ssh or rdp into with different user account and "share compute". It was fun, but absolutely no bueno for a long time now.

    • zbentley  3 hours ago

      > The same-machine-multi-user security paradigm has been dead for a long time.

      I ... what? Huge swaths of the computing landscape depend entirely that model. Schools (from primary to academic research), Windows Active Directory workplaces, thousands of cheap VPS providers ... the list is very long. All of those contexts absolutely use user accounts on the same running OS kernel as a security boundary. I've seen more than a few academic and government worksites where effectively radioactive data owned by one user was on the physical machine that other users routinely used--just not in an account they could access. Those places' infosec history wasn't perfect, but not because of the insider-threat-on-shared-machine risk.

      In cloud/webtech, I think it's easy to overlook just how many massive organizations rely on stuff like shared AD workstations, cheap user-based shared hosting, or shared HPC a la "every member of the university gets an account on the SLURM cluster and we slice compute allocations by account--and separate accounts prevent the new intern from seeing protected IP".

      Like, malicious employees can attack such systems, yes. But with adequate mitigations (network partitioning, internet access control, auditing/telemetry, good SEIM, user data encryption where appropriate, patching...all the usual good practices) this is a perfectly viable security model. Not perfect, but nothing's perfectly secure and every security paradigm has tradeoffs.

      Those environments aren't dinosaurs or asking for a security disaster; they've made considered risk assessments and decided that the multi-user-machine security model works for them.