From: Klaus Weidner <klaus@atsec.com>
To: Joy Latten <latten@austin.ibm.com>
Cc: redhat-lspp@redhat.com, linux-audit@redhat.com,
Paul Moore <paul.moore@hp.com>
Subject: Re: labeled ipsec auditing
Date: Tue, 10 Oct 2006 19:00:28 -0500 [thread overview]
Message-ID: <20061011000028.GC28519@w-m-p.com> (raw)
In-Reply-To: <1160522701.17737.8.camel@faith.austin.ibm.com>
On Tue, Oct 10, 2006 at 06:25:01PM -0500, Joy Latten wrote:
> On Mon, 2006-10-09 at 14:30 -0500, Klaus Weidner wrote:
> > On Mon, Oct 09, 2006 at 03:15:09PM -0400, Paul Moore wrote:
> > > Going back to Joy's original mail I think it was the establishing or deleting of
> > > an SA with SELinux context that we were concerned about (at least that is what I
> > > was concerned about) as that could generate quite a bit of traffic. Based on
> > > your comments above it looks like that is something we need to do.
> >
> > Here's what Joy wrote:
> >
> > > I am auditing when an ipsec policy is added and removed from the
> > > Security Policy Database. Should I also add audit when an SA is
> > > added and removed?
> >
> > If I understand it correctly, SAs can also be added and removed manually,
> > and unless we forbid that admins do that, it would need to be audited.
> >
>
> Then do I only want to audit when an SA or SPD is manually added or
> deleted? Or just audit them regardless?
I don't really know the logic well enough to give a definitive answer.
The point is that the audit trail should provide enough information to
see changes to the IPSec state that affect MLS.
If you can make a clear distinction between manually and automatically
created ones in the code, it would be okay to have no audit record for
changes to an SA that was added or removed automatically based on the
SPD, as long as changes to the SPD are audited. If it's not clear how to
distinguish them, it's safest to have audit capability for all SA events.
-Klaus
next prev parent reply other threads:[~2006-10-11 0:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-05 21:23 labeled ipsec auditing Joy Latten
2006-10-05 22:04 ` Steve Grubb
2006-10-05 22:15 ` [redhat-lspp] " Paul Moore
2006-10-09 19:09 ` Klaus Weidner
2006-10-09 19:15 ` Paul Moore
2006-10-09 19:30 ` Klaus Weidner
2006-10-10 23:25 ` Joy Latten
2006-10-11 0:00 ` Klaus Weidner [this message]
2006-10-11 13:38 ` Serge E. Hallyn
2006-10-11 18:07 ` [redhat-lspp] " Joy Latten
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061011000028.GC28519@w-m-p.com \
--to=klaus@atsec.com \
--cc=latten@austin.ibm.com \
--cc=linux-audit@redhat.com \
--cc=paul.moore@hp.com \
--cc=redhat-lspp@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox