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