Hacker News new | past | comments | ask | show | jobs | submit login

Sure, but just like the mentioned BIOS password, they are hardware, they reside outside the software and/or Operating System "security model". A (theoretical) BeOS (which as qubex noted has no authentication/login/password) install on a TPM/FDE hardware would be as safe (locally) as any Linux/NT/Whatever install. Same applies to mobile OS, which are typically "single user", one could delegate security to the hardware and get rid of the complications of the "multi-user OS" underlying base.



I presume that what you mean by "physical access" attacks is someone being able to boot into a different OS and steal data or muck with OS components. Of course it's outside the running-OS security model: the OS isn't running! Full disk encryption with a TPM verifying boot components (usually done with the assistance of Secure Boot) is not vulnerable to such an attack. Other physical access attacks, like reading disk encryption keys from DMA ports, can also be mitigated by 1) not having those ports, or 2) disabling them and then including BIOS settings in the TPM measurements used to protect the disk encryption key.

Full disclosure: I used to work on this functionality at Microsoft.


Sure, still all these are "outside" the actual OS multi-user paradigm, as qubex stated, the whole "workstation" or "terminal" model may be debated. At the time both Unix and NT had this generic idea that you had a "same" terminal (or workstation, call it as you like) to which multiple users with different credentials could have access. For that use BeOS (like Windows 9x) was totally out of question. Nowadays talking of mobile thingies, let's say a smartphone or iPad or even a MS Surface, 99.99% are "single user" so one could delegate the authentication to the hardware (TPM and SecureBootlike as much as you like) and have a simpler single user OS, without the complications, as such BeOS (or Haiku) may be not that bad.


I don't think it would simplify things that much. Having multiple users at the OS level is useful even when there's only one human user. For example, you can run a service as a user with limited privileges, to contain the effects of a vulnerability or breach.

Anyhow, sandboxing is just as necessary on a single-user OS as on a multi-user OS. And it's much more complex than multi-user support.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: