Re: RFC: deprecating crypto usage in secret-service

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