Hacker News Reader

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

And people just end up running everything as Admin the first time something needs any of this.

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.

Exactly. JOin NT perms with sharing perms plus GPO's and you'll get a clusterfuck.

I have very limited experience with Windows and don't claim to know much of anything about its security. I was referring to the User Account Control system introduced in Windows 7. Whatever might be happening underneath, the system appears to end up doing the same thing: the user operates in a reduced-privileges mode until specifically authorizing a local, temporary elevation.

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.

  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.

Sort of. Groups seem to be better suited for roles - e.g. to provide resources to sandboxes rather than act as sandboxes themselves.

In a fashion, you can also do this with sudo -u

    sudo -u ff_user firefox

This way Firefox is run as a separate user within the current user's session, with all that entails. Of course, that would be a serious pita for your average user to setup.

I guess you could script a lot of it to happen automagically for a subset of applications.

> It'd be nice to have a sort of "subuser" system

Reminds me of genode's application-specific trusted computing bases.

http://genode.org/documentation/general-overview/index

> 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`.

Take a look at NixOS and the Nix package manager. It works along these lines [0].

> then, `init` would spin up each service in complete isolation by spinning up `chroot`s

Systemd employs container features, some automatically like cgroups and some via configuration. There was an article on HN just the other day about some of its new sandbox features [1]. Parameters such as PrivateNetwork=, ProtectSystem=strict, PrivateTmp=yes, SystemCallFilter= provide chroot-like capabilities in a number of different namespace dimensions. It has support for chroot as well through the RootDirectory= parameter. See [2] for a good overview of these featuers and [3] for the reference.

Hopefully as these features mature and gain adoption, system software will operate more like what you're describing over time.

[0] https://nixos.org/

[1] https://news.ycombinator.com/item?id=12874731

[2] http://0pointer.de/blog/projects/security.html

[3] https://www.freedesktop.org/software/systemd/man/systemd.exe...

> 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.

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.

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.

% 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.

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.

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.

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.

Go and Rust support shared libraries, even if on Go's case it is a WIP.

I don't get the impression Go is trying to support something like the common Linux use cases of shared libraries, and static will stay the default.

How come?

    $ go build -buildmode=c-shared

If you mean Go plugins, there is a proposal, anyone is free to implement it and do a PR.

Or then just wait until it gets eventually implemented by the core team.

I don't think Musl's lack of dlclose should cause any issues in real world use. The rationale is:

Either behavior conforms to POSIX, but only the musl behavior can satisfy the robustness conditions musl aims to provide. In particular:

Under glibc's approach, libraries not designed with dlclose in mind (which may not be the libraries directly loaded with dlopen, but rather their dependencies) may leave around references to themselves in such a way that removing them from the address space results in a crash (or worse) later on. This cannot happen under musl. Managing storage for thread-local objects is much more difficult if dlclose unloads libraries. If space is to be reserved in advance (needed to guarantee no late/unrecoverable failures), supporting unloading in dlclose seems to necessitate leaking TLS memory, which largely defeats the purpose of doing the unloading in the first place.

More people complain that statically linked binaries in Musl cannot call dlopen, which some things rely on.

What really bugs me about Musl's refusal to support dclose is that the rationale is that _other_ libraries don't suppose safe unloading, so Musl shouldn't let you try. I don't like my libc to be paternalistic.

If Windows can do leak-free TLS with FreeLibrary, Musl can too. I'm sick of hearing "X is impossible" when some other system has been doing X for decades.

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".