netdev - Re: [PATCH] XFRM: RFC4303 compliant auditing

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: <200712071606.38108.paul.moore@hp.com>
Date:	Fri, 7 Dec 2007 16:06:37 -0500
From:	Paul Moore <paul.moore@...com>
To:	Eric Paris <eparis@...hat.com>
Cc:	netdev@...r.kernel.org, linux-audit@...hat.com
Subject: Re: [PATCH] XFRM: RFC4303 compliant auditing

On Friday 07 December 2007 3:52:31 pm Eric Paris wrote:
> On Fri, 2007-12-07 at 14:57 -0500, Paul Moore wrote:
> > NOTE: This really is an RFC patch, it compiles and boots but that is
> > pretty much all I can promise at this point.  I'm posting this patch to
> > gather feedback from the audit crowd about the continued overloading of
> > the AUDIT_MAC_IPSEC_EVENT message type - continue to use it or create a
> > new audit message type?  Of course any other comments people may have are
> > always welcome.
>
> I'm all for continuing to use it, but I feel like the op= strings should
> probably all get collected up in one place to ease maintenance in the
> future, might not matter but it's nice to be able to look only on place
> in the code to find all of the possible op=

Agreed.  I punted on doing anything here for two main reasons:

1. It makes sense to do this in the xfrm_audit_start() function which I 
couldn't use here without some overhaul ...
2. ... I didn't want to overhaul anything if I was going to end up using 
separate message types.

If we decide to go with a single audit message type (kinda sounds like it) 
I'll fix this up in the next version.

> The one advantage to multiple messages is the ability to exclude and not
> audit certain things.  How often will these extra messages actually pop
> out of a system?  Enough that people would likely still care about some
> of them but decide they don't want others?  I don't know this stuff, so
> tell me how often would any of these show up?

Bingo, this is the whole reason why I was wondering about a different message 
type.  Currently only SAD and SPD changes are audited and only because they 
effect the security labels that are assigned to packets as they are 
imported/exported out of the system (look at the LSPP requirements for 
auditing the import and export of data).  These new audit messages apply to 
individual packets and/or a particular SA and have nothing to do with 
security labels, rather they indicate error conditions found during normal 
IPsec processing.  It would be difficult to think of all of the particular 
cases where these error conditions but in general I would say that these 
audit messages should not be common.

The only reason for creating a separate audit message type for these packet/SA 
messages would be to meet a RFC requirement that states that the 
implementation MUST allow the administrator to enable and disable ESP 
auditing.  Now, we can probably say we fulfill that requirement regardless, 
but more message types allow us greater granularity and flexibility ...

-- 
paul moore
linux security @ hp
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html