linux-kernel - Re: [PATCH v4 4/4] fanotify,audit: deliver fan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 15 Aug 2022 17:15:54 -0400
From:   Steve Grubb <sgrubb@...hat.com>
To:     Richard Guy Briggs <rgb@...hat.com>
Cc:     Linux-Audit Mailing List <linux-audit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org, Paul Moore <paul@...l-moore.com>,
        Eric Paris <eparis@...isplace.org>, Jan Kara <jack@...e.cz>,
        Amir Goldstein <amir73il@...il.com>
Subject: Re: [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string

Hello Richard,

On Wednesday, August 10, 2022 10:23:49 PM EDT Richard Guy Briggs wrote:
> > I compiled a new kernel and run old user space on this. The above event
> > is
> > exactly what I see in my audit logs. Why the fan_info=3F? I really would
> > have expected 0. What if the actual rule number was 63? I think this
> > will work better to leave everything 0 with old user space.
> 
> Well, if it is to be consistently hex encoded, that corresponds to "?"

I suppose this OK.

> if it is to be interpreted as a string.  Since the fan_type is 0,
> fan_info would be invalid, so a value of 0 would be entirely reasonable,
> hex encoded to fan_info=00.  It could also be hex encoded to the string
> "(none)".  If you wanted "0" for fan_type=FAN_RESPONSE_INFO_AUDIT_RULE,
> that would be fan_info=30 if it were interpreted as a string, or
> arguably 3F for an integer of rule (decimal) 63.  Ultimately, fan_type
> should determine how fan_info's hex encoded value should be interpreted.
> 
> But ultimately, the point of this patch is to hex encode the fan_info
> field value.

Just one last update, I have been able to test the patches with the user 
space application and it appears to be working from the PoV of what is sent 
is what's in the audit logs. I'm not sure how picky old kernels are wrt the 
size of what's sent. But an unpatched 5.19 kernel seems to accept the larger 
size response and do the right thing.

-Steve