linux-kernel - Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket

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]

Message-ID: <20141021164109.GL26201@madcap2.tricolour.ca>
Date:	Tue, 21 Oct 2014 12:41:09 -0400
From:	Richard Guy Briggs <rgb@...hat.com>
To:	Steve Grubb <sgrubb@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-audit@...hat.com,
	ebiederm@...ssion.com, serge@...lyn.com,
	Eric Paris <eparis@...hat.com>
Subject: Re: [RFC][PATCH] audit: log join and part events to the read-only
 multicast log socket

On 14/10/07, Richard Guy Briggs wrote:
> On 14/10/07, Eric Paris wrote:
> > On Tue, 2014-10-07 at 14:23 -0400, Richard Guy Briggs wrote:
> > > Log the event when a client attempts to connect to the netlink audit multicast
> > > socket, requiring CAP_AUDIT_READ capability, binding to the AUDIT_NLGRP_READLOG
> > > group.  Log the disconnect too.

> > super crazy yuck.  audit_log_task_info() ??
> 
> I agree.  I already suggested that a while ago.  I'd love to.  sgrubb
> thinks it dumps way too much info.  We still haven't got a definitive
> answer about what is enough and what is too much info for any given type
> of record.
> 
> I also thought of moving audit_log_task() from auditsc.c to audit.c
> and using that.  For that matter, both audit_log_task() and
> audit_log_task_info() could use audit_log_session_info(), but they are
> in slightly different order of keywords which will upset sgrubb's
> parser.
> 
> What to do?
> 
> Another paragraph I'd like to see added to
> 	http://people.redhat.com/sgrubb/audit/audit-parse.txt
> would be a "canonical order" of keywords.  However, that discussion went
> nowhere.  Would it be reasonable to suggest only two possible orders
> instead of the almost infinite iterations possible and declare a
> standard order of keywords and gradually move to it?

Steve,

Can we agree to *two* orders (instead of the full set of iterations) for
these keywords so that we can start to sort things in a canonical order?
This random order per type of audit log message is chaos.

> - RGB

- RGB

--
Richard Guy Briggs <rbriggs@...hat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/