4 ms·

Today, the same OS core is used in phones, laptops, desktops and servers. Explicitly making it single-user means giving up on servers and parts of the market fo

by dvdkon 2y ago

Today, the same OS core is used in phones, laptops, desktops and servers. Explicitly making it single-user means giving up on servers and parts of the market for the former three. You could make the case for removing the concept of users from the kernel and forcing the OS to write some security plugin. The OS could then have a tailored security mechanism for every usecase, but they'd probably end up including users anyway (for the people who do want them).

rbanffy 2y ago
One such case is company-issued phones. They require the company-provided apps to be isolated from any user-specific configuration, creating an effective multi-user system where user apps (such as Apple Music) run with different privileges (and network access) than, say, Teams or Outlook.
- mavhc 2y ago
  Every app on your phone runs as a different user
- josephg 2y ago
  I think this is a good idea anyway. I love how if I install some dodgy app on my phone, it can't access the private, stored data of other apps. It can't steal my google or facebook credentials. And it can't cryptolocker my filesystem. My desktop computers are designed with this old "user security" model that I don't use at all - since I'm the only user anyway. User security protects ... uh, the operating system I suppose, which I could reinstall in 20 minutes anyway. But we're missing a much more important security boundary - which is between one bad program and all my other stuff. Every program you run today on desktop is inexplicably executed with full permission over all of your private files, and, worse, it has full network access. Its an insanely terrible design. We /could/ retrofit the user security model to help us isolate applications. But personally I think it would be easier to just design and implement something good from scratch. (For the security people in the room, the threat model is a bad program, or single bad npm package gets pulled into a program you run. How do we limit the blast radius?)
  - quintushoratius 2y ago
    You might be interested in Qubes OS, which runs every application in a virtual machine. https://en.wikipedia.org/wiki/Qubes_OS https://en.wikipedia.org/wiki/Qubes_OS

by dvdkon 2y ago

rbanffy 2y ago

One such case is company-issued phones. They require the company-provided apps to be isolated from any user-specific configuration, creating an effective multi-user system where user apps (such as Apple Music) run with different privileges (and network access) than, say, Teams or Outlook.

mavhc 2y ago
Every app on your phone runs as a different user
josephg 2y ago
I think this is a good idea anyway. I love how if I install some dodgy app on my phone, it can't access the private, stored data of other apps. It can't steal my google or facebook credentials. And it can't cryptolocker my filesystem. My desktop computers are designed with this old "user security" model that I don't use at all - since I'm the only user anyway. User security protects ... uh, the operating system I suppose, which I could reinstall in 20 minutes anyway. But we're missing a much more important security boundary - which is between one bad program and all my other stuff. Every program you run today on desktop is inexplicably executed with full permission over all of your private files, and, worse, it has full network access. Its an insanely terrible design. We /could/ retrofit the user security model to help us isolate applications. But personally I think it would be easier to just design and implement something good from scratch. (For the security people in the room, the threat model is a bad program, or single bad npm package gets pulled into a program you run. How do we limit the blast radius?)
- quintushoratius 2y ago
  You might be interested in Qubes OS, which runs every application in a virtual machine. https://en.wikipedia.org/wiki/Qubes_OS https://en.wikipedia.org/wiki/Qubes_OS