From: Steve Grubb <sgrubb@redhat.com>
To: burn@swtf.dyndns.org
Cc: linux-audit@redhat.com
Subject: Re: EXT :Re: Adding enterprise capability - an includeConfig directive for audit.rules?
Date: Fri, 19 Apr 2013 06:53:41 -0400 [thread overview]
Message-ID: <1799370.IXfZOumMXk@x2> (raw)
In-Reply-To: <1366320233.29573.7.camel@swtf.swtf.dyndns.org>
On Friday, April 19, 2013 07:23:53 AM Burn Alting wrote:
> Steve,
>
> I will make the changes on the weekend and re-submit.
No need, I can take care of it. I just wanted to air the concerns and make
sure everyone was in agreement or maybe someone saw another way to solve the
problem. I will merge the code today with a couple changes. I am trying to get
the audit package ready for another release sometime in the next couple days.
So, if anyone has any other bugs...now's a good time to air them. :-)
-Steve
> On Thu, 2013-04-18 at 09:49 -0400, Steve Grubb wrote:
> > On Sunday, April 07, 2013 09:16:46 PM Burn Alting wrote:
> > > Please find attached my patch on this matter.
> >
> > Thanks for taking this on.
> >
> > > I essence, /etc/audit/audit.rules is now formed from files (.rules
> > > suffixed) within /etc/audit/rules.d. The new script /sbin/augenrules is
> > > executed by from either startup script, /etc/init.d/auditd
> > > or /usr/lib/systemd/system/auditd.service before calling auditctl.
> >
> > One issue that I am concerned about is how this feature gets added to
> > existing setups. For example, someone may have a /etc/audit/audit.rules
> > file, then upgrade and if there is an empty shipped policy in
> > /etc/audit/audit.d, it will erase the installed rules.
> >
> > So, I think we should have an /etc/sysconfig option that enables
> > augenrules so that an admin has to do something to turn this on thus
> > preventing automatic deletion of rules.
> >
> > For systemd, I think we want to ship the service file with the
> > ExecStartPost line commented out which then requires an admin to take an
> > action to enable. We really don't want unexpected things to happen during
> > an upgrade.>
> > > The generated file ensures
> > >
> > > - the last processed -D directive without an option, if present, is
> > >
> > > emitted on the first line
> >
> > In generating rules, we should always start with -D. I can't imagine not
> > having it.
> >
> > > - the last processed -b directive, if present, is emitted on the second
> > >
> > > line
> >
> > We probably want the largest in all the processed files.
> >
> > > - the last processed -f directive, if present, is emitted on the third
> > >
> > > line
> >
> > We probably want the largest here, too.
> >
> > > - the last processed -e directive, if present, is emitted as the last
> > >
> > > line.
> >
> > I was thinking that if any of the files try to ask for it to be immutable,
> > then it should go at the end.
> >
> > > The file, /etc/audit/audit.rules, is only updated if it has changed.
> > >
> > > > https://www.redhat.com/mailman/listinfo/linux-audit
> >
> > That is great, because any write could be an auditable event. At some
> > point we also might want to add support for a --check option which does
> > everything except overwrite the final rules.
> >
> > -Steve
next prev parent reply other threads:[~2013-04-19 10:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-27 9:38 Adding enterprise capability - an includeConfig directive for audit.rules? Burn Alting
2013-04-02 18:03 ` Steve Grubb
2013-04-03 10:37 ` Burn Alting
2013-04-03 11:42 ` Steve Grubb
2013-04-03 13:19 ` EXT :Re: " Boyce, Kevin P. (AS)
2013-04-03 20:19 ` Burn Alting
2013-04-07 11:16 ` Burn Alting
2013-04-18 13:49 ` Steve Grubb
2013-04-18 21:23 ` Burn Alting
2013-04-19 10:53 ` Steve Grubb [this message]
2013-04-24 20:37 ` Steve Grubb
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=1799370.IXfZOumMXk@x2 \
--to=sgrubb@redhat.com \
--cc=burn@swtf.dyndns.org \
--cc=linux-audit@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.