How about having some way to signal to D-Bus that a message is sensitive so should be stored in non-swappable memory?
> 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. Technically, I think it would be possible to intercept it using a BPF filter, but I'm pretty sure that is possible by inspecting the `write` syscalls with any kind of file descriptor (thus a problem for the proposal of passing a FD over the unix socket as well). But if a malicious actor has sufficient sufficient privileges to attach a BPF program, your whole system is compromised anyway. Thayne McCombs On Sun, Aug 30, 2020 at 10:05 AM Daiki Ueno <[email protected]> wrote: > > 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 _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
