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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox