Technically there shouldn't be lots of denial messages in audit log, unless there is a repeated message with one of services or whatever, which should be solved. is there any host with a heavy audit.log right now?
I guess we can start with those hosts with selinux enforcing (if it's possible to do it partially) cause they probably have less messages.
btw: we cant save them for a long time, like few months at most I think. (then it may probably exceed 2 or 3 hundred megabytes, I'm not sure how much space is available)
--
I guess we can start with those hosts with selinux enforcing (if it's possible to do it partially) cause they probably have less messages.
btw: we cant save them for a long time, like few months at most I think. (then it may probably exceed 2 or 3 hundred megabytes, I'm not sure how much space is available)
On Tue, Oct 11, 2011 at 1:13 PM, seth vidal <skvidal@xxxxxxxxxxxxxxxxx> wrote:
Downsides:On Tue, 2011-10-11 at 13:56 -0600, Kevin Fenzi wrote:
> Greetings.
>
> I'd like to try stopping auditd and having selinux audit messages go to
> rsyslog (and thus be captured over on log02). This way we can have
> epylog process those logs, they can be remote so we can have a remote
> copy of them.
>
> This may result in some noise, but I think we can improve the epylog
> selinux module and fix things, and it gives us another audit trail of
> things happening on the machines where selinux is enabled.
>
> I think this should do it (in such a way we can easily back it out):
>
> diff --git a/modules/audit/manifests/init.pp
> b/modules/audit/manifests/init.pp index 30f19c7..ced28a1 100644
> --- a/modules/audit/manifests/init.pp
> +++ b/modules/audit/manifests/init.pp
> @@ -6,8 +6,8 @@ class audit::auditd {
> include audit::package
>
> service { auditd:
> - ensure => running,
> - enable => true,
> + ensure => stopped,
> + enable => false,
> require => Package['audit']
> }
>
> Thoughts? downsides? Alternate plans?
it is A LOT of traffic.
We should keep a close eye on how much noise it generates.
-sv
_______________________________________________
infrastructure mailing list
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
--
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
