null pointer dereference regression in 5.7

[Richard Guy Briggs]

On 2020-07-23 15:10, bauen1 wrote:
> On 7/23/20 2:58 PM, Dominick Grift wrote:
> > On 7/23/20 2:47 PM, Richard Guy Briggs wrote:
> >> On 2020-07-22 22:04, Dominick Grift wrote:
> >>> On 7/22/20 9:47 PM, Richard Guy Briggs wrote:
> >>>> On 2020-07-18 20:56, Dominick Grift wrote:
> >>>>> On 7/18/20 8:40 PM, bauen1 wrote:
> >>>>>> Hi,
> >>>>>> After upgrading from linux 5.6 to 5.7 on my debian machines with selinux I've started seeing this null pointer dereference in the audit system. I've included shortened logs for 5.6 without the error and from 5.7 with the error from my laptop. I've also seen it happen in a VM and a server, but don't have the logs anymore. Grift was able to reproduced (presumably) the same issue on fedora with 5.8-rc4.
> >>>>>>
> >>>>>> Steps to reproduce:
> >>>>>> Write an selinux policy with a domain for systemd-user-runtime-dir and audit all permissions of the dir class. E.g. `(auditallow systemd_user_runtime_dir_t all_types (dir (all)))`
> >>>>>> Switch to permissive mode.
> >>>>>> Create a new user and login, log out and wait a few seconds for systemd to stop user-runtime-dir@<uid>.service
> >>>>>
> >>>>> This should be a reproducer:
> >>>>>
> >>>>> echo "(auditallow systemd_logind_t file_type (dir (all)))" > mytest.cil
> >>>>> && sudo semodule -i mytest.cil
> >>>>> reboot
> >>>>
> >>>> Is this recipe complete?  Is permissive mode needed?  Is the user
> >>>> create/login/logout needed?
> >>>
> >>> Are you saying you can't reproduce it?
> >>
> >> Not yet.  This run caused a queue overflow but no pointer dereference.
> >>
> >>> It *should* be complete yes. with kernel 5.7/5.8 it should oops when you
> >>> reboot.
> >>
> >> I don't understand what this test does to cause an AVC.  I assume we
> >> want the smiplest test that produces the smallest amount of output but
> >> certain to trigger the event.
> > 
> > Yes that is the idea, my test was a bit broader but i based this
> > conversion of the test on bauen1's test which is a bit more narrow ( i
> > think he managed to narrow it down a bit). Maybe this test is a bit to
> > narrow and a bit broader version triggers i>>
> >> Since this test is in place on reboot, how do I remove this test for
> >> subsequent reboots?
> >>
> > 
> > You would boot with selinux=0 and then run as root `semodule -n -r
> > mytest' to unload the offending mytest module without trying to reload.
> > 
> > then reboot with selinux enforcing/permissive (you might end up with
> > some mis and/or unlabeled files)
> > 
> >>> I will admit though that I adjusted the reproducer a little bit in an
> >>> attempt to make it fit fedora.
> >>
> >> I'm running the test on f32.  I have 5 kernels that should blow up and
> >> two that might be fine with the ghak96 LSM_AUDIT_DATA_* audit_getpwd() fix.
> >>
> >>> So if it doesnt oops for you and if you use 5.7/5.8 then maybe the
> >>> reproducer got mangled in the conversion.
> >>
> >> Can you explain the mechanism and the conversion?
> > 
> > I use my own selinux security policy with different identifiers, so to
> > make my test work on Fedora I figured I just needed to translate the
> > identifiers applicable in my policy to the identifiers applicable in Fedora.
> > 
> > Basically it boils down to this:
> > The event was triggered by systemd-user-runtime-dir (which in fedora is
> > associated with type identifier systemd_logind_t) on particual (i
> > suspect) directory operations (like i guess "traverse"), when the event
> > is logged even if its granted. So I tried to express that scenario using
> > fedora identifiers rather than the ones I use.
> > 
> 
> The actual permission checks that cause the audit event are probably (dir (search remove_name rmdir)), in refpolicy syntax `dir { search remove_name rmdir };`.
> It doesn't really matter how the audit event is generated (permissive mode and denying access or enforcing and auditing allows).
> I've reproduced it with systemd version 245.6-1 on a debian system with gnupg installed. Having something like gnupg installed is important as it creates its own directory under /run/user/uid that is accessed by systemd-user-runtime-dir after log out.

Ok, I've reproduced it on the kernels that have that ghak120 patch and
the two newer kernels with the ghak96 patch in addition do not have the
problem, so the upstream audit/next is safe from your reproducer.

That still leaves auditing the code for other potential dangers.

> bauen1

- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635