9 ms·

Yes! This is an argument I've been making for several years now: the user-centric security model is obsolete and unhelpful, because most computers have either o

Yes! This is an argument I've been making for several years now: the user-centric security model is obsolete and unhelpful, because most computers have either one or zero users in the traditional sense. The whole unix-style reduced-privileges-plus-sudo approach that Windows and MacOS have copied is a nuisance which doesn't really solve the problem; the permissions systems in Android and iOS are a little closer to the mark. Qubes is a good step forward. The real problem is exactly what you said: we can't fully trust software, even software which is not explicitly malicious, because software can be exploited, and because software authors sometimes want to be "helpful" in ways we'd really rather they weren't. Every piece of software should run within a sandbox, and the human user should have complete control over which resources are or are not exposed to each sandbox; that's the future operating system I want to see. I did some exploration around the idea of doing this with hypervisors and unikernels (http://www.github.com/marssaxman/fleet http://www.github.com/marssaxman/fleet) but it got to look too much like rewriting all the software in the world. Containers are less elegant, but seem to be a more practical way of moving in the right direction.

fdgdasfadsf 10y ago
> Every piece of software should run within a sandbox I sort of agree with this but I think more in terms of projects/activities (e.g. casual media consumption, banking, working on different projects) rather than applications. To do different activities I need different combinations of tools but often the tools overlap. For example I want to sandbox the browser I use for watching cat videos on youtube from the browser I use for banking from the various browsers I use for work. So that some drive by on a casual browsing site can't attack my banking. But I don't want two browsers installed I want the same program in the same version with some common and some different config - but I don't want to manage the common config in 5 different places. The multi-user model allows for some attempt at this if one sets up multiple user accounts for the different activities. It certainly isn't sufficient but I'm not sure that sandboxing each application will actually get us there either.
- Too 10y ago
  I've been thinking about this many times before and while I want to like the idea, I always come to the conclusion that multi user setups sharing "some" data easily becomes too complex for users to handle. Your example of the browser for example, how do you know what is common config? What if changing a common config in cat-mode exposes a security vulnerability in bank-mode? And are you really going to log out of cat mode into common mode just to change a small setting? Sharing files is another one of my favorites, say for example that me and my brother like the same music and share one computer with different log ins. We want to save space on the hard drive so we share all our mp3 with each other. But I might have some music or recordings I dont want to share, how should I handle that. Windows XP tried very hard to get this working, for example your desktop and start menu was a blend of what was installed as a shared application (remember "install for all users/only for me"?) and what was installed for one user. Later if someone renamed things on what they thought was their desktop it would be renamed on everybody else's desktop also, it was very confusing even for me as a developer who knows how it works. Windows also has the concept of a dedicated shared folder and possibility to share additional folders, sounds so simple but I've never seen anyone set it up smoothly. Everything looks so good and simple on paper but requires just a tiny bit of user education and that's where the whole concept falls.
  - fdgdasfadsf 10y ago
    It is relatively easy to have multiple users sessions open at the same time. Whether this is a good idea with X windows GUIs is another matter.
MichaelMoser123 10y ago
% Every piece of software should run within a sandbox What about shared libraries? How do you define the access rights or set of processes that glibc is allowed to run with? (you might have to break up glibc into dozens of smaller libraries for that - and then manage their dependencies, the resulting web will not be too different from monolithic glibc) Also it does not solve the problem completely (not possible to do that with security anyway) - see rowhammer exploits.
- quotemstr 10y ago
  There's a faction trying to kill shared libraries. Nobody outside mobile really cares anymore. Go and Rust compile to giant shared blobs. The GTK people don't care about binary compatibility anymore. Musl doesn't support dlclose.
  - MichaelMoser123 10y ago
    Ok, in this event you need to recompile all services when a vulnerability is discovered in one of the dependent libraries; i suspect that this means that the system will not get updated in time - and that's not good at all. At least with shared libraries you can swap the so file - if the external interface has not been modified by the fix.
    - XorNot 10y ago
      A counter argument to this is recompilation should not be painful: it should be standard. And this is already somewhat true anyway: binary package distributions are a little like this. Someone else handles the compiling. So take it further: distribute binary diffs for packages to control file size, kill shared libraries dead. Have the compiler write dedupe-friendly executables so your filesystem removes duplicate blocks in binaries efficiently and let the kernel page sharing system sort out runtime.
  - pjmlp 10y ago
    Go and Rust support shared libraries, even if on Go's case it is a WIP.
yellowapple 10y ago
The user-centric model is actually still relevant if you use them as the means to software isolation. This is a major aspect to the security models of OpenBSD and (last I checked) Android, and is generally effective (unless you're deliberately subverting it, as is common on "rooted" Android devices). However, said model still has connotations of a specific actual user, which is no longer entirely accurate in such applications of that model. It'd be nice to have a sort of "subuser" system where - within, say, the user for my own desktop account - I could further divide the software I run into "users" for things like Firefox or Spotify or what have me. Basically, I'm in agreement that everything should be sandboxed. We have the technology to do it, and in fact have had the technology to do it for decades (maybe not quite as well as we can do now, but confining daemons to their own users has been possible for a long time). My own dream system would be one where every "package" for my operating system is a filesystem image with `/bin`, `/lib`, `/etc`, and possibly `/var`. One of these packages would provide the root filesystem with a microkernel and the minimum supporting libraries and executables required to get a container-oriented `init` equivalent running; then, `init` would spin up each service in complete isolation by spinning up `chroot`s or something with various packages union-mounted on top of one another. One of these services could be for a graphical login, in which case said service would spin up another isolated container of sorts for my login session, and inside that I could run applications built up from the same union-mount approach with the same sort of isolation. Plan 9 From Bell Labs is probably the closest thing to that ideal world.
- fao_ 10y ago
  However, said model still has connotations of a specific actual user, which is no longer entirely accurate in such applications of that model. It'd be nice to have a sort of "subuser" system where - within, say, the user for my own desktop account - I could further divide the software I run into "users" for things like Firefox or Spotify or what have me. I think you might be able to use groups for this.
  - yellowapple 10y ago
    Sort of. Groups seem to be better suited for roles - e.g. to provide resources to sandboxes rather than act as sandboxes themselves.
dfischer 10y ago
That essentially means a universal i/o between all programs ever built but at a high level. All up to user discretion on how they want to wire up all their "programs".
JdeBP 10y ago
Windows NT didn't copy the Unix security model. Indeed, people have remarked for the past 30 years that the Windows NT model has nothing like set-UID, for starters. People who think that the Windows NT model is like the Unix one, do not know Windows NT. There are some very interesting differences, including: * Variable-length security IDs, with a much larger namespace. * The ability of a process to employ multiple tokens during the course of its existence, including kernel-enforced restrictions on how it can employ tokens borrowed from service clients. * Nonce security IDs, employed (for example) to partition a single user from xyrself when it comes to granting access to window stations and desktops. * Universal security IDs for truly universal things, such as "Everyone" and "Creator Group", that are the same everywhere. "nobody" is one UID on FreeBSD and Debian, and a different UID on OpenBSD. * Local security IDs for local things, such as all security IDs for domain user accounts incorporating the unique ID of the domain (controllers) making the domain user account SIDs globally unique. Two BSD/Linux systems can have two different users with the same UID 1001. * Universal RIDs for things that every domain has, like "this domain's printer operator", "this domain's policy administrator", and "this domain's backup operator". FreeBSD's/OpenBSD's "operator" has the UID of Debian's "bin"; FreeBSD's/OpenBSD's "bin" has the UID of Debian's "sys"; FreeBSD's/OpenBSD's "operator" group has the GID of Debian's "tty" group; FreeBSD's/OpenBSD's "tty" group has the GID of Debian's "adm" group. * Standard security IDs for granting permissions to log on locally, via a network, in batch, as a service, or via dialup. * A Hurd-like mechanism for obtaining process tokens: an RPC transaction to a distinguished server process inside the TCB -- /hurd/passwd meet Local Security Authority Subsystem Service
- fdgdasfadsf 10y ago
  And people just end up running everything as Admin the first time something needs any of this.
  - paol 10y ago
    You exaggerate, but only slightly. Whatever the theoretical properties of the windows security model, it's a failure of usability, and that means most of the time none of it gets used. Windows is not alone in this, SELinux suffers from exactly the same problem.

fdgdasfadsf 10y ago

> Every piece of software should run within a sandbox I sort of agree with this but I think more in terms of projects/activities (e.g. casual media consumption, banking, working on different projects) rather than applications. To do different activities I need different combinations of tools but often the tools overlap. For example I want to sandbox the browser I use for watching cat videos on youtube from the browser I use for banking from the various browsers I use for work. So that some drive by on a casual browsing site can't attack my banking. But I don't want two browsers installed I want the same program in the same version with some common and some different config - but I don't want to manage the common config in 5 different places. The multi-user model allows for some attempt at this if one sets up multiple user accounts for the different activities. It certainly isn't sufficient but I'm not sure that sandboxing each application will actually get us there either.

Too 10y ago
I've been thinking about this many times before and while I want to like the idea, I always come to the conclusion that multi user setups sharing "some" data easily becomes too complex for users to handle. Your example of the browser for example, how do you know what is common config? What if changing a common config in cat-mode exposes a security vulnerability in bank-mode? And are you really going to log out of cat mode into common mode just to change a small setting? Sharing files is another one of my favorites, say for example that me and my brother like the same music and share one computer with different log ins. We want to save space on the hard drive so we share all our mp3 with each other. But I might have some music or recordings I dont want to share, how should I handle that. Windows XP tried very hard to get this working, for example your desktop and start menu was a blend of what was installed as a shared application (remember "install for all users/only for me"?) and what was installed for one user. Later if someone renamed things on what they thought was their desktop it would be renamed on everybody else's desktop also, it was very confusing even for me as a developer who knows how it works. Windows also has the concept of a dedicated shared folder and possibility to share additional folders, sounds so simple but I've never seen anyone set it up smoothly. Everything looks so good and simple on paper but requires just a tiny bit of user education and that's where the whole concept falls.
- fdgdasfadsf 10y ago
  It is relatively easy to have multiple users sessions open at the same time. Whether this is a good idea with X windows GUIs is another matter.

MichaelMoser123 10y ago

% Every piece of software should run within a sandbox What about shared libraries? How do you define the access rights or set of processes that glibc is allowed to run with? (you might have to break up glibc into dozens of smaller libraries for that - and then manage their dependencies, the resulting web will not be too different from monolithic glibc) Also it does not solve the problem completely (not possible to do that with security anyway) - see rowhammer exploits.

quotemstr 10y ago
There's a faction trying to kill shared libraries. Nobody outside mobile really cares anymore. Go and Rust compile to giant shared blobs. The GTK people don't care about binary compatibility anymore. Musl doesn't support dlclose.
- MichaelMoser123 10y ago
  Ok, in this event you need to recompile all services when a vulnerability is discovered in one of the dependent libraries; i suspect that this means that the system will not get updated in time - and that's not good at all. At least with shared libraries you can swap the so file - if the external interface has not been modified by the fix.
  - XorNot 10y ago
    A counter argument to this is recompilation should not be painful: it should be standard. And this is already somewhat true anyway: binary package distributions are a little like this. Someone else handles the compiling. So take it further: distribute binary diffs for packages to control file size, kill shared libraries dead. Have the compiler write dedupe-friendly executables so your filesystem removes duplicate blocks in binaries efficiently and let the kernel page sharing system sort out runtime.
- pjmlp 10y ago
  Go and Rust support shared libraries, even if on Go's case it is a WIP.

yellowapple 10y ago

The user-centric model is actually still relevant if you use them as the means to software isolation. This is a major aspect to the security models of OpenBSD and (last I checked) Android, and is generally effective (unless you're deliberately subverting it, as is common on "rooted" Android devices). However, said model still has connotations of a specific actual user, which is no longer entirely accurate in such applications of that model. It'd be nice to have a sort of "subuser" system where - within, say, the user for my own desktop account - I could further divide the software I run into "users" for things like Firefox or Spotify or what have me. Basically, I'm in agreement that everything should be sandboxed. We have the technology to do it, and in fact have had the technology to do it for decades (maybe not quite as well as we can do now, but confining daemons to their own users has been possible for a long time). My own dream system would be one where every "package" for my operating system is a filesystem image with `/bin`, `/lib`, `/etc`, and possibly `/var`. One of these packages would provide the root filesystem with a microkernel and the minimum supporting libraries and executables required to get a container-oriented `init` equivalent running; then, `init` would spin up each service in complete isolation by spinning up `chroot`s or something with various packages union-mounted on top of one another. One of these services could be for a graphical login, in which case said service would spin up another isolated container of sorts for my login session, and inside that I could run applications built up from the same union-mount approach with the same sort of isolation. Plan 9 From Bell Labs is probably the closest thing to that ideal world.

fao_ 10y ago
However, said model still has connotations of a specific actual user, which is no longer entirely accurate in such applications of that model. It'd be nice to have a sort of "subuser" system where - within, say, the user for my own desktop account - I could further divide the software I run into "users" for things like Firefox or Spotify or what have me. I think you might be able to use groups for this.
- yellowapple 10y ago
  Sort of. Groups seem to be better suited for roles - e.g. to provide resources to sandboxes rather than act as sandboxes themselves.

dfischer 10y ago

That essentially means a universal i/o between all programs ever built but at a high level. All up to user discretion on how they want to wire up all their "programs".

JdeBP 10y ago

Windows NT didn't copy the Unix security model. Indeed, people have remarked for the past 30 years that the Windows NT model has nothing like set-UID, for starters. People who think that the Windows NT model is like the Unix one, do not know Windows NT. There are some very interesting differences, including: * Variable-length security IDs, with a much larger namespace. * The ability of a process to employ multiple tokens during the course of its existence, including kernel-enforced restrictions on how it can employ tokens borrowed from service clients. * Nonce security IDs, employed (for example) to partition a single user from xyrself when it comes to granting access to window stations and desktops. * Universal security IDs for truly universal things, such as "Everyone" and "Creator Group", that are the same everywhere. "nobody" is one UID on FreeBSD and Debian, and a different UID on OpenBSD. * Local security IDs for local things, such as all security IDs for domain user accounts incorporating the unique ID of the domain (controllers) making the domain user account SIDs globally unique. Two BSD/Linux systems can have two different users with the same UID 1001. * Universal RIDs for things that every domain has, like "this domain's printer operator", "this domain's policy administrator", and "this domain's backup operator". FreeBSD's/OpenBSD's "operator" has the UID of Debian's "bin"; FreeBSD's/OpenBSD's "bin" has the UID of Debian's "sys"; FreeBSD's/OpenBSD's "operator" group has the GID of Debian's "tty" group; FreeBSD's/OpenBSD's "tty" group has the GID of Debian's "adm" group. * Standard security IDs for granting permissions to log on locally, via a network, in batch, as a service, or via dialup. * A Hurd-like mechanism for obtaining process tokens: an RPC transaction to a distinguished server process inside the TCB -- /hurd/passwd meet Local Security Authority Subsystem Service

fdgdasfadsf 10y ago
And people just end up running everything as Admin the first time something needs any of this.
- paol 10y ago
  You exaggerate, but only slightly. Whatever the theoretical properties of the windows security model, it's a failure of usability, and that means most of the time none of it gets used. Windows is not alone in this, SELinux suffers from exactly the same problem.