* Re: Strings encoding
From: Steve Grubb @ 2016-03-22 13:46 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <ncqt4j$vn1$1@ger.gmane.org>
Hello,
On Tuesday, March 22, 2016 09:44:19 AM Lev Stipakov wrote:
> The string values can be either enclosed in quotation marks or
> hex-encoded. Is it safe to assume that sequence of bytes after hex
> decoding is always utf-8 encoded string?
There are no guarantees what they are. This is used whenever the user could
have controlled the input in a way to trick the audit parser. And in one case
the hex encoding is an actual socket address structure.
-Steve
^ permalink raw reply
* audit.rules setting
From: Warron S French @ 2016-03-22 12:55 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 214 bytes --]
Does the "-e 2" have to be the last line of the audit.rules file?
Does it have to be listed prior to all of the syscalls and watches configured in the file?
Thank you in advance,
Warron French, MBA, SCSA
[-- Attachment #1.2: Type: text/html, Size: 2290 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Strings encoding
From: Lev Stipakov @ 2016-03-22 7:44 UTC (permalink / raw)
To: linux-audit
Hello,
The string values can be either enclosed in quotation marks or
hex-encoded. Is it safe to assume that sequence of bytes after hex
decoding is always utf-8 encoded string?
-Lev
^ permalink raw reply
* Re: Adding New field into audit records
From: Burn Alting @ 2016-03-21 8:31 UTC (permalink / raw)
To: Deepika Sundar; +Cc: linux-audit
In-Reply-To: <CAHj_pNefgfPxG+mAUqHBLHVQNW_VUnb-bGQYG4M1A7VM6sQh3Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2218 bytes --]
On Mon, 2016-03-21 at 12:14 +0530, Deepika Sundar wrote:
> Hi All,
>
>
>
> Audit log contains already defined <name>=<value> pair in each
> record.Is there any possibility to add new field <name>=<value>? and
> Is there any compatibility issues associated with it ? please specify
> if any.
We discussed this last month as per below. So what do you want to do?
On Friday, February 12, 2016 12:06:54 AM Burn Alting wrote:
> Steve,
>
> Perhaps we could update the above document to advise users
what they
> should offer in such a proposal.
Good point. Usually they come to the list and say I am working
on a daemon
that needs to write something to the audit log whenever this
kind of thing
happens. How should I record it.
This leads to a better conversation because not everything is a
candidate for
the audit logs. That doesn't mean it doesn't need to be
recorded, it just
means it needs to go somewhere else.
For example, tcp_wrappers can reject connections. Should that go
into audit
logs automatically? No way. Same with web application access
control. These
are important enough to be logged, but they belong in an
application log.
> Perhaps further, we could offer a generic solution on how one
could
> define a 'non-public' field name. That is, a 'non-public'
field is one
> which could not, via it's nomenclature, conflict with a
current or
> future 'public' (aka published) field name. Such non-public
fields could
> then be used by capability that only needs the audit source
and audit
> consumer to be aware of the field.
That's a good point. I'm pretty sure 'private-' will never be
used for a prefix
to any field. That said, if this is going into an existing
event, we really
need to have a discussion about that. This affects all third
party's that try
to make sense of the audit logs,
-Steve
[-- Attachment #1.2: Type: text/html, Size: 2542 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Adding New field into audit records
From: Deepika Sundar @ 2016-03-21 6:44 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 220 bytes --]
Hi All,
Audit log contains already defined <name>=<value> pair in each record.Is
there any possibility to add new field <name>=<value>? and Is there any
compatibility issues associated with it ? please specify if any.
[-- Attachment #1.2: Type: text/html, Size: 294 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: AUDIT changes - true sense of security
From: Steve Grubb @ 2016-03-18 15:46 UTC (permalink / raw)
To: Warron S French; +Cc: linux-audit@redhat.com
In-Reply-To: <BY1PR09MB0887D2F49855C831720CA4FBC78C0@BY1PR09MB0887.namprd09.prod.outlook.com>
On Friday, March 18, 2016 03:45:20 PM Warron S French wrote:
> Hello sir,
> The command with the '-l' argument, is that auditctl?
> The command with the '-s' argument... what is that one called, auditd?
These are both auditctl commands. The other command that you will need to read
up on is ausearch which is used to examine the resulting logs.
-Steve
> Thanks for replying so quickly, sorry for being a nag.
>
> Warron French, MBA, SCSA
> The Aerospace Corporation
>
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Friday, March 18, 2016 9:56 AM
> To: linux-audit@redhat.com
> Cc: Warron S French <warron.s.french@aero.org>
> Subject: Re: AUDIT changes - true sense of security
>
> On Friday, March 18, 2016 01:14:31 PM Warron S French wrote:
> > I have an issue, I believe, and I am asking for help on how to
> > properly address/assess it.
> >
> > I have been given guidance in support of auditing on CentOS-6.x systems:
> >
> > 1. To place various watch (-w) and action (-a) rules into place.
> >
> > 2. Make certain the configurations are immutable.
> >
> > Sometimes I have to add more rules, so I do that. However, I am not
> > certain if the rules are working properly, and I do know that I have
> > broken the auditd init-scripts on my systems a few times, and just
> > commented out the offending audit controls to work around/fix this very
> > type of problem.
> While you are experimenting, do not put in the -e 2 configuration option.
>
> > What I need to know is, since the configurations have to be immutable
> > ( with the -e 2) how can I properly start the audit service, and
> > without any inkling of a doubt be certain that the rules are in place
> > and are functioning properly?
>
> There is a rule listing command, -l, that will dump what the kernel has
> loaded. There is also a status command, -s, that will tell you if audit is
> enabled. If the rules are loaded and audit is enabled, its working.
> > Also, being a total novice, how can I test/trigger audit log actions
> > on watch and action rules to see that the rules are configured properly?
>
> If its a watch, then accessing the file and running ausearch should do it.
> If you have a syscall rule, then you have to trigger the syscall either by
> using a program or creating one.
> > Finally, is there a tool that will do a sanity check on the audit.rules
> > file?
> auditctl reports any problems that it sees with the rules.
>
> > Or is the only option to attempt to restart the auditd service, and
> > think "It started, it worked!" is acceptable?
>
> List the rules and status the audit subsystem.
>
> -Steve
^ permalink raw reply
* RE: AUDIT changes - true sense of security
From: Warron S French @ 2016-03-18 15:45 UTC (permalink / raw)
To: Steve Grubb, linux-audit@redhat.com
In-Reply-To: <2847728.hyf82qzeWv@x2>
Hello sir,
The command with the '-l' argument, is that auditctl?
The command with the '-s' argument... what is that one called, auditd?
Thanks for replying so quickly, sorry for being a nag.
Warron French, MBA, SCSA
The Aerospace Corporation
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Friday, March 18, 2016 9:56 AM
To: linux-audit@redhat.com
Cc: Warron S French <warron.s.french@aero.org>
Subject: Re: AUDIT changes - true sense of security
On Friday, March 18, 2016 01:14:31 PM Warron S French wrote:
> I have an issue, I believe, and I am asking for help on how to
> properly address/assess it.
>
> I have been given guidance in support of auditing on CentOS-6.x systems:
>
> 1. To place various watch (-w) and action (-a) rules into place.
>
> 2. Make certain the configurations are immutable.
>
> Sometimes I have to add more rules, so I do that. However, I am not
> certain if the rules are working properly, and I do know that I have
> broken the auditd init-scripts on my systems a few times, and just
> commented out the offending audit controls to work around/fix this very type of problem.
While you are experimenting, do not put in the -e 2 configuration option.
>
>
> What I need to know is, since the configurations have to be immutable
> ( with the -e 2) how can I properly start the audit service, and
> without any inkling of a doubt be certain that the rules are in place
> and are functioning properly?
There is a rule listing command, -l, that will dump what the kernel has loaded. There is also a status command, -s, that will tell you if audit is enabled. If the rules are loaded and audit is enabled, its working.
> Also, being a total novice, how can I test/trigger audit log actions
> on watch and action rules to see that the rules are configured properly?
If its a watch, then accessing the file and running ausearch should do it. If you have a syscall rule, then you have to trigger the syscall either by using a program or creating one.
> Finally, is there a tool that will do a sanity check on the audit.rules file?
auditctl reports any problems that it sees with the rules.
> Or is the only option to attempt to restart the auditd service, and
> think "It started, it worked!" is acceptable?
List the rules and status the audit subsystem.
-Steve
^ permalink raw reply
* Re: AUDIT changes - true sense of security
From: Steve Grubb @ 2016-03-18 13:55 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <BY1PR09MB088799C76DC1A164BEF95168C78C0@BY1PR09MB0887.namprd09.prod.outlook.com>
On Friday, March 18, 2016 01:14:31 PM Warron S French wrote:
> I have an issue, I believe, and I am asking for help on how to properly
> address/assess it.
>
> I have been given guidance in support of auditing on CentOS-6.x systems:
>
> 1. To place various watch (-w) and action (-a) rules into place.
>
> 2. Make certain the configurations are immutable.
>
> Sometimes I have to add more rules, so I do that. However, I am not
> certain if the rules are working properly, and I do know that I have broken
> the auditd init-scripts on my systems a few times, and just commented out
> the offending audit controls to work around/fix this very type of problem.
While you are experimenting, do not put in the -e 2 configuration option.
>
>
> What I need to know is, since the configurations have to be immutable ( with
> the -e 2) how can I properly start the audit service, and without any
> inkling of a doubt be certain that the rules are in place and are
> functioning properly?
There is a rule listing command, -l, that will dump what the kernel has
loaded. There is also a status command, -s, that will tell you if audit is
enabled. If the rules are loaded and audit is enabled, its working.
> Also, being a total novice, how can I test/trigger audit log actions on
> watch and action rules to see that the rules are configured properly?
If its a watch, then accessing the file and running ausearch should do it. If
you have a syscall rule, then you have to trigger the syscall either by using
a program or creating one.
> Finally, is there a tool that will do a sanity check on the audit.rules file?
auditctl reports any problems that it sees with the rules.
> Or is the only option to attempt to restart the auditd service, and think
> "It started, it worked!" is acceptable?
List the rules and status the audit subsystem.
-Steve
^ permalink raw reply
* AUDIT changes - true sense of security
From: Warron S French @ 2016-03-18 13:14 UTC (permalink / raw)
To: Linux-Audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 1516 bytes --]
Hello all,
I do work that requires me to configure auditing on my systems. I am a relative novice to the audit configurations in most operating systems.
I have an issue, I believe, and I am asking for help on how to properly address/assess it.
I have been given guidance in support of auditing on CentOS-6.x systems:
1. To place various watch (-w) and action (-a) rules into place.
2. Make certain the configurations are immutable.
Sometimes I have to add more rules, so I do that. However, I am not certain if the rules are working properly, and I do know that I have broken the auditd init-scripts on my systems a few times, and just commented out the offending audit controls to work around/fix this very type of problem.
What I need to know is, since the configurations have to be immutable ( with the -e 2) how can I properly start the audit service, and without any inkling of a doubt be certain that the rules are in place and are functioning properly?
Also, being a total novice, how can I test/trigger audit log actions on watch and action rules to see that the rules are configured properly?
Finally, is there a tool that will do a sanity check on the audit.rules file? Or is the only option to attempt to restart the auditd service, and think "It started, it worked!" is acceptable?
I just don't want a false sense of security, I also don't want a nagging sense of paranoia.
Thank you,
Warron French, MBA, SCSA
The Aerospace Corporation
[-- Attachment #1.2: Type: text/html, Size: 6806 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [GIT PULL] Audit patches for 4.6
From: Paul Moore @ 2016-03-17 20:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-audit, linux-kernel
Hi Linus,
A small set of patches for audit this time; just three in total and one is a
spelling fix. The two patches with actual content are designed to help
prevent new instances of auditd from displacing an existing, functioning
auditd and to generate a log of the attempt. Not to worry, dead/stuck auditd
instances can still be replaced by a new instance without problem.
Nothing controversial, and everything passes our regression suite; please pull
for Linux 4.6.
Thanks,
-Paul
---
The following changes since commit cb74ed278f8054fddf79ed930495b9e214f7c7b2:
audit: always enable syscall auditing when supported and audit is enabled
(2016-01-13 09:18:55 -0500)
are available in the git repository at:
git://git.infradead.org/users/pcmoore/audit stable-4.6
for you to fetch changes up to fd97646b05957348e01be3d9de5c3d979b25c819:
audit: Fix typo in comment (2016-02-08 11:25:39 -0500)
----------------------------------------------------------------
Richard Guy Briggs (2):
audit: stop an old auditd being starved out by a new auditd
audit: log failed attempts to change audit_pid configuration
Wei Yuan (1):
audit: Fix typo in comment
include/uapi/linux/audit.h | 1 +
kernel/audit.c | 20 +++++++++++++++++++-
kernel/audit_watch.c | 2 +-
kernel/auditfilter.c | 6 +++---
4 files changed, 24 insertions(+), 5 deletions(-)
--
paul moore
security @ redhat
^ permalink raw reply
* RE: auditd and redhat cluster
From: Maupertuis Philippe @ 2016-03-09 9:44 UTC (permalink / raw)
To: burn@swtf.dyndns.org, Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <1456867529.5021.72.camel@swtf.swtf.dyndns.org>
Sorry for the delayed answer.
We restarted auditd on both node of the cluster after taking snapshot with perf top several time before and after.
The auditd processes were higher on the passive node (15% together) but it's probably a sampling effect since the server was mostly idle.
On the active node , audit_filter_rules was around 1% and get_task_cred around 0.8%.
I will try to replicate the settings in a test environment to have more leeway in playing with the rules.
Regards
Philippe
-----Message d'origine-----
De : Burn Alting [mailto:burn@swtf.dyndns.org]
Envoyé : mardi 1 mars 2016 22:25
À : Steve Grubb
Cc : linux-audit@redhat.com; Maupertuis Philippe
Objet : Re: auditd and redhat cluster
Philippe,
What does a perf top show?
Do you see get_task_cred or audit_filter_rules as high consumers? If they are high, then try turning off the monitoring of the /tmp, /dev/shm and /var/lock/lvm trees or if appropriate, switch to monitoring via a path directive if you don't need to monitor the entire tree.
Steve, Paul,
I have yet to put together a bug report, or researched to see if the problem exists upstream, but have discovered recursive directory rules can be expensive on the kernel. The rules below on a system running rabbitmq can see get_task_cred and audit_filter_rules above 10% each.
-w /etc/pam.d -p wa -k PAM_Mods
-w /boot -k BOOT_Mods
-w /boot/grub/grub.conf -p war -k BOOT_Mods -w /etc/security -p wa -k Security_Mods -w /etc/sysconfig -p wa -k Sysconfig_Mods -w /etc/ld.so.conf.d -p wa -k Library_Mods -w /etc/inittab -p wa -k StartUp_Mods -w /etc/rc.d -p wa -k StartUp_Mods
Regards
On Tue, 2016-03-01 at 09:14 -0500, Steve Grubb wrote:
> On Tuesday, March 01, 2016 02:57:45 PM Maupertuis Philippe wrote:
> > The kernel is : 2.6.32-573.12.1.el6.x86_64 And the whole
> > audit.rules file is :
>
> <snip>
>
> > During the hour preceding the fence we got these events from the
> > passive node Key Summary Report =========================== total
> > key ===========================
> > 891 system_commands (ping)
> >
> > And on the active node :
> >
> > Key Summary Report
> > ===========================
> > total key
> > ===========================
> > 1330 system_commands
> > 286 deletion
> >
> > I am going to follow your advice and to open a call with redhat.
> > Anyway, I am interested in knowing if auditd has been reported to
> > cause trouble without generating many events.
>
> Those numbers work out to 27 events per minute. That's not really a
> lot of events. To see if its the rules or auditd causing the iowait,
> you might set the logging format to NOLOG. This will discard events
> rather than log them. If you still have iowait, its something to do
> with the rules. If that cleared it up, then auditd might be the source. Either way, put the format back to raw.
>
> I did some benchmarking of auditd over the holidays and posted some
> results
> here:
>
> https://www.redhat.com/archives/linux-audit/2015-December/msg00061.htm
> l
>
> I'd recommend:
>
> flush = incremental
> freq = 100
>
> for a modest performance improvement.
>
> -Steve
>
>
> > -----Message d'origine-----
> > De : Paul Moore [mailto:paul@paul-moore.com] Envoyé : mardi 1 mars
> > 2016 14:25 À : Maupertuis Philippe Cc : linux-audit@redhat.com Objet
> > : Re: auditd and redhat cluster
> >
> > On Mon, Feb 29, 2016 at 7:45 AM, Maupertuis Philippe
> <philippe.maupertuis@worldline.com> wrote:
> > > Hi list,
> > >
> > > One clusters fenced the passive node around two hours after
> > > auditd was started.
> > >
> > > We have found that iowait has increased since auditd was started
> > > and was unusually high.
> > >
> > > Auditd wasn’t generating many messages and there were no
> > > noticeable added activity on the disk were the audit and syslog files were written.
> > >
> > > Besides watches, the only general rules were :
> > >
> > > # creation
> > > -a exit,always -F arch=b32 -S creat -S mkdir -S mknod -S link -S
> > > symlink -S mkdirat -S mknodat -S linkat -S symlinkat -F uid=root
> > > -F
> > > success=1 -k creation -a exit,always -F arch=b64 -S creat -S mkdir
> > > -S mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S
> > > symlinkat -F uid=root -F success=1 -k creation
> > >
> > > # deletion
> > > -a exit,always -F arch=b32 -S rmdir -S unlink -S unlinkat -F
> > > uid=root -F
> > > success=1 -k deletion
> > > -a exit,always -F arch=b64 -S rmdir -S unlink -S unlinkat -F
> > > uid=root -F
> > > success=1 -k deletion
> > >
> > > After the rebot we deleted all rules and didn’t notice extra
> > > iowait anymore.
> > >
> > > Could these rules be the cause of additional iowait even if not
> > > generating many events (around 20 in two hours) ?
> > >
> > > Is there any other auditd mechanism that could explain this phenomenon ?
> > >
> > > I would appreciate any hints.
> >
> > Hi Philippe,
> >
> > First, as this is a RH cluster product, I would suggest contacting
> > RH support with your question if you haven't already; this list is
> > primarily for upstream development and support.
> >
> > If you are able to experiment with the system, or have a test
> > environment, I would suggest trying to narrow down the list of audit
> > rules/watches to see which rules/watches have the most affect on the
> > iowait times. You've listed four rules, but you didn't list the watches you have configured.
> > Also, what kernel version are you using?
> >
> > --
> > paul moore
> > www.paul-moore.com
> >
> > !!!*****************************************************************
> > ********
> > ************ "Ce message et les pièces jointes sont confidentiels et
> > réservés à l'usage exclusif de ses destinataires. Il peut également
> > être protégé par le secret professionnel. Si vous recevez ce message
> > par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire.
> > L'intégrité du message ne pouvant être assurée sur Internet, la
> > responsabilité de Worldline ne pourra être recherchée quant au
> > contenu de ce message. Bien que les meilleurs efforts soient faits
> > pour maintenir cette transmission exempte de tout virus,
> > l'expéditeur ne donne aucune garantie à cet égard et sa
> > responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.
> >
> > This e-mail and the documents attached are confidential and intended
> > solely for the addressee; it may also be privileged. If you receive
> > this e-mail in error, please notify the sender immediately and
> > destroy it. As its integrity cannot be secured on the Internet, the
> > Worldline liability cannot be triggered for the message content.
> > Although the sender endeavours to maintain a computer virus-free
> > network, the sender does not warrant that this transmission is
> > virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
> >
> > --
> > 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
!!!*************************************************************************************
"Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Slight changes to the SELinux and audit kernel repository process
From: Paul Moore @ 2016-03-03 19:55 UTC (permalink / raw)
To: selinux, linux-audit
Hello all,
Starting with this merge window I'm making some slight changes to the kernel
repository process. The short version is that I'm doing away with the
'upstream' branch, and sending pull requests directly from the 'next' and
'stable-X.YY' branches. I expect this shouldn't have much impact on anyone
and it should get back the commit ID consistency we lost with the most recent
changes.
You can find more detail at the link below if you are interested:
* http://www.paul-moore.com/blog/d/2016/03/kernel-repo-process.html
-Paul
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: auditd and redhat cluster
From: Burn Alting @ 2016-03-02 9:16 UTC (permalink / raw)
To: Paul Moore; +Cc: rgb, Maupertuis Philippe, linux-audit
In-Reply-To: <CAHC9VhThK_abGVA62HwCMcWLH1fFSfaucm-oxrTJ7exTrP=i6g@mail.gmail.com>
On Tue, 2016-03-01 at 16:53 -0500, Paul Moore wrote:
> On Tue, Mar 1, 2016 at 4:25 PM, Burn Alting <burn@swtf.dyndns.org> wrote:
> > Steve, Paul,
> >
> > I have yet to put together a bug report, or researched to see if the
> > problem exists upstream, but have discovered recursive directory rules
> > can be expensive on the kernel. The rules below on a system running
> > rabbitmq can see get_task_cred and audit_filter_rules above 10% each.
> >
> > -w /etc/pam.d -p wa -k PAM_Mods
> > -w /boot -k BOOT_Mods
> > -w /boot/grub/grub.conf -p war -k BOOT_Mods
> > -w /etc/security -p wa -k Security_Mods
> > -w /etc/sysconfig -p wa -k Sysconfig_Mods
> > -w /etc/ld.so.conf.d -p wa -k Library_Mods
> > -w /etc/inittab -p wa -k StartUp_Mods
> > -w /etc/rc.d -p wa -k StartUp_Mods
>
> Some of the work that Richard did with fsnotify for audit-by-exec
> could be used to help make filesystem watches much more efficient,
> especially the case where you are watching a lot of files in a common
> directory.
Interestingly, if we convert all the above into possibly 100's of
specific file watches (for all files in the tree's at a given time), the
system does not take a hit any more.
Again, as soon as I can, I will produce a test configuration.
I will be interested in Philippe's results, if he has/can test my
suggestion.
Rgds
^ permalink raw reply
* Re: auditd and redhat cluster
From: Paul Moore @ 2016-03-01 21:53 UTC (permalink / raw)
To: burn; +Cc: rgb, Maupertuis Philippe, linux-audit
In-Reply-To: <1456867529.5021.72.camel@swtf.swtf.dyndns.org>
On Tue, Mar 1, 2016 at 4:25 PM, Burn Alting <burn@swtf.dyndns.org> wrote:
> Steve, Paul,
>
> I have yet to put together a bug report, or researched to see if the
> problem exists upstream, but have discovered recursive directory rules
> can be expensive on the kernel. The rules below on a system running
> rabbitmq can see get_task_cred and audit_filter_rules above 10% each.
>
> -w /etc/pam.d -p wa -k PAM_Mods
> -w /boot -k BOOT_Mods
> -w /boot/grub/grub.conf -p war -k BOOT_Mods
> -w /etc/security -p wa -k Security_Mods
> -w /etc/sysconfig -p wa -k Sysconfig_Mods
> -w /etc/ld.so.conf.d -p wa -k Library_Mods
> -w /etc/inittab -p wa -k StartUp_Mods
> -w /etc/rc.d -p wa -k StartUp_Mods
Some of the work that Richard did with fsnotify for audit-by-exec
could be used to help make filesystem watches much more efficient,
especially the case where you are watching a lot of files in a common
directory.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: auditd and redhat cluster
From: Burn Alting @ 2016-03-01 21:25 UTC (permalink / raw)
To: Steve Grubb; +Cc: Maupertuis Philippe, linux-audit
In-Reply-To: <3565400.JvOrmoMvUR@x2>
Philippe,
What does a perf top show?
Do you see get_task_cred or audit_filter_rules as high consumers? If
they are high, then try turning off the monitoring of the /tmp, /dev/shm
and /var/lock/lvm trees or if appropriate, switch to monitoring via a
path directive if you don't need to monitor the entire tree.
Steve, Paul,
I have yet to put together a bug report, or researched to see if the
problem exists upstream, but have discovered recursive directory rules
can be expensive on the kernel. The rules below on a system running
rabbitmq can see get_task_cred and audit_filter_rules above 10% each.
-w /etc/pam.d -p wa -k PAM_Mods
-w /boot -k BOOT_Mods
-w /boot/grub/grub.conf -p war -k BOOT_Mods
-w /etc/security -p wa -k Security_Mods
-w /etc/sysconfig -p wa -k Sysconfig_Mods
-w /etc/ld.so.conf.d -p wa -k Library_Mods
-w /etc/inittab -p wa -k StartUp_Mods
-w /etc/rc.d -p wa -k StartUp_Mods
Regards
On Tue, 2016-03-01 at 09:14 -0500, Steve Grubb wrote:
> On Tuesday, March 01, 2016 02:57:45 PM Maupertuis Philippe wrote:
> > The kernel is : 2.6.32-573.12.1.el6.x86_64
> > And the whole audit.rules file is :
>
> <snip>
>
> > During the hour preceding the fence we got these events from the passive
> > node Key Summary Report
> > ===========================
> > total key
> > ===========================
> > 891 system_commands (ping)
> >
> > And on the active node :
> >
> > Key Summary Report
> > ===========================
> > total key
> > ===========================
> > 1330 system_commands
> > 286 deletion
> >
> > I am going to follow your advice and to open a call with redhat.
> > Anyway, I am interested in knowing if auditd has been reported to cause
> > trouble without generating many events.
>
> Those numbers work out to 27 events per minute. That's not really a lot of
> events. To see if its the rules or auditd causing the iowait, you might set
> the logging format to NOLOG. This will discard events rather than log them. If
> you still have iowait, its something to do with the rules. If that cleared it
> up, then auditd might be the source. Either way, put the format back to raw.
>
> I did some benchmarking of auditd over the holidays and posted some results
> here:
>
> https://www.redhat.com/archives/linux-audit/2015-December/msg00061.html
>
> I'd recommend:
>
> flush = incremental
> freq = 100
>
> for a modest performance improvement.
>
> -Steve
>
>
> > -----Message d'origine-----
> > De : Paul Moore [mailto:paul@paul-moore.com]
> > Envoyé : mardi 1 mars 2016 14:25
> > À : Maupertuis Philippe
> > Cc : linux-audit@redhat.com
> > Objet : Re: auditd and redhat cluster
> >
> > On Mon, Feb 29, 2016 at 7:45 AM, Maupertuis Philippe
> <philippe.maupertuis@worldline.com> wrote:
> > > Hi list,
> > >
> > > One clusters fenced the passive node around two hours after auditd
> > > was started.
> > >
> > > We have found that iowait has increased since auditd was started and
> > > was unusually high.
> > >
> > > Auditd wasn’t generating many messages and there were no noticeable
> > > added activity on the disk were the audit and syslog files were written.
> > >
> > > Besides watches, the only general rules were :
> > >
> > > # creation
> > > -a exit,always -F arch=b32 -S creat -S mkdir -S mknod -S link -S
> > > symlink -S mkdirat -S mknodat -S linkat -S symlinkat -F uid=root -F
> > > success=1 -k creation -a exit,always -F arch=b64 -S creat -S mkdir -S
> > > mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S symlinkat
> > > -F uid=root -F success=1 -k creation
> > >
> > > # deletion
> > > -a exit,always -F arch=b32 -S rmdir -S unlink -S unlinkat -F uid=root
> > > -F
> > > success=1 -k deletion
> > > -a exit,always -F arch=b64 -S rmdir -S unlink -S unlinkat -F uid=root
> > > -F
> > > success=1 -k deletion
> > >
> > > After the rebot we deleted all rules and didn’t notice extra iowait
> > > anymore.
> > >
> > > Could these rules be the cause of additional iowait even if not
> > > generating many events (around 20 in two hours) ?
> > >
> > > Is there any other auditd mechanism that could explain this phenomenon ?
> > >
> > > I would appreciate any hints.
> >
> > Hi Philippe,
> >
> > First, as this is a RH cluster product, I would suggest contacting RH
> > support with your question if you haven't already; this list is primarily
> > for upstream development and support.
> >
> > If you are able to experiment with the system, or have a test environment, I
> > would suggest trying to narrow down the list of audit rules/watches to see
> > which rules/watches have the most affect on the iowait times. You've
> > listed four rules, but you didn't list the watches you have configured.
> > Also, what kernel version are you using?
> >
> > --
> > paul moore
> > www.paul-moore.com
> >
> > !!!*************************************************************************
> > ************ "Ce message et les pièces jointes sont confidentiels et
> > réservés à l'usage exclusif de ses destinataires. Il peut également être
> > protégé par le secret professionnel. Si vous recevez ce message par erreur,
> > merci d'en avertir immédiatement l'expéditeur et de le détruire.
> > L'intégrité du message ne pouvant être assurée sur Internet, la
> > responsabilité de Worldline ne pourra être recherchée quant au contenu de
> > ce message. Bien que les meilleurs efforts soient faits pour maintenir
> > cette transmission exempte de tout virus, l'expéditeur ne donne aucune
> > garantie à cet égard et sa responsabilité ne saurait être recherchée pour
> > tout dommage résultant d'un virus transmis.
> >
> > This e-mail and the documents attached are confidential and intended solely
> > for the addressee; it may also be privileged. If you receive this e-mail in
> > error, please notify the sender immediately and destroy it. As its
> > integrity cannot be secured on the Internet, the Worldline liability cannot
> > be triggered for the message content. Although the sender endeavours to
> > maintain a computer virus-free network, the sender does not warrant that
> > this transmission is virus-free and will not be liable for any damages
> > resulting from any virus transmitted.!!!"
> >
> > --
> > 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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: auditd and redhat cluster
From: Steve Grubb @ 2016-03-01 14:14 UTC (permalink / raw)
To: linux-audit; +Cc: Maupertuis Philippe
In-Reply-To: <3D2AB1326AB2974190FCE3F69401F790DB1EBF1517@FRVDX103.fr01.awl.atosorigin.net>
On Tuesday, March 01, 2016 02:57:45 PM Maupertuis Philippe wrote:
> The kernel is : 2.6.32-573.12.1.el6.x86_64
> And the whole audit.rules file is :
<snip>
> During the hour preceding the fence we got these events from the passive
> node Key Summary Report
> ===========================
> total key
> ===========================
> 891 system_commands (ping)
>
> And on the active node :
>
> Key Summary Report
> ===========================
> total key
> ===========================
> 1330 system_commands
> 286 deletion
>
> I am going to follow your advice and to open a call with redhat.
> Anyway, I am interested in knowing if auditd has been reported to cause
> trouble without generating many events.
Those numbers work out to 27 events per minute. That's not really a lot of
events. To see if its the rules or auditd causing the iowait, you might set
the logging format to NOLOG. This will discard events rather than log them. If
you still have iowait, its something to do with the rules. If that cleared it
up, then auditd might be the source. Either way, put the format back to raw.
I did some benchmarking of auditd over the holidays and posted some results
here:
https://www.redhat.com/archives/linux-audit/2015-December/msg00061.html
I'd recommend:
flush = incremental
freq = 100
for a modest performance improvement.
-Steve
> -----Message d'origine-----
> De : Paul Moore [mailto:paul@paul-moore.com]
> Envoyé : mardi 1 mars 2016 14:25
> À : Maupertuis Philippe
> Cc : linux-audit@redhat.com
> Objet : Re: auditd and redhat cluster
>
> On Mon, Feb 29, 2016 at 7:45 AM, Maupertuis Philippe
<philippe.maupertuis@worldline.com> wrote:
> > Hi list,
> >
> > One clusters fenced the passive node around two hours after auditd
> > was started.
> >
> > We have found that iowait has increased since auditd was started and
> > was unusually high.
> >
> > Auditd wasn’t generating many messages and there were no noticeable
> > added activity on the disk were the audit and syslog files were written.
> >
> > Besides watches, the only general rules were :
> >
> > # creation
> > -a exit,always -F arch=b32 -S creat -S mkdir -S mknod -S link -S
> > symlink -S mkdirat -S mknodat -S linkat -S symlinkat -F uid=root -F
> > success=1 -k creation -a exit,always -F arch=b64 -S creat -S mkdir -S
> > mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S symlinkat
> > -F uid=root -F success=1 -k creation
> >
> > # deletion
> > -a exit,always -F arch=b32 -S rmdir -S unlink -S unlinkat -F uid=root
> > -F
> > success=1 -k deletion
> > -a exit,always -F arch=b64 -S rmdir -S unlink -S unlinkat -F uid=root
> > -F
> > success=1 -k deletion
> >
> > After the rebot we deleted all rules and didn’t notice extra iowait
> > anymore.
> >
> > Could these rules be the cause of additional iowait even if not
> > generating many events (around 20 in two hours) ?
> >
> > Is there any other auditd mechanism that could explain this phenomenon ?
> >
> > I would appreciate any hints.
>
> Hi Philippe,
>
> First, as this is a RH cluster product, I would suggest contacting RH
> support with your question if you haven't already; this list is primarily
> for upstream development and support.
>
> If you are able to experiment with the system, or have a test environment, I
> would suggest trying to narrow down the list of audit rules/watches to see
> which rules/watches have the most affect on the iowait times. You've
> listed four rules, but you didn't list the watches you have configured.
> Also, what kernel version are you using?
>
> --
> paul moore
> www.paul-moore.com
>
> !!!*************************************************************************
> ************ "Ce message et les pièces jointes sont confidentiels et
> réservés à l'usage exclusif de ses destinataires. Il peut également être
> protégé par le secret professionnel. Si vous recevez ce message par erreur,
> merci d'en avertir immédiatement l'expéditeur et de le détruire.
> L'intégrité du message ne pouvant être assurée sur Internet, la
> responsabilité de Worldline ne pourra être recherchée quant au contenu de
> ce message. Bien que les meilleurs efforts soient faits pour maintenir
> cette transmission exempte de tout virus, l'expéditeur ne donne aucune
> garantie à cet égard et sa responsabilité ne saurait être recherchée pour
> tout dommage résultant d'un virus transmis.
>
> This e-mail and the documents attached are confidential and intended solely
> for the addressee; it may also be privileged. If you receive this e-mail in
> error, please notify the sender immediately and destroy it. As its
> integrity cannot be secured on the Internet, the Worldline liability cannot
> be triggered for the message content. Although the sender endeavours to
> maintain a computer virus-free network, the sender does not warrant that
> this transmission is virus-free and will not be liable for any damages
> resulting from any virus transmitted.!!!"
>
> --
> 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: auditd and redhat cluster
From: Maupertuis Philippe @ 2016-03-01 13:57 UTC (permalink / raw)
To: Paul Moore, linux-audit@redhat.com
In-Reply-To: <CAHC9VhSqD_zJQG3oBvLCpXypLJiYbd6vOMDgHnMdZK7JwtqrLw@mail.gmail.com>
The kernel is : 2.6.32-573.12.1.el6.x86_64
And the whole audit.rules file is :
-D
-i
-b 8192
-a exit,never -F arch=b32 -F dir=/tmp/
-a exit,never -F arch=b64 -F dir=/tmp/
-a exit,never -F arch=b32 -F dir=/dev/shm/
-a exit,never -F arch=b64 -F dir=/dev/shm/
-a exit,never -F arch=b32 -F dir=/var/lock/lvm/
-a exit,never -F arch=b64 -F dir=/var/lock/lvm/
-w /sbin/agetty -p x -k console_access
-w /sbin/mingetty -p x -k console_access
-w /var/log/audit/ -k audit_logs
-w /var/log/secure -k audit_logs
-a exit,always -F arch=b32 -S creat -S mkdir -S mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S symlinkat -F uid=root -F success=1 -k creation
-a exit,always -F arch=b64 -S creat -S mkdir -S mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S symlinkat -F uid=root -F success=1 -k creation
-a exit,always -F arch=b32 -S rmdir -S unlink -S unlinkat -F uid=root -F success=1 -k deletion
-a exit,always -F arch=b64 -S rmdir -S unlink -S unlinkat -F uid=root -F success=1 -k deletion
-a always,exit -F arch=b32 -S adjtimex -S settimeofday -S stime -k time_change
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
-w /etc/localtime -p wa -k time_change
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity
-w /etc/cron.allow -p wa -k system_files
-w /etc/ntp.conf -p wa -k system_files
-w /etc/ssh/sshd_config -p wa -k system_files
-w /etc/hosts -p wa -k system_files
-w /etc/resolv.conf -p wa -k system_files
-w /etc/audit.rules -p wa -k system_files
-w /etc/auditd.conf -p wa -k system_files
-w /etc/rsyslog.conf -p wa -k system_files
-a exit,always -F arch=b32 -S sethostname -k system_locale
-a exit,always -F arch=b64 -S sethostname -k system_locale
-w /etc/issue -p wa -k system_locale
-w /etc/issue.net -p wa -k system_locale
-w /etc/hosts -p wa -k system_locale
-w /etc/sysconfig/network -p wa -k system_locale
-w /etc/sudoers -p wa -k actions
-w /root/.ssh/authorized_keys -p wa -k ssh_files
-w /home/admnet/.ssh/authorized_keys -p wa -k ssh_files
-w /home/system/.ssh/authorized_keys -p war -k ssh_files
-w /home/oper/.ssh/authorized_keys -p wa -k ssh_files
-w /home/sprod/.ssh/authorized_keys -p wa -k ssh_files
-w /home/www/.ssh/authorized_keys -p wa -k ssh_files
-w /home/integ/.ssh/authorized_keys -p wa -k ssh_files
-w /home/stat/.ssh/authorized_keys -p wa -k ssh_files
-w /home/reference/.ssh/authorized_keys -p wa -k ssh_files
-w /bin/chown -p x -k system_commands
-w /usr/local/sbin/tcpdump -p x -k system_commands
-w /usr/bin/passwd -p x -k system_commands
-w /usr/sbin/useradd -p x -k system_commands
-w /usr/sbin/usermod -p x -k system_commands
-w /bin/chgrp -p x -k system_commands
-w /sbin/route -p x -k system_commands
-w /sbin/shutdown -p x -k system_commands
-w /sbin/reboot -p x -k system_commands
-w /sbin/sysctl -p x -k system_commands
-w /sbin/ifconfig -p x -k system_commands
-w /usr/sbin/visudo -p x -k system_commands
-w /usr/bin/crontab -p x -k system_commands
-w /bin/chmod -p x -k system_commands
-w /bin/su -p x -k system_commands
-w /bin/env -p x -k system_commands
-w /sbin/auditctl -p x -k system_commands
-w /bin/mount -p x -k system_commands
-w /bin/umount -p x -k system_commands
-w /bin/ping6 -p x -k system_commands
-w /bin/ping -p x -k system_commands
-w /sbin/pam_timestamp_check -p x -k system_commands
-w /sbin/netreport -p x -k system_commands
-w /sbin/unix_chkpwd -p x -k system_commands
-w /sbin/mount.nfs -p x -k system_commands
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a exit,always -F arch=b64 -S init_module -S delete_module -k modules
-a exit,always -F arch=b32 -S init_module -S delete_module -k modules
-a exit,always -F arch=b64 -S open -S openat -F exit=-EPERM -k rights
-a exit,always -F arch=b32 -S open -S openat -F exit=-EPERM -k rights
-a exit,always -F arch=b64 -S ptrace -k info_scan
-a exit,always -F arch=b32 -S ptrace -k info_scan
During the hour preceding the fence we got these events from the passive node
Key Summary Report
===========================
total key
===========================
891 system_commands (ping)
And on the active node :
Key Summary Report
===========================
total key
===========================
1330 system_commands
286 deletion
I am going to follow your advice and to open a call with redhat.
Anyway, I am interested in knowing if auditd has been reported to cause trouble without generating many events.
Regards
Philippe
-----Message d'origine-----
De : Paul Moore [mailto:paul@paul-moore.com]
Envoyé : mardi 1 mars 2016 14:25
À : Maupertuis Philippe
Cc : linux-audit@redhat.com
Objet : Re: auditd and redhat cluster
On Mon, Feb 29, 2016 at 7:45 AM, Maupertuis Philippe <philippe.maupertuis@worldline.com> wrote:
> Hi list,
>
> One clusters fenced the passive node around two hours after auditd
> was started.
>
> We have found that iowait has increased since auditd was started and
> was unusually high.
>
> Auditd wasn’t generating many messages and there were no noticeable
> added activity on the disk were the audit and syslog files were written.
>
> Besides watches, the only general rules were :
>
> # creation
> -a exit,always -F arch=b32 -S creat -S mkdir -S mknod -S link -S
> symlink -S mkdirat -S mknodat -S linkat -S symlinkat -F uid=root -F
> success=1 -k creation -a exit,always -F arch=b64 -S creat -S mkdir -S
> mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S symlinkat
> -F uid=root -F success=1 -k creation
>
> # deletion
> -a exit,always -F arch=b32 -S rmdir -S unlink -S unlinkat -F uid=root
> -F
> success=1 -k deletion
> -a exit,always -F arch=b64 -S rmdir -S unlink -S unlinkat -F uid=root
> -F
> success=1 -k deletion
>
> After the rebot we deleted all rules and didn’t notice extra iowait anymore.
>
> Could these rules be the cause of additional iowait even if not
> generating many events (around 20 in two hours) ?
>
> Is there any other auditd mechanism that could explain this phenomenon ?
>
> I would appreciate any hints.
Hi Philippe,
First, as this is a RH cluster product, I would suggest contacting RH support with your question if you haven't already; this list is primarily for upstream development and support.
If you are able to experiment with the system, or have a test environment, I would suggest trying to narrow down the list of audit rules/watches to see which rules/watches have the most affect on the iowait times. You've listed four rules, but you didn't list the watches you have configured. Also, what kernel version are you using?
--
paul moore
www.paul-moore.com
!!!*************************************************************************************
"Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: auditd and redhat cluster
From: Paul Moore @ 2016-03-01 13:25 UTC (permalink / raw)
To: Maupertuis Philippe; +Cc: linux-audit@redhat.com
In-Reply-To: <3D2AB1326AB2974190FCE3F69401F790DB1EBF12E6@FRVDX103.fr01.awl.atosorigin.net>
On Mon, Feb 29, 2016 at 7:45 AM, Maupertuis Philippe
<philippe.maupertuis@worldline.com> wrote:
> Hi list,
>
> One clusters fenced the passive node around two hours after auditd was
> started.
>
> We have found that iowait has increased since auditd was started and was
> unusually high.
>
> Auditd wasn’t generating many messages and there were no noticeable added
> activity on the disk were the audit and syslog files were written.
>
> Besides watches, the only general rules were :
>
> # creation
> -a exit,always -F arch=b32 -S creat -S mkdir -S mknod -S link -S symlink -S
> mkdirat -S mknodat -S linkat -S symlinkat -F uid=root -F success=1 -k
> creation
> -a exit,always -F arch=b64 -S creat -S mkdir -S mknod -S link -S symlink -S
> mkdirat -S mknodat -S linkat -S symlinkat -F uid=root -F success=1 -k
> creation
>
> # deletion
> -a exit,always -F arch=b32 -S rmdir -S unlink -S unlinkat -F uid=root -F
> success=1 -k deletion
> -a exit,always -F arch=b64 -S rmdir -S unlink -S unlinkat -F uid=root -F
> success=1 -k deletion
>
> After the rebot we deleted all rules and didn’t notice extra iowait anymore.
>
> Could these rules be the cause of additional iowait even if not generating
> many events (around 20 in two hours) ?
>
> Is there any other auditd mechanism that could explain this phenomenon ?
>
> I would appreciate any hints.
Hi Philippe,
First, as this is a RH cluster product, I would suggest contacting RH
support with your question if you haven't already; this list is
primarily for upstream development and support.
If you are able to experiment with the system, or have a test
environment, I would suggest trying to narrow down the list of audit
rules/watches to see which rules/watches have the most affect on the
iowait times. You've listed four rules, but you didn't list the
watches you have configured. Also, what kernel version are you using?
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* auditd and redhat cluster
From: Maupertuis Philippe @ 2016-02-29 12:45 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 2547 bytes --]
Hi list,
One clusters fenced the passive node around two hours after auditd was started.
We have found that iowait has increased since auditd was started and was unusually high.
Auditd wasn't generating many messages and there were no noticeable added activity on the disk were the audit and syslog files were written.
Besides watches, the only general rules were :
# creation
-a exit,always -F arch=b32 -S creat -S mkdir -S mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S symlinkat -F uid=root -F success=1 -k creation
-a exit,always -F arch=b64 -S creat -S mkdir -S mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S symlinkat -F uid=root -F success=1 -k creation
# deletion
-a exit,always -F arch=b32 -S rmdir -S unlink -S unlinkat -F uid=root -F success=1 -k deletion
-a exit,always -F arch=b64 -S rmdir -S unlink -S unlinkat -F uid=root -F success=1 -k deletion
After the rebot we deleted all rules and didn't notice extra iowait anymore.
Could these rules be the cause of additional iowait even if not generating many events (around 20 in two hours) ?
Is there any other auditd mechanism that could explain this phenomenon ?
I would appreciate any hints.
Regards
Philippe
!!!*************************************************************************************
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
[-- Attachment #1.2: Type: text/html, Size: 5912 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Regarding log_file_parser
From: Steve Grubb @ 2016-02-26 17:12 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <5ebf37c3.fb52.1531e631d05.Coremail.zhchf2010@126.com>
On Saturday, February 27, 2016 12:22:05 AM 张晨峰 wrote:
> when parsing the field "log_file", If the dir is examined nonexistent, why
> don't create it ? what are the reasons for the design?
Its assumed that the audit system is installed on a managed system. That means
that it depends on the admin or the OS distribution to provide its basic
needs. With that assumption, one would then only verify that the path exists
so that if open(2) later fails, you can correctly tell the admin why the audit
system cannot be started.
The audit system _could_ make the directory. But what if its a typo? (e.g.
/vr/log/audit) Should auditd make the whole directory hierarchy all the way to
the last directory? What permissions should the directory (or directories)
have? What should be the owner and group? If those don't exist, should the
audit system make the accounts? What if the directory chosen is not labeled
correctly for SE Linux? Should auditd have knowledge of SE Linux policy and
call semanage to fix that? What about other MAC systems?
I really just want to draw the line and say its the admin's responsibility to
correctly set it up and then only verify the essentials so that a meaningful
and actionable problem is reported. :-)
Hope this helps...
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Regarding log_file_parser
From: 张晨峰 @ 2016-02-26 16:22 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 1079 bytes --]
|
Hi，
I have some doubt about the bold code below， at audit-2.5/src/auditd-config.c
static int log_file_parser(struct nv_pair *nv, int line,
struct daemon_conf *config)
{
char *dir = NULL, *tdir;
DIR *d;
int fd, mode;
struct stat buf;
audit_msg(LOG_DEBUG, "log_file_parser called with: %s", nv->value);
/* get dir from name. */
tdir = strdup(nv->value);
if (tdir)
dir = dirname(tdir);
if (dir == NULL || strlen(dir) < 4) { // '/var' is shortest dirname
audit_msg(LOG_ERR,
"The directory name: %s is too short - line %d",
dir, line);
free((void *)tdir);
return 1;
}
/* verify the directory path exists */
d = opendir(dir);
if (d == NULL) {
audit_msg(LOG_ERR, "Could not open dir %s (%s)", dir,
strerror(errno));
free((void *)tdir);
return 1;
}
when parsing the field "log_file", If the dir is examined nonexistent, why don't create it ?
what are the reasons for the design?
Thanks.
--
frank
|
[-- Attachment #1.2: Type: text/html, Size: 6469 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Regarding Auditing on RHEL7.1
From: Paul Moore @ 2016-02-26 14:57 UTC (permalink / raw)
To: Sarthak Jain; +Cc: Richard Guy Briggs, linux-audit@redhat.com
In-Reply-To: <5078D98067B1B340BEE9F4F5FF71B8A733EB6C@BLRXMB02.microfocus.com>
On Fri, Feb 26, 2016 at 1:37 AM, Sarthak Jain
<Sarthak.Jain@microfocus.com> wrote:
> Hi Paul,
>
> Well thanks for replying back. But as per my knowledge, RHEL 7 is still facing the issue. Even RHEL 7.1 also.
Which RHEL-7.x kernel version are you using?
While not explicitly mentioned in the release notes, the issue you are
describing is fixed in the errata below. If you have any further RHEL
specific questions I suggest contacting Red Hat support, this mailing
list is for upstream development and support.
* https://rhn.redhat.com/errata/RHSA-2015-2152.html
--
paul moore
www.paul-moore.com
^ permalink raw reply
* RE: Regarding Auditing on RHEL7.1
From: Sarthak Jain @ 2016-02-26 6:37 UTC (permalink / raw)
To: Paul Moore; +Cc: Richard Guy Briggs, linux-audit@redhat.com
In-Reply-To: <CAHC9VhRByxgSKd3HjvuL4WZEZmve0MYQNUsaqEJD_XzY+vcHYA@mail.gmail.com>
Hi Paul,
Well thanks for replying back. But as per my knowledge, RHEL 7 is still facing the issue. Even RHEL 7.1 also.
Assumption : If we modify the configuration file (/etc/hosts), then audit log event will come.
Scenario 1: If we modify the configuration file (/etc/hosts) when the permission is (rw-r--r--), then audit log event is coming properly as mentioned below -
------
type=SYSCALL msg=audit(1456467914.581:50455): arch=c000003e syscall=82 success=yes exit=0 a0=8db730 a1=903980 a2=fffffffffffffea0 a3=7fffe734aee0 items=4 ppid=27080 pid=29188 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=6667 comm="vi" exe="/usr/bin/vi" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=CWD msg=audit(1456467914.581:50455): cwd="/root"
type=PATH msg=audit(1456467914.581:50455): item=0 name="/etc/" inode=67108993 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT
type=PATH msg=audit(1456467914.581:50455): item=1 name="/etc/" inode=67108993 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT
type=PATH msg=audit(1456467914.581:50455): item=2 name="/etc/hosts" inode=70206961 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=DELETE
type=PATH msg=audit(1456467914.581:50455): item=3 name="/etc/hosts~" inode=70206961 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=CREATE
--------
Scenario 2: Let's say if we modify the file when the permissions for file are (rw-rw-rw-), then audit log event is coming as mentioned below -
----------
type=SYSCALL msg=audit(1456466535.398:50437): arch=c000003e syscall=2 success=yes exit=3 a0=10d7730 a1=241 a2=1b6 a3=0 items=3 ppid=27080 pid=27328 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=6667 comm="vi" exe="/usr/bin/vi" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=CWD msg=audit(1456466535.398:50437): cwd="/root"
type=PATH msg=audit(1456466535.398:50437): item=0 name="/etc/" inode=67108993 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT
type=PATH msg=audit(1456466535.398:50437): item=1 name=(null) inode=70206961 dev=fd:00 mode=0100666 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL
type=PATH msg=audit(1456466535.398:50437): item=2 name=(null) inode=70206961 dev=fd:00 mode=0100666 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL
-----------
As you can see, in second scenario, the name is coming "null". As mentioned in the previous message, I think it is a kernel level bug. As I saw the conversation on this link - https://www.redhat.com/archives/linux-audit/2015-January/msg00016.html , I guess it has been targeted for kernel v3.19-rcX? Or if it has been fixed for RHEL 7, are there any patches which we need to apply?
Thanks
-----Original Message-----
From: Paul Moore [mailto:paul@paul-moore.com]
Sent: Friday, February 26, 2016 12:44 AM
To: Sarthak Jain <Sarthak.Jain@microfocus.com>
Cc: linux-audit@redhat.com; Richard Guy Briggs <rgb@redhat.com>
Subject: Re: Regarding Auditing on RHEL7.1
On Wed, Feb 24, 2016 at 9:32 AM, Sarthak Jain <Sarthak.Jain@microfocus.com> wrote:
> Hi,
>
> There has been one issue I am facing with auditing on RHEL 7.1. It is
> the same one as described here -
> https://www.redhat.com/archives/linux-audit/2015-January/msg00045.html
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1155208
>
> Can you please comment on this whether it has been fixed or not?
The issue has been fixed in upstream kernels as well as in RHEL-7.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* RE: Regarding Auditing on RHEL 7.1
From: Sarthak Jain @ 2016-02-26 6:28 UTC (permalink / raw)
To: Steve Grubb, linux-audit@redhat.com
In-Reply-To: <2113594.6K0R9tGoXX@x2>
Hi Steve,
Thanks for explaining the thing properly. I think I misinterpreted the meaning of "CONFIG_CHANGE" and I understood.
The problem which I was asking was something different. I actually have already started a different thread for that.
Thanks.
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Friday, February 26, 2016 1:22 AM
To: linux-audit@redhat.com
Cc: Sarthak Jain <Sarthak.Jain@microfocus.com>
Subject: Re: Regarding Auditing on RHEL 7.1
On Wednesday, February 24, 2016 07:04:08 AM Sarthak Jain wrote:
> I am Sarthak Jain working in MicroFocus. I want your small help to
> clarify one of my doubt regarding the kernel auditing on RHEL 7.1. I
> hope you are the right person to contact. It will just 2 min (max :P)
> to go through the problem.
>
> Assumption: Ideally, if we change the configuration file (for ex-
> /etc/hosts), we should be getting audit events for it.
>
> Scenario: By default, the permissions for '/etc/hosts' is (rw-r-r--).
> If we modify this file, then audit events are coming as attached in
> file - 'file1.txt'.
>
> Problem: Let say if we change the permissions of the '/etc/hosts' to
> (rw-rw-rw), then audit system is not recording the "CONFIG_CHANGE"
> event at all.
That is because the audit configuration has not changed. Config change events are specific to changes in the audit system itself. What you get on this is syscall event with a path
If you want to get events on changing permissions on a file, then you would put a rule like this:
-a always,exit -F path=/etc/hosts -F perms=a -F key=permission-change
After modifying the file with chmod, then run:
ausearch --start today -k permission-change
> I have attached the file - 'file2.txt' for your reference. Can you
> please clarify this ? Is it a kernel level bug?
No. Its doing what it should.
-Steve
^ permalink raw reply
* Re: Regarding Auditing on RHEL 7.1
From: Steve Grubb @ 2016-02-25 19:52 UTC (permalink / raw)
To: linux-audit; +Cc: Sarthak Jain
In-Reply-To: <5078D98067B1B340BEE9F4F5FF71B8A733E824@BLRXMB02.microfocus.com>
On Wednesday, February 24, 2016 07:04:08 AM Sarthak Jain wrote:
> I am Sarthak Jain working in MicroFocus. I want your small help to clarify
> one of my doubt regarding the kernel auditing on RHEL 7.1. I hope you are
> the right person to contact. It will just 2 min (max :P) to go through the
> problem.
>
> Assumption: Ideally, if we change the configuration file (for ex-
> /etc/hosts), we should be getting audit events for it.
>
> Scenario: By default, the permissions for '/etc/hosts' is (rw-r-r--). If we
> modify this file, then audit events are coming as attached in file -
> 'file1.txt'.
>
> Problem: Let say if we change the permissions of the '/etc/hosts' to
> (rw-rw-rw), then audit system is not recording the "CONFIG_CHANGE" event at
> all.
That is because the audit configuration has not changed. Config change events
are specific to changes in the audit system itself. What you get on this is
syscall event with a path
If you want to get events on changing permissions on a file, then you would put
a rule like this:
-a always,exit -F path=/etc/hosts -F perms=a -F key=permission-change
After modifying the file with chmod, then run:
ausearch --start today -k permission-change
> I have attached the file - 'file2.txt' for your reference. Can you
> please clarify this ? Is it a kernel level bug?
No. Its doing what it should.
-Steve
^ 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