On 2021-04-21 13:14, Paul Moore wrote:
On Wed, Apr 21, 2021 at 1:03 PM Richard Guy Briggs
<rgb(a)redhat.com> wrote:
> On 2021-04-21 12:18, Paul Moore wrote:
> > On Wed, Apr 21, 2021 at 9:04 AM Greg Kroah-Hartman
> > <gregkh(a)linuxfoundation.org> wrote:
> > >
> > > This reverts commit 70c4cf17e445264453bc5323db3e50aa0ac9e81f.
> > >
> > > Commits from @umn.edu addresses have been found to be submitted in
"bad
> > > faith" to try to test the kernel community's ability to review
"known
> > > malicious" changes. The result of these submissions can be found in
a
> > > paper published at the 42nd IEEE Symposium on Security and Privacy
> > > entitled, "Open Source Insecurity: Stealthily Introducing
> > > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu
(University
> > > of Minnesota) and Kangjie Lu (University of Minnesota).
> > >
> > > Because of this, all submissions from this group must be reverted from
> > > the kernel tree and will need to be re-reviewed again to determine if
> > > they actually are a valid fix. Until that work is complete, remove this
> > > change to ensure that no problems are being introduced into the
> > > codebase.
> > >
> > > Cc: Wenwen Wang <wang6495(a)umn.edu>
> > > Cc: Richard Guy Briggs <rgb(a)redhat.com>
> > > Cc: Paul Moore <paul(a)paul-moore.com>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> > > ---
> > > kernel/auditfilter.c | 12 +++++-------
> > > 1 file changed, 5 insertions(+), 7 deletions(-)
> >
> > NACK on this revert. I've looked at the original patch again this
> > morning, and the original patch still looks correct and doesn't appear
> > to introduce any new faults to the best of my understanding.
>
> Agreed. Though on review, a much simpler fix to my original patch that
> caused this problem requiring this fix
> e85322d21cfebeac64f58a204e9adc0bc5c1e46f rgb 2014-10-02 ("audit: cull
redundancy in audit_rule_change")
> would have been the two-liner in the error path similar to the pattern
> in audit_data_to_entry() error path would have been:
>
> if (entry->rule.tree)
> audit_put_tree(entry->rule.tree); /* that's the temporary one
*/
Given the situation this morning I think it is best to limit
discussion on this thread to just the safety of the patches in
question and the necessity of the reverts Greg is proposing here. If
you have suggestions about how to clean-up or otherwise improve the
code relating to these patches I think it is better to have that
discussion in the appropriate subsystem list/forum/etc (as one would
do normally).
My original patch wasn't exploitable anyways since both cases that call
audit_rule_change() from audit_receive_msg() were covered, there was no
fallthrough, and for extra precaution there was a BUG_ON() added.
I'd say it was harmless, essentially a revert of my redundancy cull
patch. This seems to be the consensus about many of the patches in this
set.
Wenwen's address bounces, almost certainly because they moved to
cs.uga.edu in between April and July 2019.
paul moore
- RGB
--
Richard Guy Briggs <rgb(a)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