* open_by_handle_at and CVE-2020-35501
@ 2021-02-25 22:14 Steve Grubb
2021-02-25 22:28 ` Paul Moore
0 siblings, 1 reply; 3+ messages in thread
From: Steve Grubb @ 2021-02-25 22:14 UTC (permalink / raw)
To: linux-audit
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. They are using a
rule like this:
-a always,exit -F path=/path/to/file -F perm=wr
and expecting that we have an audit record when opened using the
name_to_handle_at/open_by_handle_at syscall pair.
I run a study of my system by adding audit rules for each of the syscalls.
What I found was that the name_to_handle_at seems to be used by systemd and
it only passes a relative file name. This makes the audit event next to
useless.
And interestingly I have no events for open_by_handle_at in spite of systemd
preparing to use it. So, I don't have any idea what the audit event would
look like.
In any event, they are asking what upstream audit is going to do about this?
In looking into open_by_handle_at, I found that it was used in an exploit
against docker some time ago where it was possible to bruteforce the handle.
Of cource you need CAP_DAC_READ_SEARCH to call it.
https://www.programmersought.com/article/54607139735/
I think we should do something, not sure what. Simply adding the syscall to
the open perms machinery will get an event, but probably nothing usable. You
could at least see who is doing it and with what program.
In the meantime, people can use the syscall rules to audit for any occurance.
I think the default rules do include it.
Cheers,
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: open_by_handle_at and CVE-2020-35501
2021-02-25 22:14 open_by_handle_at and CVE-2020-35501 Steve Grubb
@ 2021-02-25 22:28 ` Paul Moore
2021-03-02 15:10 ` Steve Grubb
0 siblings, 1 reply; 3+ messages in thread
From: Paul Moore @ 2021-02-25 22:28 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
On Thu, Feb 25, 2021 at 5:15 PM Steve Grubb <sgrubb@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
> ... 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 ...
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: open_by_handle_at and CVE-2020-35501
2021-02-25 22:28 ` Paul Moore
@ 2021-03-02 15:10 ` Steve Grubb
0 siblings, 0 replies; 3+ messages in thread
From: Steve Grubb @ 2021-03-02 15:10 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
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@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 ...
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-03-02 15:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-25 22:14 open_by_handle_at and CVE-2020-35501 Steve Grubb
2021-02-25 22:28 ` Paul Moore
2021-03-02 15:10 ` Steve Grubb
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).