* RE: Audit reporting Invalid argument
From: Bhagwat, Shriniketan Manjunath @ 2016-06-14 13:44 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <3850158.qFrFSIuG4S@x2>
Hi Steve,
>> The plugin will be restarted when the next event arrives to audispd.
I do not want my plug-in to be running unnecessarily all the time until the auditd is running.
I can accomplish my requirement by sending SIGHUP to audispd and changing the plug-in configuration's option active=yes/no.
Regards,
Ketan
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Monday, June 13, 2016 8:31 PM
To: Bhagwat, Shriniketan Manjunath <shriniketan.bhagwat@hpe.com>
Cc: linux-audit@redhat.com
Subject: Re: Audit reporting Invalid argument
On Monday, June 13, 2016 08:15:36 AM Bhagwat, Shriniketan Manjunath wrote:
> Hi,
>
> Is it possible to start and stop the user written audit plug-in while
> auditd and audispd running? As I understand, audispd is started by
> auditd. Audispd starts the user plug-in program using their
> configuration files present in /etc/audisp/plugins.d directory. Auditd
> and user plug-in are started and stopped as part of auditd startup and
> stop. Is it possible to start the user plug-in after the auditd is
> started and stop the user plug-in before the auditd is stopped?
There is nothing that prevents you from sending a SIGTERM to the plugin if you are root. The plugin will be restarted when the next event arrives to audispd.
-Steve
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Monday, May 16, 2016 6:24 PM
> To: Bhagwat, Shriniketan Manjunath <shriniketan.bhagwat@hpe.com>
> Cc: linux-audit@redhat.com
> Subject: Re: Audit reporting Invalid argument
>
> On Saturday, May 14, 2016 09:40:05 AM Bhagwat, Shriniketan Manjunath wrote:
> > > Not today. The check for uid 0 is a poor man's check for
> > > CAP_AUDIT_CONTROL
> >
> > Are there any future plans to support enabling audit from non root
> > user using CAP_AUDIT_CONTROL?
>
> You are the only person who has asked for it. I suppose it can be done
> in a couple lines of code. But you still have the permissions of the
> directories that hold the rules to correct. Easy to fix, but I think
> you might be fighting the distribution's package manager which would
> set things back to root every update.
> > Regarding suppression of events, I will do some testing and let you
> > know later.
> >
> > Is there a way I can avoid default logging of the audit events to
> > /var/log/audit/audit.log?
>
> If you have an old copy old the audit system (2.5.1 or earlier) then
> use log_format = NOLOG. If you have a current copy, then use write_logs = no.
>
> -Steve
>
> > I do not want audit to log audit events to audit.log, however I will
> > capture them using my plug-in. Is there a way I can accomplish this?
> > I tried to commenting the log_file filed from auditd.conf, however
> > the events are still written to audit.log. I think below code from
> > auditd-config.c is causing audit to write to audit.log
> >
> > config->log_file = strdup("/var/log/audit/audit.log");
^ permalink raw reply
* Re: Audit reporting Invalid argument
From: Steve Grubb @ 2016-06-13 15:01 UTC (permalink / raw)
To: Bhagwat, Shriniketan Manjunath; +Cc: linux-audit@redhat.com
In-Reply-To: <8FC6AD31395616439ECBCD98E071A87F4BF3F544@G4W3296.americas.hpqcorp.net>
On Monday, June 13, 2016 08:15:36 AM Bhagwat, Shriniketan Manjunath wrote:
> Hi,
>
> Is it possible to start and stop the user written audit plug-in while auditd
> and audispd running? As I understand, audispd is started by auditd. Audispd
> starts the user plug-in program using their configuration files present in
> /etc/audisp/plugins.d directory. Auditd and user plug-in are started and
> stopped as part of auditd startup and stop. Is it possible to start the
> user plug-in after the auditd is started and stop the user plug-in before
> the auditd is stopped?
There is nothing that prevents you from sending a SIGTERM to the plugin if you
are root. The plugin will be restarted when the next event arrives to audispd.
-Steve
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Monday, May 16, 2016 6:24 PM
> To: Bhagwat, Shriniketan Manjunath <shriniketan.bhagwat@hpe.com>
> Cc: linux-audit@redhat.com
> Subject: Re: Audit reporting Invalid argument
>
> On Saturday, May 14, 2016 09:40:05 AM Bhagwat, Shriniketan Manjunath wrote:
> > > Not today. The check for uid 0 is a poor man's check for
> > > CAP_AUDIT_CONTROL
> >
> > Are there any future plans to support enabling audit from non root
> > user using CAP_AUDIT_CONTROL?
>
> You are the only person who has asked for it. I suppose it can be done in a
> couple lines of code. But you still have the permissions of the directories
> that hold the rules to correct. Easy to fix, but I think you might be
> fighting the distribution's package manager which would set things back to
> root every update.
> > Regarding suppression of events, I will do some testing and let you
> > know later.
> >
> > Is there a way I can avoid default logging of the audit events to
> > /var/log/audit/audit.log?
>
> If you have an old copy old the audit system (2.5.1 or earlier) then use
> log_format = NOLOG. If you have a current copy, then use write_logs = no.
>
> -Steve
>
> > I do not want audit to log audit events to audit.log, however I will
> > capture them using my plug-in. Is there a way I can accomplish this? I
> > tried to commenting the log_file filed from auditd.conf, however the
> > events are still written to audit.log. I think below code from
> > auditd-config.c is causing audit to write to audit.log
> >
> > config->log_file = strdup("/var/log/audit/audit.log");
^ permalink raw reply
* RE: Audit reporting Invalid argument
From: Bhagwat, Shriniketan Manjunath @ 2016-06-13 8:15 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <1956741.kKb8qJBsiM@x2>
Hi,
Is it possible to start and stop the user written audit plug-in while auditd and audispd running?
As I understand, audispd is started by auditd. Audispd starts the user plug-in program using their configuration files present in /etc/audisp/plugins.d directory. Auditd and user plug-in are started and stopped as part of auditd startup and stop.
Is it possible to start the user plug-in after the auditd is started and stop the user plug-in before the auditd is stopped?
Regards,
Ketan
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Monday, May 16, 2016 6:24 PM
To: Bhagwat, Shriniketan Manjunath <shriniketan.bhagwat@hpe.com>
Cc: linux-audit@redhat.com
Subject: Re: Audit reporting Invalid argument
On Saturday, May 14, 2016 09:40:05 AM Bhagwat, Shriniketan Manjunath wrote:
> > Not today. The check for uid 0 is a poor man's check for
> > CAP_AUDIT_CONTROL
>
> Are there any future plans to support enabling audit from non root
> user using CAP_AUDIT_CONTROL?
You are the only person who has asked for it. I suppose it can be done in a couple lines of code. But you still have the permissions of the directories that hold the rules to correct. Easy to fix, but I think you might be fighting the distribution's package manager which would set things back to root every update.
> Regarding suppression of events, I will do some testing and let you
> know later.
>
> Is there a way I can avoid default logging of the audit events to
> /var/log/audit/audit.log?
If you have an old copy old the audit system (2.5.1 or earlier) then use log_format = NOLOG. If you have a current copy, then use write_logs = no.
-Steve
> I do not want audit to log audit events to audit.log, however I will
> capture them using my plug-in. Is there a way I can accomplish this? I
> tried to commenting the log_file filed from auditd.conf, however the
> events are still written to audit.log. I think below code from
> auditd-config.c is causing audit to write to audit.log
>
> config->log_file = strdup("/var/log/audit/audit.log");
^ permalink raw reply
* Re: problems with slow auditing/journaling after updating to RHEL 6.8
From: Steve Grubb @ 2016-06-10 17:20 UTC (permalink / raw)
To: linux-audit
Cc: Hymowitz, Eric B. (GSFC-444.0)[HONEYWELL TECHNOLOGY SOLUTIONS INC]
In-Reply-To: <C48FB23694BB7C419BE308167EE3ED4B0A272B48@NDMSMBX401.ndc.nasa.gov>
On Friday, June 10, 2016 04:43:19 PM Jacobson, Robert C. [HONEYWELL TECHNOLOGY
SOLUTIONS INC] wrote:
> I guess the first question I should ask is : is this the proper list for
> questions about problems? If not, then please accept my apology -- and I
> would greatly appreciate if you could direct me to the proper list.
Yes, this is the correct list.
> I recently upgraded a system to RHEL 6.8.
> kernel: 2.6.32-642.1.1.el6.x86_64
> audit: audit-2.4.5-3.el6.x86_64
>
> My users and I immediately noticed a huge drop in application performance --
> and when I investigated further, I found a large amount of CPU wait.
Look under audit
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.8_Release_Notes/new_features_security.html
There was a bug fixed where the guarantee about writing to disk was not being
met. There were two choices, fix the behavior so that you get guaranteed writes
to disk or leave it alone and hope no one ever notices.
This led me to do a performance study during the Christmas break and I posted
the results here:
https://www.redhat.com/archives/linux-audit/2015-December/msg00061.html
What I would recommend is changing flush to INCREMENTAL and freq to a number on
that table that you think is the target performance you need. 100 is a good
all around number.
The result of this performance study then led to a redesign of the logging
code released in 2.5. The 2.5 logging is over 90 times faster except when
using SYNC or DATA settings. Nothing can really help that.
-Steve
> Here's a graph from nagios data via splunk, over the past 48 hours. The
> system was patched ~1300 (right about the middle of each graph -- the first
> spike), then rebooted at 1715 (the second spike):
> http://i.imgur.com/BuyazLH.jpg
>
> Here's some nmon snapshot during a "problem" period:
> http://i.imgur.com/YbQjeK2.jpg
>
> (note: all logical volumes on sda5, dm-9 is the logical volume for audit
> logs)
>
> If I'm interpreting things correctly, it is due to drastic slow-down of
> journaling on my audit volume. I don't know if this is a problem with the
> auditing subsystem, or the disk I/O subsystem, or ... what?
>
> Here's an excerpt from iotop, while I run a process that generates perhaps
> 1000 audit log messages:
>
> Total DISK READ : 0.00 B/s | Total DISK WRITE : 160.53 K/s
> Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 586.11 K/s
> PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
> 1458 be/3 root 0.00 B/s 0.00 B/s 0.00 % 97.23 % [jbd2/dm-9-8]
> 24354 be/3 root 0.00 B/s 145.59 K/s 0.00 % 0.54 % auditd
>
> The total amount of data generated in the logs is actually very small --
> approximately 1 MB -- so I'm puzzled as to why it would take so long to
> write it out.
>
> The process that generates most of these audit messages takes 1.1 second to
> run with auditing off (or on a RHEL 6.7 system with auditing on or off).
> With auditing running, it takes 32 seconds to run.
>
> ## auditing is off:
> $ time nice -n 10 /product/bin/fclient.rb -d 3
> Logging in /tmp/ferret.log
>
> real 0m1.113s
> user 0m0.435s
> sys 0m0.643s
>
> ## auditing is on:
> $ time nice -n 10 /product/bin/fclient.rb -d 3
> Logging in /tmp/ferret.log
>
> real 0m32.088s
> user 0m0.394s
> sys 0m0.686s
>
> I'll note that the ruby version hasn't changed between 6.7 and 6.8 (still
> ruby-1.8.7.374-4.el6_6.x86_64)
>
> The system is using CFQ for disk I/O. The filesystem is ext4. Disks are
> all local SATA disks.
>
> I'd appreciate any guidance you have!
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Robert Jacobson Robert.C.Jacobson@nasa.gov
> Lead System Admin Solar Dynamics Observatory (SDO)
> Bldg 14, E222 (301) 286-1591
>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* problems with slow auditing/journaling after updating to RHEL 6.8
From: Jacobson, Robert C. (GSFC-444.0)[HONEYWELL TECHNOLOGY SOLUTIONS INC] @ 2016-06-10 16:43 UTC (permalink / raw)
To: linux-audit@redhat.com
Cc: Hymowitz, Eric B. (GSFC-444.0)[HONEYWELL TECHNOLOGY SOLUTIONS INC]
I guess the first question I should ask is : is this the proper list for questions about problems? If not, then please accept my apology -- and I would greatly appreciate if you could direct me to the proper list.
I recently upgraded a system to RHEL 6.8.
kernel: 2.6.32-642.1.1.el6.x86_64
audit: audit-2.4.5-3.el6.x86_64
My users and I immediately noticed a huge drop in application performance -- and when I investigated further, I found a large amount of CPU wait.
Here's a graph from nagios data via splunk, over the past 48 hours. The system was patched ~1300 (right about the middle of each graph -- the first spike), then rebooted at 1715 (the second spike):
http://i.imgur.com/BuyazLH.jpg
Here's some nmon snapshot during a "problem" period:
http://i.imgur.com/YbQjeK2.jpg
(note: all logical volumes on sda5, dm-9 is the logical volume for audit logs)
If I'm interpreting things correctly, it is due to drastic slow-down of journaling on my audit volume. I don't know if this is a problem with the auditing subsystem, or the disk I/O subsystem, or ... what?
Here's an excerpt from iotop, while I run a process that generates perhaps 1000 audit log messages:
Total DISK READ : 0.00 B/s | Total DISK WRITE : 160.53 K/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 586.11 K/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1458 be/3 root 0.00 B/s 0.00 B/s 0.00 % 97.23 % [jbd2/dm-9-8]
24354 be/3 root 0.00 B/s 145.59 K/s 0.00 % 0.54 % auditd
The total amount of data generated in the logs is actually very small -- approximately 1 MB -- so I'm puzzled as to why it would take so long to write it out.
The process that generates most of these audit messages takes 1.1 second to run with auditing off (or on a RHEL 6.7 system with auditing on or off).
With auditing running, it takes 32 seconds to run.
## auditing is off:
$ time nice -n 10 /product/bin/fclient.rb -d 3
Logging in /tmp/ferret.log
real 0m1.113s
user 0m0.435s
sys 0m0.643s
## auditing is on:
$ time nice -n 10 /product/bin/fclient.rb -d 3
Logging in /tmp/ferret.log
real 0m32.088s
user 0m0.394s
sys 0m0.686s
I'll note that the ruby version hasn't changed between 6.7 and 6.8 (still ruby-1.8.7.374-4.el6_6.x86_64)
The system is using CFQ for disk I/O. The filesystem is ext4. Disks are all local SATA disks.
I'd appreciate any guidance you have!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert Jacobson Robert.C.Jacobson@nasa.gov
Lead System Admin Solar Dynamics Observatory (SDO)
Bldg 14, E222 (301) 286-1591
^ permalink raw reply
* Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
From: Richard Guy Briggs @ 2016-06-10 1:44 UTC (permalink / raw)
To: Steve Grubb
Cc: Arnd Bergmann, y2038, linux-kernel, linux-audit, Al Viro,
linux-fsdevel, Thomas Gleixner, Linus Torvalds, Deepa Dinamani
In-Reply-To: <1850599.zs4hA4SSlr@x2>
On 16/06/09, Steve Grubb wrote:
> On Thursday, June 09, 2016 07:59:43 PM Richard Guy Briggs wrote:
> > On 16/06/09, Steve Grubb wrote:
> > > On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
> > > > struct timespec is not y2038 safe.
> > > > Audit timestamps are recorded in string format into
> > > > an audit buffer for a given context.
> > > > These mark the entry timestamps for the syscalls.
> > > > Use y2038 safe struct timespec64 to represent the times.
> > > > The log strings can handle this transition as strings can
> > > > hold upto 1024 characters.
> > >
> > > Have you tested this with ausearch or any audit utilities? As an aside, a
> > > time stamp that is up to 1024 characters long is terribly wasteful
> > > considering how many events we get.
> >
> > Steve,
> >
> > I don't expect the size of the time stamp text to change since the
> > format isn't being changed and I don't expect the date stamp text length
> > to change until Y10K, but you never know what will happen in 8
> > millenia... (Who knows, maybe that damn Linux server in my basement
> > will still be running then...)
> >
> > Isn't the maximum message length MAX_AUDIT_MESSAGE_LENGTH (8970 octets)?
>
> Bytes, yes. But I was thinking that if its going to get big we should consider
> switching from a base 10 representation to base 16. That would give us back a
> few bytes. We discuss this on the linux-audit list rather than the main list.
This seems like a false economy to me. If I understand correctly, it
will be 285 years before we roll the next text digit. The next binary
digit in the internal kernel format is in 22 years.
I know there have been discussions about changing to a binary format,
which seems to have a lot more to offer than breaking the current format
for a few bytes.
Is this not the linux-audit main list? Is there another one I am
missing?
> -Steve
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
From: Deepa Dinamani @ 2016-06-10 0:45 UTC (permalink / raw)
To: Steve Grubb
Cc: Arnd Bergmann, y2038, Linux Kernel Mailing List, linux-audit,
Al Viro, Linux FS-devel Mailing List, Thomas Gleixner,
Linus Torvalds
In-Reply-To: <15760445.1IAucOxmWy@x2>
On Thu, Jun 9, 2016 at 7:31 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
>> Audit timestamps are recorded in string format into
>> an audit buffer for a given context.
>> These mark the entry timestamps for the syscalls.
>> Use y2038 safe struct timespec64 to represent the times.
>> The log strings can handle this transition as strings can
>> hold upto 1024 characters.
>
> Have you tested this with ausearch or any audit utilities? As an aside, a time
> stamp that is up to 1024 characters long is terribly wasteful considering how
> many events we get.
/* AUDIT_BUFSIZ is the size of the temporary buffer used for formatting
* audit records. Since printk uses a 1024 byte buffer, this buffer
* should be at least that large. */
#define AUDIT_BUFSIZ 1024
The commit text is pointing out that the reserve space ensured in each
call to audit_log_vformat is already much more than is needed by this
call from audit_log_start.
Also, since struct timespec64 is already the same as struct timespec
on 64-bit systems, there is really no functional change except on
32-bit machines.
Let me know if you want me to try it out on a 32-bit system.
-Deepa
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
From: Steve Grubb @ 2016-06-10 0:19 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Arnd Bergmann, y2038, linux-kernel, linux-audit, Al Viro,
linux-fsdevel, Thomas Gleixner, Linus Torvalds, Deepa Dinamani
In-Reply-To: <20160609235943.GL18488@madcap2.tricolour.ca>
On Thursday, June 09, 2016 07:59:43 PM Richard Guy Briggs wrote:
> On 16/06/09, Steve Grubb wrote:
> > On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
> > > struct timespec is not y2038 safe.
> > > Audit timestamps are recorded in string format into
> > > an audit buffer for a given context.
> > > These mark the entry timestamps for the syscalls.
> > > Use y2038 safe struct timespec64 to represent the times.
> > > The log strings can handle this transition as strings can
> > > hold upto 1024 characters.
> >
> > Have you tested this with ausearch or any audit utilities? As an aside, a
> > time stamp that is up to 1024 characters long is terribly wasteful
> > considering how many events we get.
>
> Steve,
>
> I don't expect the size of the time stamp text to change since the
> format isn't being changed and I don't expect the date stamp text length
> to change until Y10K, but you never know what will happen in 8
> millenia... (Who knows, maybe that damn Linux server in my basement
> will still be running then...)
>
> Isn't the maximum message length MAX_AUDIT_MESSAGE_LENGTH (8970 octets)?
Bytes, yes. But I was thinking that if its going to get big we should consider
switching from a base 10 representation to base 16. That would give us back a
few bytes. We discuss this on the linux-audit list rather than the main list.
-Steve
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
From: Richard Guy Briggs @ 2016-06-09 23:59 UTC (permalink / raw)
To: Steve Grubb
Cc: linux-audit, Arnd Bergmann, y2038, linux-kernel, Al Viro,
linux-fsdevel, Thomas Gleixner, Linus Torvalds, Deepa Dinamani
In-Reply-To: <15760445.1IAucOxmWy@x2>
On 16/06/09, Steve Grubb wrote:
> On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
> > struct timespec is not y2038 safe.
> > Audit timestamps are recorded in string format into
> > an audit buffer for a given context.
> > These mark the entry timestamps for the syscalls.
> > Use y2038 safe struct timespec64 to represent the times.
> > The log strings can handle this transition as strings can
> > hold upto 1024 characters.
>
> Have you tested this with ausearch or any audit utilities? As an aside, a time
> stamp that is up to 1024 characters long is terribly wasteful considering how
> many events we get.
Steve,
I don't expect the size of the time stamp text to change since the
format isn't being changed and I don't expect the date stamp text length
to change until Y10K, but you never know what will happen in 8
millenia... (Who knows, maybe that damn Linux server in my basement
will still be running then...)
Isn't the maximum message length MAX_AUDIT_MESSAGE_LENGTH (8970 octets)?
> -Steve
>
> > Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> > Cc: Paul Moore <paul@paul-moore.com>
> > Cc: Eric Paris <eparis@redhat.com>
> > Cc: linux-audit@redhat.com
> > ---
> > include/linux/audit.h | 4 ++--
> > kernel/audit.c | 10 +++++-----
> > kernel/audit.h | 2 +-
> > kernel/auditsc.c | 6 +++---
> > 4 files changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index 961a417..2f6a1123 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -335,7 +335,7 @@ static inline void audit_ptrace(struct task_struct *t)
> > /* Private API (for audit.c only) */
> > extern unsigned int audit_serial(void);
> > extern int auditsc_get_stamp(struct audit_context *ctx,
> > - struct timespec *t, unsigned int *serial);
> > + struct timespec64 *t, unsigned int *serial);
> > extern int audit_set_loginuid(kuid_t loginuid);
> >
> > static inline kuid_t audit_get_loginuid(struct task_struct *tsk)
> > @@ -510,7 +510,7 @@ static inline void __audit_seccomp(unsigned long
> > syscall, long signr, int code) static inline void audit_seccomp(unsigned
> > long syscall, long signr, int code) { }
> > static inline int auditsc_get_stamp(struct audit_context *ctx,
> > - struct timespec *t, unsigned int *serial)
> > + struct timespec64 *t, unsigned int *serial)
> > {
> > return 0;
> > }
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 22bb4f2..6c2f405 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -1325,10 +1325,10 @@ unsigned int audit_serial(void)
> > }
> >
> > static inline void audit_get_stamp(struct audit_context *ctx,
> > - struct timespec *t, unsigned int *serial)
> > + struct timespec64 *t, unsigned int *serial)
> > {
> > if (!ctx || !auditsc_get_stamp(ctx, t, serial)) {
> > - *t = CURRENT_TIME;
> > + ktime_get_real_ts64(t);
> > *serial = audit_serial();
> > }
> > }
> > @@ -1370,7 +1370,7 @@ struct audit_buffer *audit_log_start(struct
> > audit_context *ctx, gfp_t gfp_mask, int type)
> > {
> > struct audit_buffer *ab = NULL;
> > - struct timespec t;
> > + struct timespec64 t;
> > unsigned int uninitialized_var(serial);
> > int reserve = 5; /* Allow atomic callers to go up to five
> > entries over the normal backlog limit */
> > @@ -1422,8 +1422,8 @@ struct audit_buffer *audit_log_start(struct
> > audit_context *ctx, gfp_t gfp_mask,
> >
> > audit_get_stamp(ab->ctx, &t, &serial);
> >
> > - audit_log_format(ab, "audit(%lu.%03lu:%u): ",
> > - t.tv_sec, t.tv_nsec/1000000, serial);
> > + audit_log_format(ab, "audit(%llu.%03lu:%u): ",
> > + (unsigned long long)t.tv_sec, t.tv_nsec/1000000, serial);
> > return ab;
> > }
> >
> > diff --git a/kernel/audit.h b/kernel/audit.h
> > index cbbe6bb..029d674 100644
> > --- a/kernel/audit.h
> > +++ b/kernel/audit.h
> > @@ -111,7 +111,7 @@ struct audit_context {
> > enum audit_state state, current_state;
> > unsigned int serial; /* serial number for record */
> > int major; /* syscall number */
> > - struct timespec ctime; /* time of syscall entry */
> > + struct timespec64 ctime; /* time of syscall entry */
> > unsigned long argv[4]; /* syscall arguments */
> > long return_code;/* syscall return code */
> > u64 prio;
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 62ab53d..ecebb3c 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -1523,7 +1523,7 @@ void __audit_syscall_entry(int major, unsigned long
> > a1, unsigned long a2, return;
> >
> > context->serial = 0;
> > - context->ctime = CURRENT_TIME;
> > + ktime_get_real_ts64(&context->ctime);
> > context->in_syscall = 1;
> > context->current_state = state;
> > context->ppid = 0;
> > @@ -1932,13 +1932,13 @@ EXPORT_SYMBOL_GPL(__audit_inode_child);
> > /**
> > * auditsc_get_stamp - get local copies of audit_context values
> > * @ctx: audit_context for the task
> > - * @t: timespec to store time recorded in the audit_context
> > + * @t: timespec64 to store time recorded in the audit_context
> > * @serial: serial value that is recorded in the audit_context
> > *
> > * Also sets the context as auditable.
> > */
> > int auditsc_get_stamp(struct audit_context *ctx,
> > - struct timespec *t, unsigned int *serial)
> > + struct timespec64 *t, unsigned int *serial)
> > {
> > if (!ctx->in_syscall)
> > return 0;
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
- RGB
^ permalink raw reply
* Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
From: Steve Grubb @ 2016-06-09 14:31 UTC (permalink / raw)
To: linux-audit
Cc: Deepa Dinamani, linux-fsdevel, linux-kernel, Arnd Bergmann, y2038,
Al Viro, Thomas Gleixner, Linus Torvalds
In-Reply-To: <1465448705-25055-18-git-send-email-deepa.kernel@gmail.com>
On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
> struct timespec is not y2038 safe.
> Audit timestamps are recorded in string format into
> an audit buffer for a given context.
> These mark the entry timestamps for the syscalls.
> Use y2038 safe struct timespec64 to represent the times.
> The log strings can handle this transition as strings can
> hold upto 1024 characters.
Have you tested this with ausearch or any audit utilities? As an aside, a time
stamp that is up to 1024 characters long is terribly wasteful considering how
many events we get.
-Steve
> Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Eric Paris <eparis@redhat.com>
> Cc: linux-audit@redhat.com
> ---
> include/linux/audit.h | 4 ++--
> kernel/audit.c | 10 +++++-----
> kernel/audit.h | 2 +-
> kernel/auditsc.c | 6 +++---
> 4 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 961a417..2f6a1123 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -335,7 +335,7 @@ static inline void audit_ptrace(struct task_struct *t)
> /* Private API (for audit.c only) */
> extern unsigned int audit_serial(void);
> extern int auditsc_get_stamp(struct audit_context *ctx,
> - struct timespec *t, unsigned int *serial);
> + struct timespec64 *t, unsigned int *serial);
> extern int audit_set_loginuid(kuid_t loginuid);
>
> static inline kuid_t audit_get_loginuid(struct task_struct *tsk)
> @@ -510,7 +510,7 @@ static inline void __audit_seccomp(unsigned long
> syscall, long signr, int code) static inline void audit_seccomp(unsigned
> long syscall, long signr, int code) { }
> static inline int auditsc_get_stamp(struct audit_context *ctx,
> - struct timespec *t, unsigned int *serial)
> + struct timespec64 *t, unsigned int *serial)
> {
> return 0;
> }
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 22bb4f2..6c2f405 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1325,10 +1325,10 @@ unsigned int audit_serial(void)
> }
>
> static inline void audit_get_stamp(struct audit_context *ctx,
> - struct timespec *t, unsigned int *serial)
> + struct timespec64 *t, unsigned int *serial)
> {
> if (!ctx || !auditsc_get_stamp(ctx, t, serial)) {
> - *t = CURRENT_TIME;
> + ktime_get_real_ts64(t);
> *serial = audit_serial();
> }
> }
> @@ -1370,7 +1370,7 @@ struct audit_buffer *audit_log_start(struct
> audit_context *ctx, gfp_t gfp_mask, int type)
> {
> struct audit_buffer *ab = NULL;
> - struct timespec t;
> + struct timespec64 t;
> unsigned int uninitialized_var(serial);
> int reserve = 5; /* Allow atomic callers to go up to five
> entries over the normal backlog limit */
> @@ -1422,8 +1422,8 @@ struct audit_buffer *audit_log_start(struct
> audit_context *ctx, gfp_t gfp_mask,
>
> audit_get_stamp(ab->ctx, &t, &serial);
>
> - audit_log_format(ab, "audit(%lu.%03lu:%u): ",
> - t.tv_sec, t.tv_nsec/1000000, serial);
> + audit_log_format(ab, "audit(%llu.%03lu:%u): ",
> + (unsigned long long)t.tv_sec, t.tv_nsec/1000000, serial);
> return ab;
> }
>
> diff --git a/kernel/audit.h b/kernel/audit.h
> index cbbe6bb..029d674 100644
> --- a/kernel/audit.h
> +++ b/kernel/audit.h
> @@ -111,7 +111,7 @@ struct audit_context {
> enum audit_state state, current_state;
> unsigned int serial; /* serial number for record */
> int major; /* syscall number */
> - struct timespec ctime; /* time of syscall entry */
> + struct timespec64 ctime; /* time of syscall entry */
> unsigned long argv[4]; /* syscall arguments */
> long return_code;/* syscall return code */
> u64 prio;
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 62ab53d..ecebb3c 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1523,7 +1523,7 @@ void __audit_syscall_entry(int major, unsigned long
> a1, unsigned long a2, return;
>
> context->serial = 0;
> - context->ctime = CURRENT_TIME;
> + ktime_get_real_ts64(&context->ctime);
> context->in_syscall = 1;
> context->current_state = state;
> context->ppid = 0;
> @@ -1932,13 +1932,13 @@ EXPORT_SYMBOL_GPL(__audit_inode_child);
> /**
> * auditsc_get_stamp - get local copies of audit_context values
> * @ctx: audit_context for the task
> - * @t: timespec to store time recorded in the audit_context
> + * @t: timespec64 to store time recorded in the audit_context
> * @serial: serial value that is recorded in the audit_context
> *
> * Also sets the context as auditable.
> */
> int auditsc_get_stamp(struct audit_context *ctx,
> - struct timespec *t, unsigned int *serial)
> + struct timespec64 *t, unsigned int *serial)
> {
> if (!ctx->in_syscall)
> return 0;
^ permalink raw reply
* [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
From: Deepa Dinamani @ 2016-06-09 5:05 UTC (permalink / raw)
To: linux-fsdevel, linux-kernel
Cc: Arnd Bergmann, Thomas Gleixner, Al Viro, Linus Torvalds, y2038,
Paul Moore, Eric Paris, linux-audit
In-Reply-To: <1465448705-25055-1-git-send-email-deepa.kernel@gmail.com>
struct timespec is not y2038 safe.
Audit timestamps are recorded in string format into
an audit buffer for a given context.
These mark the entry timestamps for the syscalls.
Use y2038 safe struct timespec64 to represent the times.
The log strings can handle this transition as strings can
hold upto 1024 characters.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Eric Paris <eparis@redhat.com>
Cc: linux-audit@redhat.com
---
include/linux/audit.h | 4 ++--
kernel/audit.c | 10 +++++-----
kernel/audit.h | 2 +-
kernel/auditsc.c | 6 +++---
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 961a417..2f6a1123 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -335,7 +335,7 @@ static inline void audit_ptrace(struct task_struct *t)
/* Private API (for audit.c only) */
extern unsigned int audit_serial(void);
extern int auditsc_get_stamp(struct audit_context *ctx,
- struct timespec *t, unsigned int *serial);
+ struct timespec64 *t, unsigned int *serial);
extern int audit_set_loginuid(kuid_t loginuid);
static inline kuid_t audit_get_loginuid(struct task_struct *tsk)
@@ -510,7 +510,7 @@ static inline void __audit_seccomp(unsigned long syscall, long signr, int code)
static inline void audit_seccomp(unsigned long syscall, long signr, int code)
{ }
static inline int auditsc_get_stamp(struct audit_context *ctx,
- struct timespec *t, unsigned int *serial)
+ struct timespec64 *t, unsigned int *serial)
{
return 0;
}
diff --git a/kernel/audit.c b/kernel/audit.c
index 22bb4f2..6c2f405 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1325,10 +1325,10 @@ unsigned int audit_serial(void)
}
static inline void audit_get_stamp(struct audit_context *ctx,
- struct timespec *t, unsigned int *serial)
+ struct timespec64 *t, unsigned int *serial)
{
if (!ctx || !auditsc_get_stamp(ctx, t, serial)) {
- *t = CURRENT_TIME;
+ ktime_get_real_ts64(t);
*serial = audit_serial();
}
}
@@ -1370,7 +1370,7 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
int type)
{
struct audit_buffer *ab = NULL;
- struct timespec t;
+ struct timespec64 t;
unsigned int uninitialized_var(serial);
int reserve = 5; /* Allow atomic callers to go up to five
entries over the normal backlog limit */
@@ -1422,8 +1422,8 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
audit_get_stamp(ab->ctx, &t, &serial);
- audit_log_format(ab, "audit(%lu.%03lu:%u): ",
- t.tv_sec, t.tv_nsec/1000000, serial);
+ audit_log_format(ab, "audit(%llu.%03lu:%u): ",
+ (unsigned long long)t.tv_sec, t.tv_nsec/1000000, serial);
return ab;
}
diff --git a/kernel/audit.h b/kernel/audit.h
index cbbe6bb..029d674 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -111,7 +111,7 @@ struct audit_context {
enum audit_state state, current_state;
unsigned int serial; /* serial number for record */
int major; /* syscall number */
- struct timespec ctime; /* time of syscall entry */
+ struct timespec64 ctime; /* time of syscall entry */
unsigned long argv[4]; /* syscall arguments */
long return_code;/* syscall return code */
u64 prio;
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 62ab53d..ecebb3c 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1523,7 +1523,7 @@ void __audit_syscall_entry(int major, unsigned long a1, unsigned long a2,
return;
context->serial = 0;
- context->ctime = CURRENT_TIME;
+ ktime_get_real_ts64(&context->ctime);
context->in_syscall = 1;
context->current_state = state;
context->ppid = 0;
@@ -1932,13 +1932,13 @@ EXPORT_SYMBOL_GPL(__audit_inode_child);
/**
* auditsc_get_stamp - get local copies of audit_context values
* @ctx: audit_context for the task
- * @t: timespec to store time recorded in the audit_context
+ * @t: timespec64 to store time recorded in the audit_context
* @serial: serial value that is recorded in the audit_context
*
* Also sets the context as auditable.
*/
int auditsc_get_stamp(struct audit_context *ctx,
- struct timespec *t, unsigned int *serial)
+ struct timespec64 *t, unsigned int *serial)
{
if (!ctx->in_syscall)
return 0;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] audit: add fields to exclude filter by reusing user filter
From: Paul Moore @ 2016-06-03 20:31 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: Paul Moore, linux-audit, linux-kernel
In-Reply-To: <20160603202426.GJ1759@madcap2.tricolour.ca>
On Fri, Jun 3, 2016 at 4:24 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 16/06/03, Paul Moore wrote:
>> On Wed, Jun 1, 2016 at 6:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > RFE: add additional fields for use in audit filter exclude rules
>> > https://github.com/linux-audit/audit-kernel/issues/5
>> >
>> > Re-factor audit_filter_type() to use audit_filter_user_rules() to enable
>> > exclude filter to additionally filter on PID, UID, GID, AUID,
>> > LOGINUID_SET, SUBJ_*.
>> >
>> > Add check in audit_filter_user() to quit early if list is empty.
>> >
>> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
>> > ---
>> > kernel/auditfilter.c | 22 +++++++++-------------
>> > 1 files changed, 9 insertions(+), 13 deletions(-)
>>
>> I like the consolidation between audit_filter_type() and
>> audit_filter_user(), I like it so much I think we should take it
>> further. Let's consolidate both functions into a single function (say
>> audit_filter()?) and update the callers to use the new function. This
>> shouldn't be hard as the only callers are audit_receive_msg() and
>> audit_log_start(); you'll need to be careful as the return values of
>> the current functions are opposite of each other, but it should be
>> easy enough to update one of the callers.
>>
>> Sound reasonable?
>
> Potentially... I was even eyeing kernel/auditsc.c::audit_filter_rules()
> for re-factoring...
It's possible that we may be able to do some work on eliminating
duplication between the audit_filter_user()/audit_filter_type() and
audit_filter_rules(), but we'll always need audit_filter_rules()
simply because it can filter on more things, e.g. it has access to
object information.
I would suggest working on just audit_filter_user() and
audit_filter_type() right now so we can get something ready for
upstream before -rc5 or so, and then look into possible refactoring
with audit_filter_rules().
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH] audit: add fields to exclude filter by reusing user filter
From: Richard Guy Briggs @ 2016-06-03 20:24 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, linux-kernel
In-Reply-To: <CAHC9VhRNomeoJVxULVmAHiBMpavBVNC3rtbk2rce7U2RdVWqjg@mail.gmail.com>
On 16/06/03, Paul Moore wrote:
> On Wed, Jun 1, 2016 at 6:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > RFE: add additional fields for use in audit filter exclude rules
> > https://github.com/linux-audit/audit-kernel/issues/5
> >
> > Re-factor audit_filter_type() to use audit_filter_user_rules() to enable
> > exclude filter to additionally filter on PID, UID, GID, AUID,
> > LOGINUID_SET, SUBJ_*.
> >
> > Add check in audit_filter_user() to quit early if list is empty.
> >
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > kernel/auditfilter.c | 22 +++++++++-------------
> > 1 files changed, 9 insertions(+), 13 deletions(-)
>
> I like the consolidation between audit_filter_type() and
> audit_filter_user(), I like it so much I think we should take it
> further. Let's consolidate both functions into a single function (say
> audit_filter()?) and update the callers to use the new function. This
> shouldn't be hard as the only callers are audit_receive_msg() and
> audit_log_start(); you'll need to be careful as the return values of
> the current functions are opposite of each other, but it should be
> easy enough to update one of the callers.
>
> Sound reasonable?
Potentially... I was even eyeing kernel/auditsc.c::audit_filter_rules()
for re-factoring...
> > diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> > index 96c9a1b..515c752 100644
> > --- a/kernel/auditfilter.c
> > +++ b/kernel/auditfilter.c
> > @@ -1358,6 +1358,9 @@ int audit_filter_user(int type)
> > ret = 1; /* Audit by default */
> >
> > rcu_read_lock();
> > + if (list_empty(&audit_filter_list[AUDIT_FILTER_USER]))
> > + goto unlock_and_return;
> > +
> > list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_USER], list) {
> > rc = audit_filter_user_rules(&e->rule, type, &state);
> > if (rc) {
> > @@ -1366,13 +1369,14 @@ int audit_filter_user(int type)
> > break;
> > }
> > }
> > +unlock_and_return:
> > rcu_read_unlock();
> > -
> > return ret;
> > }
> >
> > int audit_filter_type(int type)
> > {
> > + enum audit_state state = AUDIT_DISABLED;
> > struct audit_entry *e;
> > int result = 0;
> >
> > @@ -1380,19 +1384,11 @@ int audit_filter_type(int type)
> > if (list_empty(&audit_filter_list[AUDIT_FILTER_TYPE]))
> > goto unlock_and_return;
> >
> > - list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_TYPE],
> > - list) {
> > - int i;
> > - for (i = 0; i < e->rule.field_count; i++) {
> > - struct audit_field *f = &e->rule.fields[i];
> > - if (f->type == AUDIT_MSGTYPE) {
> > - result = audit_comparator(type, f->op, f->val);
> > - if (!result)
> > - break;
> > - }
> > + list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_TYPE], list) {
> > + if (audit_filter_user_rules(&e->rule, type, &state) == 1) {
> > + result = 1;
> > + break;
> > }
> > - if (result)
> > - goto unlock_and_return;
> > }
> > unlock_and_return:
> > rcu_read_unlock();
> > --
> > 1.7.1
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
> --
> paul moore
> www.paul-moore.com
- RGB
^ permalink raw reply
* Re: [PATCH] audit: add fields to exclude filter by reusing user filter
From: Paul Moore @ 2016-06-03 19:32 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, linux-kernel
In-Reply-To: <3ff3a1c2837c8045bb54058effd11edd897b6412.1464810610.git.rgb@redhat.com>
On Wed, Jun 1, 2016 at 6:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> RFE: add additional fields for use in audit filter exclude rules
> https://github.com/linux-audit/audit-kernel/issues/5
>
> Re-factor audit_filter_type() to use audit_filter_user_rules() to enable
> exclude filter to additionally filter on PID, UID, GID, AUID,
> LOGINUID_SET, SUBJ_*.
>
> Add check in audit_filter_user() to quit early if list is empty.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/auditfilter.c | 22 +++++++++-------------
> 1 files changed, 9 insertions(+), 13 deletions(-)
I like the consolidation between audit_filter_type() and
audit_filter_user(), I like it so much I think we should take it
further. Let's consolidate both functions into a single function (say
audit_filter()?) and update the callers to use the new function. This
shouldn't be hard as the only callers are audit_receive_msg() and
audit_log_start(); you'll need to be careful as the return values of
the current functions are opposite of each other, but it should be
easy enough to update one of the callers.
Sound reasonable?
> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> index 96c9a1b..515c752 100644
> --- a/kernel/auditfilter.c
> +++ b/kernel/auditfilter.c
> @@ -1358,6 +1358,9 @@ int audit_filter_user(int type)
> ret = 1; /* Audit by default */
>
> rcu_read_lock();
> + if (list_empty(&audit_filter_list[AUDIT_FILTER_USER]))
> + goto unlock_and_return;
> +
> list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_USER], list) {
> rc = audit_filter_user_rules(&e->rule, type, &state);
> if (rc) {
> @@ -1366,13 +1369,14 @@ int audit_filter_user(int type)
> break;
> }
> }
> +unlock_and_return:
> rcu_read_unlock();
> -
> return ret;
> }
>
> int audit_filter_type(int type)
> {
> + enum audit_state state = AUDIT_DISABLED;
> struct audit_entry *e;
> int result = 0;
>
> @@ -1380,19 +1384,11 @@ int audit_filter_type(int type)
> if (list_empty(&audit_filter_list[AUDIT_FILTER_TYPE]))
> goto unlock_and_return;
>
> - list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_TYPE],
> - list) {
> - int i;
> - for (i = 0; i < e->rule.field_count; i++) {
> - struct audit_field *f = &e->rule.fields[i];
> - if (f->type == AUDIT_MSGTYPE) {
> - result = audit_comparator(type, f->op, f->val);
> - if (!result)
> - break;
> - }
> + list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_TYPE], list) {
> + if (audit_filter_user_rules(&e->rule, type, &state) == 1) {
> + result = 1;
> + break;
> }
> - if (result)
> - goto unlock_and_return;
> }
> unlock_and_return:
> rcu_read_unlock();
> --
> 1.7.1
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [PATCH 2/2] exclude filter: add support for user filter fields
From: Richard Guy Briggs @ 2016-06-01 22:58 UTC (permalink / raw)
To: linux-audit; +Cc: Richard Guy Briggs
In-Reply-To: <1464821889-3109-1-git-send-email-rgb@redhat.com>
RFE: add additional fields for use in audit filter exclude rules
https://github.com/linux-audit/audit-kernel/issues/5
Enable the exclude filter to additionally filter on PID, UID, GID, AUID,
LOGINUID_SET, SUBJ_*.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
docs/auditctl.8 | 2 +-
lib/libaudit.c | 21 ++++++++++++++++++---
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/docs/auditctl.8 b/docs/auditctl.8
index ceb6c40..540ff70 100644
--- a/docs/auditctl.8
+++ b/docs/auditctl.8
@@ -76,7 +76,7 @@ Add a rule to the syscall exit list. This list is used upon exit from a system c
Add a rule to the user message filter list. This list is used by the kernel to filter events originating in user space before relaying them to the audit daemon. It should be noted that the only fields that are valid are: uid, auid, gid, pid, subj_user, subj_role, subj_type, subj_sen, subj_clr, and msgtype. All other fields will be treated as non-matching. It should be understood that any event originating from user space from a process that has CAP_AUDIT_WRITE will be recorded into the audit trail. This means that the most likely use for this filter is with rules that have an action of never since nothing has to be done to allow events to be recorded.
.TP
.B exclude
-Add a rule to the event type exclusion filter list. This list is used to filter events that you do not want to see. For example, if you do not want to see any avc messages, you would using this list to record that. The message type that you do not wish to see is given with the msgtype field.
+Add a rule to the event type exclusion filter list. This list is used to filter events that you do not want to see. For example, if you do not want to see any avc messages, you would using this list to record that. Events can be excluded by process ID, user ID, group ID, login user ID, login user ID set, message type or subject context.
.RE
The following describes the valid \fIactions\fP for the rule:
diff --git a/lib/libaudit.c b/lib/libaudit.c
index 184bc65..cff2cd8 100644
--- a/lib/libaudit.c
+++ b/lib/libaudit.c
@@ -1393,9 +1393,24 @@ int audit_rule_fieldpair_data(struct audit_rule_data **rulep, const char *pair,
if ((field = audit_name_to_field(f)) < 0)
return -2;
- /* Exclude filter can be used only with MSGTYPE field */
- if (flags == AUDIT_FILTER_EXCLUDE && field != AUDIT_MSGTYPE)
- return -12;
+ /* Exclude filter can be used only with MSGTYPE and cred fields */
+ if (flags == AUDIT_FILTER_EXCLUDE)
+ switch(field) {
+ case AUDIT_PID:
+ case AUDIT_UID:
+ case AUDIT_GID:
+ case AUDIT_LOGINUID:
+ case AUDIT_LOGINUID_SET:
+ case AUDIT_MSGTYPE:
+ case AUDIT_SUBJ_USER:
+ case AUDIT_SUBJ_ROLE:
+ case AUDIT_SUBJ_TYPE:
+ case AUDIT_SUBJ_SEN:
+ case AUDIT_SUBJ_CLR:
+ break;
+ default:
+ return -12;
+ }
rule->fields[rule->field_count] = field;
rule->fieldflags[rule->field_count] = op;
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] add support for loginuid_set using macro AUDIT_LOGINUID_SET
From: Richard Guy Briggs @ 2016-06-01 22:58 UTC (permalink / raw)
To: linux-audit; +Cc: Richard Guy Briggs
In-Reply-To: <1464821889-3109-1-git-send-email-rgb@redhat.com>
See upstream kernel commits:
780a7654cee8d61819512385e778e4827db4bfbc
041d7b98ffe59c59fdd639931dea7d74f9aa9a59
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
lib/fieldtab.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/fieldtab.h b/lib/fieldtab.h
index bf48c95..107157d 100644
--- a/lib/fieldtab.h
+++ b/lib/fieldtab.h
@@ -31,6 +31,8 @@ _S(AUDIT_SGID, "sgid" )
_S(AUDIT_FSGID, "fsgid" )
_S(AUDIT_LOGINUID, "auid" )
_S(AUDIT_LOGINUID, "loginuid" )
+_S(AUDIT_LOGINUID_SET, "auid_set" )
+_S(AUDIT_LOGINUID_SET, "loginuid_set" )
_S(AUDIT_PERS, "pers" )
_S(AUDIT_ARCH, "arch" )
_S(AUDIT_MSGTYPE, "msgtype" )
--
1.7.1
^ permalink raw reply related
* [PATCH 0/2] add support for more fields to the exclude filter
From: Richard Guy Briggs @ 2016-06-01 22:58 UTC (permalink / raw)
To: linux-audit; +Cc: Richard Guy Briggs
When support for avoiding in-band signals to indicate an unset loginuid
was added to the kernel, userspace was neglected, so add them here as a
prerequisite to enable their use in the exclude filter:
See upstream kernel commits:
780a7654cee8d61819512385e778e4827db4bfbc
041d7b98ffe59c59fdd639931dea7d74f9aa9a59
The rest to support additional fields for the exclude filter is in the
second patch.
RFE: add additional fields for use in audit filter exclude rules
https://github.com/linux-audit/audit-kernel/issues/5
Richard Guy Briggs (2):
add support for loginuid_set using macro AUDIT_LOGINUID_SET
exclude filter: add support for user filter fields
docs/auditctl.8 | 2 +-
lib/fieldtab.h | 2 ++
lib/libaudit.c | 21 ++++++++++++++++++---
3 files changed, 21 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH] audit: add fields to exclude filter by reusing user filter
From: Richard Guy Briggs @ 2016-06-01 22:50 UTC (permalink / raw)
To: linux-audit, linux-kernel; +Cc: Richard Guy Briggs, sgrubb, pmoore, eparis
RFE: add additional fields for use in audit filter exclude rules
https://github.com/linux-audit/audit-kernel/issues/5
Re-factor audit_filter_type() to use audit_filter_user_rules() to enable
exclude filter to additionally filter on PID, UID, GID, AUID,
LOGINUID_SET, SUBJ_*.
Add check in audit_filter_user() to quit early if list is empty.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/auditfilter.c | 22 +++++++++-------------
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 96c9a1b..515c752 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1358,6 +1358,9 @@ int audit_filter_user(int type)
ret = 1; /* Audit by default */
rcu_read_lock();
+ if (list_empty(&audit_filter_list[AUDIT_FILTER_USER]))
+ goto unlock_and_return;
+
list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_USER], list) {
rc = audit_filter_user_rules(&e->rule, type, &state);
if (rc) {
@@ -1366,13 +1369,14 @@ int audit_filter_user(int type)
break;
}
}
+unlock_and_return:
rcu_read_unlock();
-
return ret;
}
int audit_filter_type(int type)
{
+ enum audit_state state = AUDIT_DISABLED;
struct audit_entry *e;
int result = 0;
@@ -1380,19 +1384,11 @@ int audit_filter_type(int type)
if (list_empty(&audit_filter_list[AUDIT_FILTER_TYPE]))
goto unlock_and_return;
- list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_TYPE],
- list) {
- int i;
- for (i = 0; i < e->rule.field_count; i++) {
- struct audit_field *f = &e->rule.fields[i];
- if (f->type == AUDIT_MSGTYPE) {
- result = audit_comparator(type, f->op, f->val);
- if (!result)
- break;
- }
+ list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_TYPE], list) {
+ if (audit_filter_user_rules(&e->rule, type, &state) == 1) {
+ result = 1;
+ break;
}
- if (result)
- goto unlock_and_return;
}
unlock_and_return:
rcu_read_unlock();
--
1.7.1
^ permalink raw reply related
* Re: krb5 issues
From: Steve Grubb @ 2016-05-26 20:12 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <5744603D.9020504@kenbass.com>
On Tuesday, May 24, 2016 10:07:57 AM Ken Bass wrote:
> On 05/23/2016 11:21 AM, Ken Bass wrote:
> > I enabled krb5 in my audisp-remote and audispd-remote reports "GSS-API
> > error sending token length" and fails to log remotely.
> >
> > If I reboot the destination auditd server AFTER the clients are
> > running it appears to work. But if I reboot any clients machine,
> > logging from that rebooted machine fails.
> > I created my service principals using freeipa - all systems are clean
> > installs of Centos 7.2.
> >
> > For now, I disabled krb5, but that is not a good solution.
>
> After disabling krb5 and rebooting the client servers several times I am
> seeing similar problems. I am seeing a dozen or so log file entries of
>
> Too many connections from 10.10.10.10:39107 - rejected
>
> I only have 2 clients and all I am doing is rebooting them. I tried
> increasing the tcp_listen_queue to 20 (from the default of 5) which made
> no difference.
>
> I seem to have traced it to needing to specify the tcp_client_ports to
> 60 rather than using whatever the default was. What would have been
> blocking this?
I think 60 is the default in the audit config files. IPtables/firewalld needs to
be opened and selinux is expecting port 60.
> And why only when the clients are rebooted second does it
> fail?
>
> After changing this the Kerberos works, so I think the 'error sending
> token length' is basically the same message but in a different code path
> to indicate the connection is rejected / cannot write to the TCP socket.
>
> Was the commented out ##tcp_client_ports parameter supposed to be
> changed by the end user? Was the defaults supposed to work?
There is some discussion of this in the man pages. Ports < 1024 are
privileged. If its higher they you can have someone dump spoofed log events in
the aggregating server. So, setting the port low gives a small amount of trust
that it might be real events from a real system. You should also use
tcp_wrappers to make sure specific systems are sending events. Kerberos though
is supposed to help ensure that you have even more trust.
-Steve
> On a related note, using krb5 causes a problem with selinux. Unless I
> disable it (or figure out a rule) auditd fails to start because it is
> denied permission to create /var/tmp/auditd_0 kerberos replay cache file.
> Is there a rule or procedure to properly fix that?
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: krb5 issues
From: Steve Grubb @ 2016-05-26 20:04 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <57471335.3010406@kenbass.com>
On Thursday, May 26, 2016 11:16:05 AM Ken Bass wrote:
> On 05/24/2016 10:07 AM, Ken Bass wrote:
> > On a related note, using krb5 causes a problem with selinux. Unless I
> > disable it (or figure out a rule) auditd fails to start because it is
> > denied permission to create /var/tmp/auditd_0 kerberos replay cache file.
> > Is there a rule or procedure to properly fix that?
>
> Is there somewhere to file a bug report for this at?
You could use Bugzilla and file against selinux-policy.
> Obviously the selinux is not being setup for auditd to manage the
> /var/tmp/auditd_0 file when krb5 is enabled. Using Centos 7.2.
I think its used so rarely that no one has noticed.
-Steve
^ permalink raw reply
* RE: audit.log with logrotate on CentOS
From: Warron S French @ 2016-05-26 17:30 UTC (permalink / raw)
To: Ed Christiansen MS, linux-audit@redhat.com
In-Reply-To: <57471DF3.50907@ll.mit.edu>
Hi Ed, thanks for your input. You have basically confirmed my suspicion. Apparently I failed to mention (I asked to this forum yesterday the same question and never saw a response even that my post made it) that I am asking in the CentOS Forums as well.
Currently there is no direction from the CentOS Forums; but they have engaged my question and attempted to start looking into this issue. Someone mentioned that there is a known bug for logrotate in CentOS-6.7, and of course that the version that I am running.
I am liking your approach to the solution a little more though. Maybe set max_log_file to 4096 in /etc/audit/auditd.conf and then run a script that looks for all...
/var/log/audit/audit.log files not already ending in .bz2 already.
Warron French, MBA, SCSA
-----Original Message-----
From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Ed Christiansen MS
Sent: Thursday, May 26, 2016 12:02 PM
To: linux-audit@redhat.com
Subject: Re: audit.log with logrotate on CentOS
probably the easiest way to do that is:
1. remove logrotate from /etc/cron.daily and put into root crontab:
1 0 * * 1 /usr/bin/logrotate
2. write a script that implements the other logic and run it from root cron a few minutes later.
I'd run a few tests with the logrotate to see how long it actually takes, but that's because I can be a little extra paranoid.
There really isn't a way to ensure that you always get less than 4GB if you rotate weekly. You can approximate this with this: maxsize 4G, which will rotate when the logfile reaches 4GB.
On 5/26/2016 11:29 AM, Warron S French wrote:
> Hello, I am using CentOS-6.7 and I have implemented the audispatch
> configurations and they are working pretty nicely.
>
> One of the requirements I have to satisfy, somehow, is 7 years
> retention of logdata. That is an enormous amount of data to store on
> /var/log/audit filesystem - even for a single server and 6
> workstations combined. I have a 2.0TB sized filesystem in place
> already - but it won't be enough to satisfy the retention of 7 years of data.
>
> So, my plan is a tiered approach to managing the log files if someone
> could please advise on how best to implement the following:
>
> Rotate log files every single Monday morning at 12:01am.
>
> When I rotate them place the dateext extension (for example
> *20160523*) to indicate all date is up to that date extension.
>
> When I rotate them, I also want to bzip2 compress them (I have the
> binaries on the server).
>
> Only keep at most 15 of those rotated (date-string extension applied)
> compressed files so that I can once a month take over a DVD burner and
> burn the files to DvD; however, I want to ensure that the files never
> grow any larger than the size of a normal (*not dual-layer*) DvD media
> which is typically 4.70GB (so I am estimating a 4.0GB limitation) that
> is after rotation and compression.
>
> Can someone help me figure out how to most appropriately (and more
> importantly) and successfully implement this configuration?
>
> *Warron French, MBA, SCSA*
>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: audit.log with logrotate on CentOS
From: Ed Christiansen MS @ 2016-05-26 16:01 UTC (permalink / raw)
To: linux-audit@redhat.com
In-Reply-To: <BY1PR09MB0887EE63A6F82A957AADC6AAC7410@BY1PR09MB0887.namprd09.prod.outlook.com>
probably the easiest way to do that is:
1. remove logrotate from /etc/cron.daily and put into root crontab:
1 0 * * 1 /usr/bin/logrotate
2. write a script that implements the other logic and run it from root
cron a few minutes later.
I'd run a few tests with the logrotate to see how long it actually
takes, but that's because I can be a little extra paranoid.
There really isn't a way to ensure that you always get less than 4GB if
you rotate weekly. You can approximate this with this: maxsize 4G,
which will rotate when the logfile reaches 4GB.
On 5/26/2016 11:29 AM, Warron S French wrote:
> Hello, I am using CentOS-6.7 and I have implemented the audispatch
> configurations and they are working pretty nicely.
>
> One of the requirements I have to satisfy, somehow, is 7 years retention
> of logdata. That is an enormous amount of data to store on
> /var/log/audit filesystem – even for a single server and 6 workstations
> combined. I have a 2.0TB sized filesystem in place already – but it
> won’t be enough to satisfy the retention of 7 years of data.
>
> So, my plan is a tiered approach to managing the log files if someone
> could please advise on how best to implement the following:
>
> Rotate log files every single Monday morning at 12:01am.
>
> When I rotate them place the dateext extension (for example *20160523*)
> to indicate all date is up to that date extension.
>
> When I rotate them, I also want to bzip2 compress them (I have the
> binaries on the server).
>
> Only keep at most 15 of those rotated (date-string extension applied)
> compressed files so that I can once a month take over a DVD burner and
> burn the files to DvD; however, I want to ensure that the files never
> grow any larger than the size of a normal (*not dual-layer*) DvD media
> which is typically 4.70GB (so I am estimating a 4.0GB limitation) that
> is after rotation and compression.
>
> Can someone help me figure out how to most appropriately (and more
> importantly) and successfully implement this configuration?
>
> *Warron French, MBA, SCSA*
>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
^ permalink raw reply
* Re: Better error message in auditd wanted
From: Christian Boltz @ 2016-05-26 15:56 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1919045.4D9BsBxTjm@x2>
Hello,
Am Donnerstag, 26. Mai 2016, 10:54:43 CEST schrieb Steve Grubb:
> On Thursday, May 26, 2016 03:03:11 PM Christian Boltz wrote:
> > I'd like to ask for a more useful error message in auditd ;-)
> >
> > If audit.log is world-readable (chmod 644 [1]), auditd refuses to
> > start.
> >
> > The problem is that it gives a completely useless error message when
> > doing that:
> >
> > # systemctl status auditd.service
> > ● auditd.service - Security Auditing Service
...
> > ExecStart=/sbin/auditd -n (code=exited, status=6)
...
> > Exit status 6/NOTCONFIGURED is not really helpful and not even a
> > correct) information :-(
> >
> > After searching around, reading the manpage etc. I tried to start
> > auditd manually in debug mode:
> >
> >
> > # auditd -f
> > Config file /etc/audit/auditd.conf opened for parsing
> > log_file_parser called with: /var/log/audit/audit.log
> > /var/log/audit/audit.log permissions should be 0600 or 0640
> > The audit daemon is exiting.
> >
> >
> > Now _that_ is a useful message and clearly states what the problem
> > is.
> >
> > Can you please change auditd so that it prints or logs this useful
> > message independent of the given parameters?
>
> This is the code you are talking about:
> https://fedorahosted.org/audit/browser/trunk/src/auditd-config.c#L618
>
> It is LOG_ERR, so it should be captured by syslog. Not sure what else
> can be done.
You are right, the message is in syslog - but not in the
systemctl status auditd
output.
I just played a bit with the auditd.service file (with 644 file
permissions on audit.log).
The original auditd.service as shipped in the openSUSE package has
ExecStart=/sbin/auditd -n
and leads to the useless error message I reported.
I changed auditd.service to contain
ExecStart=/sbin/auditd -f
which made the status output more verbose:
# systemctl restart auditd.service
Job for auditd.service failed because the control process exited with error code. See "systemctl status auditd.service" and "journalctl -xe" for details.
# systemctl status auditd.service
● auditd.service - Security Auditing Service
Loaded: loaded (/etc/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Do 2016-05-26 17:16:46 CEST; 2s ago
Process: 22254 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
Process: 22251 ExecStart=/sbin/auditd -f (code=exited, status=6)
Main PID: 22251 (code=exited, status=6)
Mai 26 17:16:46 tux auditd[22251]: /var/log/audit/audit.log permissions should be 0600 or 0640
Mai 26 17:16:46 tux auditd[22251]: The audit daemon is exiting.
Mai 26 17:16:46 tux systemd[1]: Starting Security Auditing Service...
Mai 26 17:16:46 tux systemd[1]: auditd.service: Main process exited, code=exited, status=6/NOTCONFIGURED
Mai 26 17:16:46 tux augenrules[22254]: /sbin/augenrules: No change
Mai 26 17:16:46 tux augenrules[22254]: No rules
Mai 26 17:16:46 tux systemd[1]: Failed to start Security Auditing Service.
Mai 26 17:16:46 tux systemd[1]: auditd.service: Unit entered failed state.
Mai 26 17:16:46 tux systemd[1]: auditd.service: Failed with result 'exit-code'.
For comparison, let me repeat the output with auditd -n:
# systemctl restart auditd.service
Job for auditd.service failed because the control process exited with error code. See "systemctl status auditd.service" and "journalctl -xe" for details.
# systemctl status auditd.service
● auditd.service - Security Auditing Service
Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Do 2016-05-26 17:18:00 CEST; 2s ago
Process: 22374 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
Process: 22370 ExecStart=/sbin/auditd -n (code=exited, status=6)
Main PID: 22370 (code=exited, status=6)
Mai 26 17:18:00 tux systemd[1]: Starting Security Auditing Service...
Mai 26 17:18:00 tux augenrules[22374]: /sbin/augenrules: No change
Mai 26 17:18:00 tux augenrules[22374]: No rules
Mai 26 17:18:00 tux systemd[1]: auditd.service: Main process exited, code=exited, status=6/NOTCONFIGURED
Mai 26 17:18:00 tux systemd[1]: Failed to start Security Auditing Service.
Mai 26 17:18:00 tux systemd[1]: auditd.service: Unit entered failed state.
Mai 26 17:18:00 tux systemd[1]: auditd.service: Failed with result 'exit-code'.
As you can see, the systemctl status output with -f has two more lines,
and one of them is the message I want to see ;-)
The syslog contains the "permissions should be 600 or 640" with both
-f and -n, so this "only" affects the systemctl status output.
I'm afraid this has to do with systemd and journald interaction which
makes things more interesting[tm].
AFAIK systemd grabs STDERR output for systemctl status, which might
explain why the additional log lines are visible when using -f.
However, systemd and journald should also grab the syslog messages.
I have no idea why this doesn't happen here - maybe you need to ask a
systemd expert to clarify this.
For completeness: The complete auditd.service file (as shipped by the
openSUSE package) is:
# /usr/lib/systemd/system/auditd.service
[Unit]
Description=Security Auditing Service
DefaultDependencies=no
After=local-fs.target systemd-tmpfiles-setup.service
Conflicts=shutdown.target
Before=sysinit.target shutdown.target
ConditionKernelCommandLine=!audit=0
[Service]
ExecStart=/sbin/auditd -n
## To not use augenrules, copy this file to /etc/systemd/system/auditd.service
## and comment/delete the next line and uncomment the auditctl line.
## NOTE: augenrules expect any rules to be added to /etc/audit/rules.d/
ExecStartPost=-/sbin/augenrules --load
#ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target
Regards,
Christian Boltz
--
My concern is that Flash seems to be closer to Swiss cheese than
anything else. [Vahis in evergreen]
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* audit.log with logrotate on CentOS
From: Warron S French @ 2016-05-26 15:29 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 1416 bytes --]
Hello, I am using CentOS-6.7 and I have implemented the audispatch configurations and they are working pretty nicely.
One of the requirements I have to satisfy, somehow, is 7 years retention of logdata. That is an enormous amount of data to store on /var/log/audit filesystem - even for a single server and 6 workstations combined. I have a 2.0TB sized filesystem in place already - but it won't be enough to satisfy the retention of 7 years of data.
So, my plan is a tiered approach to managing the log files if someone could please advise on how best to implement the following:
Rotate log files every single Monday morning at 12:01am.
When I rotate them place the dateext extension (for example 20160523) to indicate all date is up to that date extension.
When I rotate them, I also want to bzip2 compress them (I have the binaries on the server).
Only keep at most 15 of those rotated (date-string extension applied) compressed files so that I can once a month take over a DVD burner and burn the files to DvD; however, I want to ensure that the files never grow any larger than the size of a normal (not dual-layer) DvD media which is typically 4.70GB (so I am estimating a 4.0GB limitation) that is after rotation and compression.
Can someone help me figure out how to most appropriately (and more importantly) and successfully implement this configuration?
Warron French, MBA, SCSA
[-- Attachment #1.2: Type: text/html, Size: 3903 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: krb5 issues
From: Ken Bass @ 2016-05-26 15:16 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <5744603D.9020504@kenbass.com>
On 05/24/2016 10:07 AM, Ken Bass wrote:
>
> On a related note, using krb5 causes a problem with selinux. Unless I
> disable it (or figure out a rule) auditd fails to start because it is
> denied permission to create /var/tmp/auditd_0 kerberos replay cache file.
> Is there a rule or procedure to properly fix that?
Is there somewhere to file a bug report for this at? Obviously the
selinux is not being setup for auditd to manage the /var/tmp/auditd_0
file when krb5 is enabled. Using Centos 7.2.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox