linux-kernel - Re: Why not make kdbus use CUSE?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <547DAEF3.1090106@gentoo.org>
Date:	Tue, 02 Dec 2014 07:22:11 -0500
From:	Richard Yao <ryao@...too.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: Why not make kdbus use CUSE?

Dear Greg,

I had hoped that I could avoid reading through the code for yet another
IPC mechanism when I asked why we needed kdbus at LinuxCon Europe. In
hindsight, I should have just checked out the code and read it instead
of asking. However, what I did instead was ask and then do some thinking
based on that, mean to send an email and then sent it long after I
should have.

Our conversation now has lead me to realize my mistake and I have tried
to rectify it. I now see that kdbus is hooking into kernel interface to
implement KDBUS_ITEM_PAYLOAD_MEMFD in a way that we could only achieve
from userspace with UNIX domain sockets. I imagine that we could avoid
putting this code into the kernel through a combination of libev,
libfuse, memfds and UNIX domain sockets.

A fallback path could be provided by using anonymous files on the FUSE
filesystem. This could probably by by the sender doing something like
the following:

void *buf;
int coookie;
char *name = strdup("/sys/fs/kdbus/tmp/XXXXXX");
int fd = mkstemp(name);
unlink(name);
buf = mmap(NULL, LENGTH, PROT_WRITE, MAP_SHARED, fd, 0);
// Do your writes here
cookie = ioctl(fd, SEAL);
close(fd);
munmap(buf);
// Send a message via a UNIX domain socket to the server with the
// cookie, plus whatever XXXXXX became and instructions on where to
// send the data. If the file had been closed before the message was
// received, the server should be able to say okay. Otherwise, it can //
send an error. The server would need to have a timer to handle the
// case where a process never actually sends a message with the cookie.

Assuming that this dance succeeds, the FUSE process could then make a
readonly file in itself, open it read only, unlink it, put the data into
the file and send the file descriptor via UNIX domain socket while
refusing further writes. If it has its own user/group, the file should
be safe from prying eyes.

This is not as good as a memfd and also suffers from the race that
O_TMPFILE was meant to close, but it should be able to function as a
decent fallback. This would preserve portability across not only
different versions of Linux, but also other POSIX systems. Keeping the
code in userspace would allow us to apply SELinux policies to it, which
is something that we would lose if it were go to into the kernel.

That said, it is still not clear to me that dbus must be inside the
kernel to be able to perform multicast and zero copy using memfd. Is
there something that I have missed that make this not the case?

Yours truly,
Richard Yao

Download attachment "signature.asc" of type "application/pgp-signature" (885 bytes)