| > With UNIX domain sockets it is absolutely possible to determine the PID of the process that you are talking to and use pidfd to validate where it is coming from. Validate what? You're just moving the responsibility to whatever answer you give here. If you say "validate the exec name is firefox-bin" then the next person who comes in will say "I hate $your_new_fangled_ipc, you can make it dump all your secrets by renaming your exec to firefox-bin". (This is just an example). > And how exactly does the app container service store something encrypted securely on disk? That's literally the point of a secrets service on a modern desktop. The more I think of it, the less sense this makes. If you already have a system where applications cannot read each other's data, what is the point of secret service? What is the security advantage? If you want to encrypt with TPM, fingerprint, or anything else, that's encryption, which is separate from storage (you can encrypt the password with say a PCR but the application gets to store the encrypted password in any way they want). Password encryption in the desktop keyrings are for the situation for when every application can read each other's data files easily (again, as in the desktop). In which case, it may make sense to use encryption so that such data is not (trivially) accessible from any other application (otherwise https://developer.pidgin.im/wiki/PlainTextPasswords applies) . If your applications are already running sandboxed, a keyring sounds to me like useless complexity? Just make each application store its data into its sandbox. What's the threat vector here, that super-user-that-can-escape-sandbox can read into the sandboxes and extract the password? > You can actually do decent code generation for it without having to have like 5 competing ways to extend the XML to add basic things like struct member annotations (and then have things like Qt's own DBus code generator unable to actually handle any real DBus service definitions. Try throwing the systemd one at it, doesn't fucking work. The code doesn't even compile.) Yes sure, another problem resulting from the lack of standarization. But my point was -- standarize (write a spec), instead of adding more to the problem by creating yet another competing standard which will obviously NOT solve the problem of lack of standarization. |
I'm genuinely kind of surprised people are tripping up on this. Obviously, what you validate is up to you, but you can. Why stick to just the base name? Why not the absolute path? Bonus points for ensuring it's a root owned file in root owned paths. You could special case Flatpak, or specific mount points, or go crazy and add signatures to binaries if you want. The policy would obviously vary strongly depending on the system, but if you were dealing with a secure booted system with dm-verity, or something similar, well then this mechanism should be fairly watertight. It's not really the end of the world if there are systems with different security characteristics here.
You can really get creative.
(It is worth noting, though, that this could be bypassed various ways trivially, like with LD_PRELOAD, so to be a true security boundary it would need more thought. Still, this could definitely be made improved numerous ways.)
> The more I think of it, the less sense this makes. If you already have a system where applications cannot read each other's data, what is the point of secret service? What is the security advantage?
Well, the obvious initial benefit is the same thing that DPAPI has had for ages, which is that it's encrypted on-disk. Of course that's good because it minimizes the number of components that will see the raw secret and ensures that even other privileged processes can't just read user secrets. Defense in depth suggests that it is a feature, not a problem, if multiple security mechanisms overlap. Bonus points if they'd both be sufficient enough to prevent attacks on their own.
An additional case worth considering is when the home folder is stored elsewhere over a network filesystem, as in some more enterprise use cases.
> If you want to encrypt with TPM, fingerprint, or anything else, that's encryption, which is separate from storage (you can encrypt the password with say a PCR but the application gets to store the encrypted password in any way they want).
It would be ill-advised to have each application deal with how to encrypt user data. They can store keymatter in the keyring instead of the data itself if they want to handle storage themselves. (I'm pretty sure this is actually being done in some use cases.)
> Password encryption in the desktop keyrings are for the situation for when every application can read each other's data files easily (again, as in the desktop). In which case, it may make sense to use encryption so that such data is not (trivially) accessible from any other application (otherwise https://developer.pidgin.im/wiki/PlainTextPasswords applies) .
That page exists to explain why they don't bother, but part of that is that there just isn't an option. If there actually was an option, well, it would be different.
> If your applications are already running sandboxed, a keyring sounds to me like useless complexity? Just make each application store its data into its sandbox. What's the threat vector here, that super-user-that-can-escape-sandbox can read into the sandboxes and extract the password?
The threat vector is whatever you want it to be, there are plenty of things this could be useful for. The reality is that Linux desktops do not run all programs under a sandbox and we're not really headed in a direction where we will do that, either. This is probably in part because on Linux most of the programs you run are inherently somewhat vetted by your distribution and considered "trusted" (even if they are subject to MAC like SELinux or AppArmor, like in SuSE) so adding a sandbox feels somewhat superfluous and may be inconvenient (i.e. file access in Bottles is a good example.) But, even in a world where all desktop apps are running in bubblewrap, it's still nice to have extra layers of defense that compliment each other. And even if something or someone does manage to access your decrypted home folder data, it's nice if the most sensitive bits are protected.
> Yes sure, another problem resulting from the lack of standarization. But my point was -- standarize (write a spec), instead of adding more to the problem by creating yet another competing standard which will obviously NOT solve the problem of lack of standarization.
The reason why people don't bother doing this (in my estimation) is because DBus is demoralizing to work on. DBus isn't a mess because of one or a couple of issues, it is a mess because from the ground up, it was and is riddled with many, many shortcomings.
And therein lies the rub: if you would like to have influence in how these problems get solved, you are more than welcome to go try to improve the DBus situation yourself. You don't have to, of course, but if you're not interested in contributing to solving this problem, I don't see why anyone should be all that concerned about your opinion on how it should be fixed.