[skissane]

> The irony behind it is that one could argue that we are using UNIX wrong, because technically each program should run as its own user with its own groups.

I think one problem with the UNIX design is that UIDs/GIDs are a flat namespace, and commonly only 32-bits in size (even on 64-bit systems), when what is really needed to meet contemporary requirements is a hierarchy, either with an unlimited number of levels, or at least generous limits. Allow a user to create sub-uids (such as one per an application) and even sub-sub-uids (a web browser might create a sub-sub-uid for each website the user visits).

I think the Windows design of variable-length SIDs is in principle superior to the POSIX approach.

(Although, not necessarily in practice - it isn’t uncommon for Windows to make design decisions which in theory are superior to those of UNIX, but the practical implementation of them is full of warts, backward compatibility hacks, arbitrary limitations, and undocumented black boxes, which end up canceling out a lot of the theoretical advantage.)

[aragilar]

Have you heard of user namespaces? They would match all your requirements it seems.

[skissane]

I have but I don’t agree that they do.

From what I understand, Linux user namespaces require you to reserve a UID range for each namespace to be mapped to its parent. Since you only have 32-bits to play with, you are forced to map multiple UIDs in the child namespace to the same UID in the parent, while many security decisions are based on the root user namespace UID only. So this is actually a lot more limiting and inflexible than Windows-style variable length UIDs would be.

[ElectricalUnion]

> you are forced to map multiple UIDs in the child namespace to the same UID in the parent

Is that really a limit or just a thing for convenience?

I don't think besides 0 in namespace being the actual user in the actual system as a good convenience, that there is any "need" for pids per root-pid, and even if that happened it would save "root-pids".

And I find it unlikely as of now that a system would reach the 16-bit limits of running more that 65000 applications on a single system without hitting some other limit like /proc/sys/kernel/pid_max or /proc/sys/fs/file-max first.

[skissane]

> I don't think besides 0 in namespace being the actual user in the actual system as a good convenience, that there is any "need" for pids per root-pid, and even if that happened it would save "root-pids".

What happens with filesystems though? I would assume the filesystem is using the root user namespace. Which means if you have two different UIDs and they map to the same UID in the root namespace, they get collapsed into one for file ownership/etc. That seems a rather major limitation.

> And I find it unlikely as of now that a system would reach the 16-bit limits of running more that 65000 applications on a single system

With 32-bit identifiers, if you make each level 16-bit, you only have room for two levels. What if you have need for a third?

Also, you have to design a mapping from however many levels you need to the 32-bit flat namespace. A mapping which works well for one use case might turn out to be a problematic limitation in another. With variable-length UIDs there is no mapping to bother with.

[ElectricalUnion]

> Also, you have to design a mapping from however many levels you need to the 32-bit flat namespace. A mapping which works well for one use case might turn out to be a problematic limitation in another. With variable-length UIDs there is no mapping to bother with.

Yes, this thing is gonna make IPv4 NAT look like a nice thing in comparison.

Yes, it will probably mean horrible kludge mapping of isolated-applications to UIDs, but until you get to 2^15 ~ 2^16 count of isolated-applications it should work fine.

Yes, this will be on a per-system basis, the resulting filesystem will be only useable by your system, and no other system.

What I'm saying is that in theory the "filesystem" and the "UIDs are 32 bit" parts are mostly there. They're there from the multi-user-big-box days not being used (except by Android/Linux).

> With 32-bit identifiers, if you make each level 16-bit, you only have room for two levels. What if you have need for a third?

The main reason why 65536 UIDs and GIDs are often submapped to every user is because POSIX systems often have a hardcoded assumption that user nobody is UID 65534, GID 65534, and if you want to run nested POSIX systems under POSIX systems without too many changes, reserving that many UIDs and GIDs are required.

There's no good place for that universal "nobody" user anyways, and if you're rethinking how the UIDs and GID mechanisms relate to security, definitively no place for a universal nobody, so you might as well map only the required ammount of UIDs/GIDs per isolated-application.

That then leads to leaving unmapped UIDs unmapped on both host and isolated-applications.

Unless you're reaching the 2^15 ~ 2^16 count of isolated-applications then it should work fine.

Another option would be doing what Android (and supposedly flatpak) does: you should not be able to simply run whatever you want if you're a isolated-application. If as a isolated-application you need to run another isolated-application you need to invoke "the platform" via `am` or `flatpak-spawn` and use it to spawn another isolated-application.

> What happens with filesystems though? I would assume the filesystem is using the root user namespace. Which means if you have two different UIDs and they map to the same UID in the root namespace, they get collapsed into one for file ownership/etc. That seems a rather major limitation.

As far as I know most of what can be considered normal Linux filesystems (ext4, btrfs and I think xfs) support said 32-bit UIDs so you would not need to change filesystem code (and I believe changing and bugfixing filesystem code is always a scary proposition) to use a 32-bit mapping.

Nothing prevents you from using only UID/GIDs; there are other security mechanisms that could be used:

* present every isolated-applications with different overlay filesystems visible. So you can have several things read/write to the same places, but every one has it's own view of what is being read/written.

* displaying a entirely different file system for every isolated-application (bindfs as an example)

* every isolated-application has it's SELinux context (labels) or other forms of ACL applied to those files.

But I find this birthday attack scenario dubious, why would you "need" this UID overlap if the isolated-application don't overlap outside of both namespaces?

If they aren't the same isolated-application it's the wrong thing to do and a security risk.

If they do map to the same isolated-application with the same set of data then trusting everything will be fine is a reasonable assumption. It isn't getting any more data or more privileges from being at different UIDs or GIDs in different contexts.

[skissane]

You are really proving my point - multiple paragraphs of details and provisos, many of which would have been completely unnecessary if UIDs had been variable-length all along, as Windows SIDs are.