[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200519072451.GA3128@ircssh-2.c.rugged-nimbus-611.internal>
Date: Tue, 19 May 2020 07:24:52 +0000
From: Sargun Dhillon <sargun@...gun.me>
To: Jann Horn <jannh@...gle.com>
Cc: Kees Cook <keescook@...omium.org>,
Christian Brauner <christian.brauner@...ntu.com>,
Tycho Andersen <tycho@...ho.ws>,
Matt Denton <mpdenton@...gle.com>,
Chris Palmer <palmer@...gle.com>,
Jeffrey Vander Stoep <jeffv@...gle.com>,
Linux Containers <containers@...ts.linux-foundation.org>,
Linux API <linux-api@...r.kernel.org>,
kernel list <linux-kernel@...r.kernel.org>
Subject: Re: seccomp feature development
On Tue, May 19, 2020 at 12:39:39AM +0200, Jann Horn wrote:
> > For user_notif, I think we need something in and around these options:
> >
> > - make a new API that explicitly follows EA struct design
> > (and while read()/write() might be easier[4], I tend to agree with
> > Jann and we need to stick to ioctl(): as Tycho noted, "read/write is
> > for data". Though I wonder if read() could be used for the notifications,
> > which ARE data, and use ioctl() for the responses?)
>
> Just as a note: If we use read() there, we'll never be able to
> transfer things like FDs through that API.
>
Although there is no good reason for read being able to receive FDs, there is
precedence for recvmsg being able to do this. Either way, I do not think
it's a good idea to recv file descriptors, and instead file descriptors
should be fetched via the pidfd_getfd syscall.
Injection is more complicated, and for now, I believe that "writes" should
be done via ioctl, or in the future, something like sendmsg might work.
Powered by blists - more mailing lists