Basically https://xkcd.com/1200/
because programs often to need to have part of the capabilities of the user which started them, just a very well controlled subset of them, something which the UNIX model can't properly represent (through you can hack it on-top of it)
There is also the problem of having by default "owner-user owner-group other" as permission sets for files and executable. This works if others is "other humans" (assuming it does work, security issues on shared systems based on that where not uncommon). But this works much less if you want to protect users from rogue programs because then "other" tends to be far to permissive.
But users can be in multiple groups. You can have files with groups like "graphics, audio" etc. and give access to the application users by adding that user to the relevant groups.
>IPC other than file based
This isn't UNIX model though, is it?
Though I agree with you. Given the current state of programs, file permissions aren't enough for isolation.
Picture: local DB client, remote DB server. Server can stream a file to the client for the client to write to disk. “On the same machine, as a different user” is just the trivial case of “over the network.”
Next problem will be sharing data between programs that legitimately need to do so; if I had an _emacs user that owned my source code, how do I make it non-painful for the _gcc user to read the source and write the resulting executables (which would end up in a directory owned by _emacs)? What about git, various preprocessors/generators, formatters, linters?
You'd have to step out of the traditional UNIX authn/authz model to effectively implement that. It's what various security-focussed OS's have been doing for a while anyway; e.g. OpenBSD implements unveil, which "hides" entire branches of the VFS tree. For example, if git has no business reading or writing files outside of the currently operated on repository, it can restrict itself very early in the process life - before proceeding to perform any of the "tricky" operations that are the common sources of security bugs.
The problem is not isolation or lack of it. The problem is that app require complex set of permissions for both users files and other apps.
App might want to send notification to notification daemon. But app should not be able to pretend to be another app, whether by name or icon. And good luck trying to stop malicious app from just making same/similar enough icon and spelling Firefox with some fancy UTF characters to go around it.
And that's pretty simple case! And already very hard on kernel/OS level to solve. Now look at files.
You might want to allow graphical editor to open any graphical file, regardless of location.
You might want to allow that same editor to only edit some of them.
But for browser, you might want to allow saving new files, but not editing/rewriting existing ones, because it is not an editor, and should have no business editing the files.
Or, allow browser tab browsing certain URL (say, web image editor) to modify the files, but not the image sharing webpage that only needs to read the file.
Now we not only have insanely granular permissions per app, the different actions from "app" (web browser is basically container for multiple applications at that point) also need different permissions.
It has nothing to do with "unix bad", or "unix wrong", to actually separate the applications without hardships on the user (like fucking with permissions every time one app needs to touch files of another app) is just very very hard
More likely, you want to temporarily give them permission to specific files you indicate. A graphical editor doesn’t have reason to read any file that the user didn’t explicitly picked for editing/viewing.
That’s how Mac OS works nowadays (possibly except for the ‘temporarily’; I don’t know the details): applications can only open files that the user selected in the system file open dialog. That runs in a separate process and opens up an app’s sandbox to allow access to the file the user selected.
In addition to sending data, processes may send file descriptors across a Unix domain socket connection using the sendmsg() and recvmsg() system calls. This allows the sending processes to grant the receiving process access to a file descriptor for which the receiving process otherwise does not have access.[2][3] This can be used to implement a rudimentary form of capability-based security.
https://linux.die.net/man/7/unix
SCM_RIGHTS
Send or receive a set of open file descriptors from another process. The data
portion contains an integer array of the file descriptors. The passed file
descriptors behave as though they have been created with dup(2).
Other nifty thing with UNIX sockets is that you can just... read which user sent the message and as it is kernel adding that metadata you're 100% sure it came from that user. That's for example how you can set postgresql so say a certain user in the system can log as themselves without having to have a password.
> The FileChooser portal allows sandboxed applications to ask the user for access to files outside the sandbox. The portal backend will present the user with a file chooser dialog.
> The selected files will be made accessible to the application via the document portal, and the returned URI will point into the document portal fuse filesystem in /run/user/$UID/doc/.
[1]: https://docs.flatpak.org/en/latest/portal-api-reference.html...
I mean, the correct approach would be to have groups even for specific network protocols because capabilities are not enough to sandbox a binary correctly, and the network group is pretty much pointless.
And then there's icmp, which brings us to the ping binary which on lazy distributions still has an SUID flag set, as well as glibc which still allows LD_PRELOAD by default because it is intended functionality from the perspective of its developers.
Most of these privilege escalation exploits can be mitigated, if users and groups and capabilities are managed correctly.
In practice I probably would recommend to use the systemd seccomp sandboxes because most of these quirks have been abstracted away there and are configurable in the service files - like file/folder access, user/group randomization, chrooting, capabilities etc.
The problem with this approach is that, of course, it really doesn’t scale easily. Eventually you need multi tenant, and eventually we ended just pushing everything into the database, using row level security and tenant IDs. It worked great but felt more fragile (eg, you can disable RLS)
I’m not an OS expert by any means, but I think ultimately the problem is that we’re using one operating system model for two orthogonal use cases.
I feel like need a well-defined client model - “one user with multiple apps” and a well-defined server model - “one app with multiple users”. But it’s not clear to me how the OS can help with the latter, since it’s going to be domain specific. Maybe Postgres’ model is the right answer after all.
I tried to use Apparmor and SELinux, but how policies work is beyond me. Snap's sandboxing seems to be the closest thing to user-friendly sandboxing, but it's still not that user-friendly.
In practice I don't have the time to debug every shitty little app armor integration for weeks. I lost days to libvirt-manager because its app armor support was enforced and not even half assed. Some configuration paths would automatically get whitelisted in its auto generated app armor profiles, others would just get you a file not found until you whitelisted them manually. The process responsible for generating these profiles would also silently kill itself if it encountered a path that was on its internal ban list, have fun debugging that when you do things like using an alternative bios rom, which by default are all stored in a blocked path.
Apparmor feels like security through obscurity, unless you already know that you are dealing with app armor fuckery there is no chance in hell that you will be able to run your application and not being able to run anything is the holy grail of security.
I used libvirt with apparmor and was pretty satisfied with it
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 the requirements of today’s systems is a hierarchical system, 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 and arbitrary limitations, which ends up canceling out a lot of those theoretical advantages.)
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.
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.
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.
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.
How big of a change is it? If you are, say, a Linux terminal native can you just pick up and run?
Doing so has proved hard and slow so far, and Spectrum hasn't had a usable release for the masses yet.
As a qubes user, I think this is interesting but it definitely does not sound more usable.
There's some learning curve for features which exist for valid reasons, especially around communicating between domains. For instance, copy-and-paste between qubes requires extra steps. Plugging in a USB keyboard or mouse doesn't just work - you have to authorize it first (just click the OK button using a PS/2 mouse, or laptop's touchpad). You have to learn how to move files between qubes. USB drives, cameras, and microphones aren't globally available to all applications - you have to attach them to a qube first. You can install software using apt-get inside a qube, but it won't persist across reboots - you have to update the OS template.
I want those extra steps and complications - they are features, not a bugs! The first few days you'll be looking things up in the FAQ. After that it's pretty easy.
There are a few sore points that don't go away. You don't get GPU acceleration in your web browser, so rendering is slower. Gaming is not an option. Your application qubes live behind a firewall qube, so things that require network broadcast like Chromecast won't work. Those are fine for me but not for everyone.
> You can install software using apt-get inside a qube, but it won't persist across reboots - you have to update the OS template.
> I want those extra steps and complications
Is it wrong of me to say that enabling persistence, with snapshots, on a qube should be a single toggle?
Yes, if you only have a USB keyboard, it will work. Manual creation of a USB VM then is recommended for security: https://www.qubes-os.org/doc/usb-qubes/
> Is it wrong of me to say that enabling persistence, with snapshots, on a qube should be a single toggle?
Of course you are right. TemplateVMs provide /root partition to AppVMs and software should be installed normally to the former. At every AppVM reboot, their /root is reset to the one from TemplateVM. Ordinary, persistent VMs are also possible. Details: https://www.qubes-os.org/doc/getting-started/
Am I wrong about that?
Upd: yes, also there is no GPU acceleration in the VMs.
Of course, I’m not being targeted by the state so my threat model is much lower.
The idea you can really secure you data on a PC connected to Internet from the most powerful actors is very naive.
> Never lead to escapes
Escape is the highest form of security failure. I'm talking about data access and exfiltration.
Do you store all your important data on a VM with no internet access? Even Qubes users don't, it's hard to work with. Then it's Firefox/ kernel bug away from being accessed remotely.
XSAs are publicly known vulnerabilities discovered by someone who wanted to make it public and later were published by the Xen developers. There very probably are publicly unknown vulnerabilities, both in HW and Xen, discovered/created by people who want to profit from exploiting them. There are whole teams focused on this kind of work, payed by states and criminal-enablers like NSO.
> What is restrictive about Qubes?
No GPU acceleration for video in a VM, legacy OS on dom0. Xen development in support of modern CPUs has fallen behind, didn't even boot on modern Zen X570 platform last time I tried, dysfunctional nested virtualization, using KVM from Linux does not work, can't run Android Studio with phone emulator.
Did you just call Snowden a "twitter persona"? You're not serious. Not sure if I should reply further after that.
> Do you store all your important data on a VM with no internet access? Even Qubes users don't
Yes, I do. And I'm a Qubes user. There are many more users like me on their forums. This is much more convenient than you think: you can easily and securely copy/paste passwords wherever needed.
What about that audit?
If you keep all your important data off internet, that's good for you, and Qubes helps.
It's not wheel's fault, and so substituting root group for wheel was nothing more than a special snowflake move by someone who thought the sysadmins were holding back and the "enemy".
actually if you think about it, lots of machines you OWN nowadays don't give you root access.
For example you can't get access at the actual filesystem on your iphone without a jailbreak.
Why have multiple different unix users if all have the same power of the root user? They aren't isolated from each other, they aren't less powerful than root. So why not just use the already existing single root account?
Though I suppose, with further thought, it’s not significantly worse than having them in sudoers, in that particular respect.
Sudoing into root from lowuser account is in some scenarios potentially more dangerous than just using both accounts separately, as the user who uses root regularly/very often gets accustomed to the fact his commands are powerful and can screw his system, so mistakes almost never happen. While sudoing all the time creates a false sense of security and the user is more likely to run harmful command with sudo.
> To prevent remote root exploits, the Amazon Linux AMI does not allow remote root login via SSH[...] By default, the only account that can log in remotely via SSH is ec2-user. The ec2-user has sudo privileges.
Can someone please explain how this makes any sense for better security. It seems to be just a security theater.
Second, it can still be useful for bookkeeping.
Back in the day, university campus networks popularized a "cluster" approach of logging in to specific machines whereby hosts followed the pattern: $(uname)[0-9]{2}. You would soon setup authorized_keys and a script that would check the load of all machines by iterating ssh. The same home directory would be shared to all machines, regardless of OS, so portability of shells scripts and POSIX/C code was necessary.
Back in the day, it was about multiple OS users on one big machine, maintained by a university or a corporation.
Now I'm the only human user of my several machines. I have more than one interactive user account on some of them. I put these accounts to the wheel group, to avoid ever using a root password. (Void Linux has it pre-configured in /etc/sudoers.)