open_by_handle_at and CVE-2020-35501

Steve Grubb sgrubb at redhat.com
Tue Mar 2 15:10:55 UTC 2021


Hello Paul,

On Thursday, February 25, 2021 5:28:11 PM EST Paul Moore wrote:
> On Thu, Feb 25, 2021 at 5:15 PM Steve Grubb <sgrubb at redhat.com> wrote:
> > Hello,
> > 
> > There was an announcement on the oss-security mail list a week ago:
> > 
> > https://seclists.org/oss-sec/2021/q1/155
> > 
> > regarding auditing of the open_by_handle_at system call ...
> 
> The *at() syscalls are a known issue with respect to audit; we have a
> few open GH issues related to the topic, the oldest appears to be the
> one below:
>
> * https://github.com/linux-audit/audit-kernel/issues/9
 
Yes, that is true. But this is a bit different because at least those *at 
functions get triggered by -F perm=xrwa. Should one or both of the syscalls 
be added to the filter? And name_to_handle_at() appears to be yet another 
kernel system call who's arg4 has something that is security relevant.

So, it looks like there are probably 3 work items: 1) add syscall(s) to the 
perm filter, 2) add an auxiliary record to grab the arg4 flags variable, 3) add 
to the list of functions that have *at path resolution issues.

-Steve


> > ... In any event, they are asking what upstream audit is going to do
> > about this?
> I recognize it sounds a bit trite here, but "patches are always
> welcome".  Basically someone needs to have the time and motivation to
> look into this and put forth some patches that we can discuss and
> iterate over.  The problem is that historically audit has attracted
> very few kernel developers outside the occasional development push by
> a distro preparing a OS release for a certification effort.  I was
> just lamenting this fact on a private mail thread with some other
> kernel developers a couple of weeks ago ...







More information about the Linux-audit mailing list