> Because you do not get it: this is not Android. There is no fixed UIDs.
Uhhh... I didn't say anything about fixed UIDs.
> There is no fixed absolute paths.
There is if your distribution says there is.
> The binaries are not always root-owned.
They are if your distribution says they are.
> There is no central signing authority (thank god!).
I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Yeah, fine, the binaries themselves lack a signature attached to them, but if they can sign the packages they sure as shit can sign an ELF binary provided a mechanism to do so.
But anyway. There is if your distribution has one.
> You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.
There is if your distribution makes there a way to validate something from the PID.
The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not. That's how desktop Linux really works. You're not forced into any specific policy, but that doesn't mean policy is pointless. There are plenty of people running Secure Boot and Lockdown mode too, it's not automatically pointless.
Immutable distros exist right now.
> Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.
This doesn't fix anything. Like half of the shit I have installed via Flatpak needs direct session bus access anyways.
> I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.
Do you know what "principle of least privilege" is? My printer driver is "privileged" but that doesn't mean it needs to be able to capture my screen and read all of my passwords. It would be much better if Linux was capabilities-based. Hey, maybe someone should attempt to implement an RPC framework that does that.
> What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.
That's because your thought process is going in one direction and not taking any new input. You've been running the same exact narrative the entire time. Yes it's true that if you assume the system must be watertight-secure under all circumstances in every single existing desktop Linux setup, then it can't be done. But that's irrelevant. The question is could it be used as a primitive to construct a more secure Linux desktop, and the answer is a resounding, "Well, duh".
Again. Immutable distros exist right now. They already start with many of the necessary security properties, you mostly need to find a way to deal with insecure linker behavior.
> You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?
sigh
You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data. Sometimes it is also used to share data between different programs, but I don't even think that is most of the time.
Checking my kdewallet, I can see the following applications:
- KRDC
- Remmina
- KRDP
- Chromium
- krfb
- xdg-desktop-portal
... And then the "Passwords" folder, which contains the passwords saved for e.g. SMB shares.
Of those... I think the only one that is ever even accessed by anything else is the Chromium one possibly, for browser migration? The rest are only ever stored for themselves. So yes, the wallet is being used as a dumb key-value store. One that is encrypted automatically without needing the application to do key management.
> Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).
Not cryptography itself, but key management. Although you can do key management by proxy by providing a cryptography API too, sort of how using the TPM for this purpose works. That is the approach taken by DPAPI on Windows, in contrast to the keyring approach taken on Linux and macOS (where you get a key value store from the app perspective and do neither cryptography nor key management in the app.)
And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.
> This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.
It's not circular at all... man, you really need to learn how to read. What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd. There is no world in which that is logically worth the effort.
> I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.
Well, it's at least good that you also recognize the value I place in your opinion at this point, so that we can agree on at least one thing.
But honestly outside of being a smarmy dickhead (sorry, but I never have any reservations firing back when someone is doing it to me) the point I'm making is that if you want DBus to get fixed instead, well, good for you. I would like a Threadripper for Christmas, while we're at it. Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.
(And it really doesn't matter to me what Windows or macOS does here honestly. I care about the Linux desktop, not how it compares to whatever crapware Microsoft and Apple are pushing. They haven't really meaningfully improved the desktop in the past 10 years anyways.)
You STILL do not get it: This Is Not Android. Even ignoring that most distributions are not going to do what you want them to do (that's the entire point), the distribution has zero power over what users do. Firefox _is_ still distributed as a simple tarball that you can unpack in your home directory and run.
If flatpak or your distribution suddenly start requiring _root_ so that users can run programs that do not really require root, this not only would be a net security degradation rather than improvement, it would prevent me from using that distribution altogether. And yes, these programs need access to the desktop, the theming service, accessibility, input management, etc. for obvious reasons.
This is why even the current method is superior to anything you are proposing here, and the SCM_CREDENTIALS stuff just does not rightly fit in the Linux desktop model.
> I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Ye
ANY that is source based, for example. Actually, I have not used _any_ distribution that would sign even packages in ages, much less binaries.
Go and check how much love you are going to get if you start asking around for people to sign their own binaries to run them in their machine, to implement a sandboxing mechanism that there are a million other, way less intrusive ways to implement.
> The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not.
It doesn't really matter. A user is then going to mount a $HOME through NFS into a serverbox and expect to run graphical applications from there.
> Like half of the shit I have installed via Flatpak needs direct session bus access anyways.
A problem I fully acknowledge. But how would _any_ D-Bus replacement fix that? You'd need to replace _all_ IPC servers to offer some form of "no longer trust the clients" API (more or less what Wayland supposedly did to X11), and this is a decades-long task _at best_. A different IPC system doesn't really help, and may even delay this!.
> Do you know what "principle of least privilege" is? M
Irrelevant when my point is that I want _my_ privileged process to manage the password keyring itself.
> You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data.
The entire raison-d'être for KWallet was to store AND SHARE passwords amongst programs, as a glorified netrc replacement. The "secure" storage part comes later, and few if any people enable the auto-locking mechanism which is the only thing that can offer any sensible protection to it. As you are aware of, KWallet and gnome-keyring have never provided any level of actual secure storage.
> And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.
why do you make this distinction for secrets, and not for literally the rest of extremely critical private data that the app store? Why would user want to backup the passwords but not the private app documents?
"You want a private data storage that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap such private data; [other] individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key."
I mean, from your description, you want KWallet to provide protection so that say the mail client cannot access the browser passwords (something I already disagree with). But don't you also want, in this containerized world, for the mail client to NOT be able to read your browser's history, for example? If you already provide secure, containerized storage for apps, I fail to see any specific distinction between "private app data" and "private app secret" (I would still make the distinction if it was "shared"). You'd want your history to be protected (from other programs) as much as any website password.
I do not even know why you bring up the word "regulation" in here.
> What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd
This is not a reading problem: you are still saying that it is a mess because it is a mess. If you want to break the circular reasoning, you have to introduce an actual reason into the loop.
> Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.
You keep framing this as if we were not improving the Linux desktop too, which just shows your bias.
My point: Just don't act like it's weird when the actions only result in a LARGER and more explosive trainwreck rather than an improvement.
Uhhh... I didn't say anything about fixed UIDs.
> There is no fixed absolute paths.
There is if your distribution says there is.
> The binaries are not always root-owned.
They are if your distribution says they are.
> There is no central signing authority (thank god!).
I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Yeah, fine, the binaries themselves lack a signature attached to them, but if they can sign the packages they sure as shit can sign an ELF binary provided a mechanism to do so.
But anyway. There is if your distribution has one.
> You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.
There is if your distribution makes there a way to validate something from the PID.
The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not. That's how desktop Linux really works. You're not forced into any specific policy, but that doesn't mean policy is pointless. There are plenty of people running Secure Boot and Lockdown mode too, it's not automatically pointless.
Immutable distros exist right now.
> Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.
This doesn't fix anything. Like half of the shit I have installed via Flatpak needs direct session bus access anyways.
> I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.
Do you know what "principle of least privilege" is? My printer driver is "privileged" but that doesn't mean it needs to be able to capture my screen and read all of my passwords. It would be much better if Linux was capabilities-based. Hey, maybe someone should attempt to implement an RPC framework that does that.
> What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.
That's because your thought process is going in one direction and not taking any new input. You've been running the same exact narrative the entire time. Yes it's true that if you assume the system must be watertight-secure under all circumstances in every single existing desktop Linux setup, then it can't be done. But that's irrelevant. The question is could it be used as a primitive to construct a more secure Linux desktop, and the answer is a resounding, "Well, duh".
Again. Immutable distros exist right now. They already start with many of the necessary security properties, you mostly need to find a way to deal with insecure linker behavior.
> You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?
sigh
You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data. Sometimes it is also used to share data between different programs, but I don't even think that is most of the time.
Checking my kdewallet, I can see the following applications:
- KRDC
- Remmina
- KRDP
- Chromium
- krfb
- xdg-desktop-portal
... And then the "Passwords" folder, which contains the passwords saved for e.g. SMB shares.
Of those... I think the only one that is ever even accessed by anything else is the Chromium one possibly, for browser migration? The rest are only ever stored for themselves. So yes, the wallet is being used as a dumb key-value store. One that is encrypted automatically without needing the application to do key management.
> Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).
Not cryptography itself, but key management. Although you can do key management by proxy by providing a cryptography API too, sort of how using the TPM for this purpose works. That is the approach taken by DPAPI on Windows, in contrast to the keyring approach taken on Linux and macOS (where you get a key value store from the app perspective and do neither cryptography nor key management in the app.)
And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.
> This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.
It's not circular at all... man, you really need to learn how to read. What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd. There is no world in which that is logically worth the effort.
> I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.
Well, it's at least good that you also recognize the value I place in your opinion at this point, so that we can agree on at least one thing.
But honestly outside of being a smarmy dickhead (sorry, but I never have any reservations firing back when someone is doing it to me) the point I'm making is that if you want DBus to get fixed instead, well, good for you. I would like a Threadripper for Christmas, while we're at it. Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.
(And it really doesn't matter to me what Windows or macOS does here honestly. I care about the Linux desktop, not how it compares to whatever crapware Microsoft and Apple are pushing. They haven't really meaningfully improved the desktop in the past 10 years anyways.)