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

I adored BeOS but I am not sure whether the single-user “wide open” lack-of-security model it embodied was a path worth taking. Surely one can question whether it makes sense to have purportedly multi-user UNIX-derived OSes on single-user mobile devices, but...

That was the norm back then though. Windows 98, Mac OS 8 and 9. Yeah Windows NT 4 / 2000 were multi-user but they were targeting workstations rather than personal computing and even then it was another 5 or 10 years later before Microsoft took security seriously in their NT line (roughly midway through XP's like if I recall correctly)

Never mind that persistent internet connectivity was not the norm for most at that stage. This curtailed the power of drive by infections to a large degree.

My parents (and many others' parents too, I'm sure) know this all too well. Sometimes at parties I still have to hear about all those times I caused the phone bill to become huge because I couldn't leave the CompuServe Information Manager and IRC alone. Great times.

Or NT based for that matters. Talking of PC's still today, some 20 years later, more or less the only thing that may prevent unauthorized access from an intruder with physical access to a machine is the BIOS password, anything else is just something that may slow down him/her a little bit.

Well, yeah — but NT was maimed mainly by flawed implementation and assumptions made in the threat model (crucially, assumptions about the remote and local attack surface —code execution by unauthenticated users (the world of the web) and the presumption of no offline access to local hardware (NTchngpwd)—) that required strengthening and reinforcement, whereas BeOS (and DOS/Windows9x) are totally unprepared for this kind of thinking.

Full disk encryption backed by a TPM or other hardware-based security module is secure against physical access attacks. This isn't an esoteric setup either: most windows PCs on the market support this.

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.

Well most computers back then were bulky desktops, not shoulder bag friendly laptops.

Never mind that the first threat scenario contemplated is a physical attacker is way out there on the probability scale unless you already suspect you are on someone's hit list.

Err. All operating systems suffer from that problem.

No. Systems that rely on encrypted and signed credentials to perform login theoretically do not suffer from that problem: case in point, the Windows SAM had hashed that seem to preclude if limited to NTLM decryption save for brute-forcing, which itself is curtailed by salting the hashes — but if those hashes are removed by offline editing to the SAM, the system allowed access. A system that did not allow removing the hashes because the file system is encrypted and/or because signing made the tampering visible (itself evaluated by TPM-style verification) would be conceptually not vulnerable to this line of attack (implementation flaws notwithstanding).

Windows has support for full-disk encryption using a passphrase or physical key. It also supports Secure Boot.

I don't see what that has to do with multi-user systems though. If your argument is that we could have the Secure Boot system ask for the passphrase and tie the entire box to a single user... then you're missing out on most of the current point of multi-user systems.

The first is that many companies actually do have multiple people using the same machines. Not at the same time, but at different times. This needs auditing - i.e. a multi-user system.

The second is, again, auditing - when a system administrator runs a command on a system remotely, they do it as their own user.

The third is security (combined with auditing) - various service processes get run in different user contexts so that they can't mess with the user's stuff unless they're allowed to, and they have their own user ID that anything they do happens under.

Operating systems aren't built for home users, they're built for companies, in almost all cases, and stripping out the multi-user framework would change the OS to be unrecognisable. Just stripping out the authentication part doesn't buy you much complexity reduction either.

I must have expressed myself unclearly.

(First though: Windows now supports full disk encryption and secure boot. It certainly did not when I and it parted ways back in the days of XP SP1 circa 2002.)

I was not implying that the secure pass phrase/secure boot/etc be considered the basis for a secure mobile OS. Much the contrary. Multi-user systems with privilege hierarchies are fundamental aspects of how we now architect even our single-user devices. (Discussing whether another system is possible, desirable, and/or whether we could have or will eventually go down that route is midway between hypothetical and counter-factual.)

We were talking of actual single user systems in practice, tablets, smartphones and similar are usually single user devices and even in corporate many laptops are used as desktop replacement by single employees...

You mentioned PCs originally, hence the confusion.

In any case, I believe Android uses the multi-user features of Linux as a security mechanism (and building a new kernel from scratch might not have led to Android being a major player - ARM companies already knew how to write device drivers for Linux), although it could reasonably use an object-capability system under a more focused kernel.

Never mind that it even today is way down the list of probable attack scenarios for most personal computers.

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