Hi,
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.
--
bauen1
https://dn42.bauen1.xyz/
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
