Thank you for the comments. "Thomas Kluyver" <[email protected]> writes:
> It's not clear to me that using file descriptors fulfils the same goal > as the encryption mechanism. The secret service spec [1] suggests that > the goal is for swappable memory to contain encrypted (rather than > plaintext) secrets. Passing the secret over a separate channel > wouldn't seem to do that - though I guess there would be one fewer > copy of the data, as the bus daemon doesn't see it. I think both endpoints (gnome-keyring and libsecret, for example) already have protection against that using mlock, while as you say, with the current "plain" mechanism, the D-Bus daemon can leak the data into the swap because it has no knowledge about which part of the traffic should be considered as confidential. > Approaching it from another angle, what threat would this protect > against which could otherwise steal data from D-Bus over unix sockets? > I think it would have to be something which can listen to another > connection but not connect itself, but I don't know of a scenario > where that's possible. To my understanding, once the data has been written to a file descriptor, it is copied into the kernel space, and cannot leak into swappable memory until it is read by the user space program. As D-Bus already provides a way to transfer FD between the peers, we don't need to care about listen or connect. > Passing file descriptors is only possible over Unix sockets, as far as > I know, so it wouldn't be usable on Windows, though I don't know how > big a concern that is. I guess we probably should check how Unix sockets are implemented in WSL at least. Regards, -- Daiki Ueno _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
