Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] fsnotify: Fix handling of renames in audit
From: Jan Kara @ 2015-02-10 15:00 UTC (permalink / raw)
  To: Andrew Morton; +Cc: LKML, Jan Kara, linux-audit, Paul Moore, Eric Paris, stable

Commit e9fd702a58c4 (audit: convert audit watches to use fsnotify
instead of inotify) broke handling of renames in audit. Audit code wants
to update inode number of an inode corresponding to watched name in a
directory. When something gets renamed into a directory to a watched
name, inotify previously passed moved inode to audit code however new
fsnotify code passes directory inode where the change happened. That
confuses audit and it starts watching parent directory instead of a file
in a directory.

This can be observed for example by doing:
cd /tmp
touch foo bar
auditctl -w /tmp/foo
touch foo
mv bar foo
touch foo

In audit log we see events like:
type=CONFIG_CHANGE msg=audit(1423563584.155:90): auid=1000 ses=2
op="updated rules" path="/tmp/foo" key=(null) list=4 res=1
...
type=PATH msg=audit(1423563584.155:91): item=2 name="bar" inode=1046884
dev=08:0
2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
type=PATH msg=audit(1423563584.155:91): item=3 name="foo" inode=1046842
dev=08:0
2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
type=PATH msg=audit(1423563584.155:91): item=4 name="foo" inode=1046884
dev=08:0
2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE
...
and that's it - we see event for the first touch after creating the
audit rule, we see events for rename but we don't see any event for the
last touch. However we start seeing events for unrelated stuff happening
in /tmp.

Fix the problem by passing moved inode as data in the FS_MOVED_FROM and
FS_MOVED_TO events instead of the directory where the change happens.
This doesn't introduce any new problems because noone besides
audit_watch.c cares about the passed value:
fs/notify/fanotify/fanotify.c cares only about FSNOTIFY_EVENT_PATH events.
fs/notify/dnotify/dnotify.c doesn't care about passed 'data' value at all.
fs/notify/inotify/inotify_fsnotify.c uses 'data' only for FSNOTIFY_EVENT_PATH.
kernel/audit_tree.c doesn't care about passed 'data' at all.
kernel/audit_watch.c expects moved inode as 'data'.

CC: linux-audit@redhat.com
CC: Paul Moore <paul@paul-moore.com>
CC: Eric Paris <eparis@redhat.com>
CC: stable@vger.kernel.org
Fixes: e9fd702a58c49dbb14481dca88dad44758da393a
Signed-off-by: Jan Kara <jack@suse.cz>
---
 include/linux/fsnotify.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
index 1c804b057fb1..7ee1774edee5 100644
--- a/include/linux/fsnotify.h
+++ b/include/linux/fsnotify.h
@@ -101,8 +101,10 @@ static inline void fsnotify_move(struct inode *old_dir, struct inode *new_dir,
 		new_dir_mask |= FS_ISDIR;
 	}
 
-	fsnotify(old_dir, old_dir_mask, old_dir, FSNOTIFY_EVENT_INODE, old_name, fs_cookie);
-	fsnotify(new_dir, new_dir_mask, new_dir, FSNOTIFY_EVENT_INODE, new_name, fs_cookie);
+	fsnotify(old_dir, old_dir_mask, source, FSNOTIFY_EVENT_INODE, old_name,
+		 fs_cookie);
+	fsnotify(new_dir, new_dir_mask, source, FSNOTIFY_EVENT_INODE, new_name,
+		 fs_cookie);
 
 	if (target)
 		fsnotify_link_count(target);
-- 
2.1.4

^ permalink raw reply related

* Re: Audit: audisp-remote plugin: why is OpenLDAP a dependency ??
From: salgak @ 2015-02-09 17:26 UTC (permalink / raw)
  To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <20150209180058.54f930bd@ivy-bridge>


[-- Attachment #1.1: Type: text/plain, Size: 950 bytes --]

Yeah, just crawled into the rpm and saw that. Going to try to re-spin a smaller RPM without the zos and see if that works. 

----- Original Message -----

From: "Steve Grubb" <sgrubb@redhat.com> 
To: salgak@comcast.net 
Cc: linux-audit@redhat.com 
Sent: Monday, February 9, 2015 12:00:58 PM 
Subject: Re: Audit: audisp-remote plugin: why is OpenLDAP a dependency ?? 

On Mon, 9 Feb 2015 13:47:36 +0000 (UTC) 
salgak@comcast.net wrote: 

> I'm currently dealing with a VMware appliance, and need to export my 
> audit logs. Despite VMware telling me to use the audisp-remote plugin 
> with auditd, I get a dependency check for OpenLDAP, and the install 
> fails. 
> 
> I'm pointing to my audit server (a Splunk box) via IP address. Is 
> there any workaround, or am I stuck adding even MORE software to the 
> appliance ?? 

The package the plugin is included in contains all of them. The 
zos-remote plugin is the one that wants openldap. 

-Steve 


[-- Attachment #1.2: Type: text/html, Size: 1561 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: Audit: audisp-remote plugin: why is OpenLDAP a dependency ??
From: Steve Grubb @ 2015-02-09 17:00 UTC (permalink / raw)
  To: salgak; +Cc: linux-audit
In-Reply-To: <473290240.2225092.1423489656934.JavaMail.zimbra@comcast.net>

On Mon, 9 Feb 2015 13:47:36 +0000 (UTC)
salgak@comcast.net wrote:

> I'm currently dealing with a VMware appliance, and need to export my
> audit logs. Despite VMware telling me to use the audisp-remote plugin
> with auditd, I get a dependency check for OpenLDAP, and the install
> fails. 
> 
> I'm pointing to my audit server (a Splunk box) via IP address. Is
> there any workaround, or am I stuck adding even MORE software to the
> appliance ?? 

The package the plugin is included in contains all of them. The
zos-remote plugin is the one that wants openldap.

-Steve

^ permalink raw reply

* Audit: audisp-remote plugin: why is OpenLDAP a dependency ??
From: salgak @ 2015-02-09 13:47 UTC (permalink / raw)
  To: linux-audit
In-Reply-To: <924112195.2223087.1423489490422.JavaMail.zimbra@comcast.net>


[-- Attachment #1.1: Type: text/plain, Size: 766 bytes --]

I'm currently dealing with a VMware appliance, and need to export my audit logs. Despite VMware telling me to use the audisp-remote plugin with auditd, I get a dependency check for OpenLDAP, and the install fails. 

I'm pointing to my audit server (a Splunk box) via IP address. Is there any workaround, or am I stuck adding even MORE software to the appliance ?? 

______________________________________________________________________________________ 
It is by Caffeine alone, that I set my Mind in Motion. 
It is by the Beans of Java that thought acquires speed, the hands develop shakes, the shakes become a warning. 
It is by Caffeine alone that I set my Mind in Motion. 
______________________________________________________________________________________ 


[-- Attachment #1.2: Type: text/html, Size: 1085 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* RE: Linux audit performance impact
From: Viswanath, Logeswari P (MCOU OSTL) @ 2015-02-06 11:52 UTC (permalink / raw)
  To: Richard Guy Briggs; +Cc: linux-audit@redhat.com
In-Reply-To: <20150204161557.GF18752@madcap2.tricolour.ca>

One more question, I have enabled all system calls for auditing and auditd is not running. 
Will printk result in write system call which in turn be audited?
If yes, is there any way to ignore auditing for a specific processes such as syslogd to avoid auditing these extra write system calls?

-----Original Message-----
From: Viswanath, Logeswari P (MCOU OSTL) 
Sent: Friday, February 06, 2015 12:17 PM
To: 'Richard Guy Briggs'
Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
Subject: RE: Linux audit performance impact

Hi all,

Please find the below the details of the performance test we ran.
It would be great if we get help to identify the reason behind the degradation and the ways of improving it. 

Kernel Version:
root > uname -r
3.13.0-36-generic

OS Version:
Ubuntu 14.04.1

No. of CPUs: 
root > nproc
24

Audit Status:
root > auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=0 rate_limit=0 backlog_limit=320 lost=57190353 backlog=0

Rules Configured:
root > auditctl -l
LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=all

Attached is the program used to load the system.

Results:

Without enabling audit	12.29
With auditing enabled and no rules configured 12.31
With auditing enabled, 1 rule configured but auditd not running - kauditd logs audit records to syslog via printk	41.02		

The degradation is around 200%

Regards,
Logeswari.

-----Original Message-----
From: Richard Guy Briggs [mailto:rgb@redhat.com]
Sent: Wednesday, February 04, 2015 9:46 PM
To: Viswanath, Logeswari P (MCOU OSTL)
Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
Subject: Re: Linux audit performance impact

On 15/02/04, Viswanath, Logeswari P (MCOU OSTL) wrote:
> The intent is to calculate the performance impact by the auditing 
> components such as
> 
> 1) impact because of kauditd without auditd - but kauditd writes to syslog, so we are unable to determine the impact just because of kauditd - It is fine even if the audit record is dropped by kauditd. Is there any way to do this?

Not yet.  That is a mode that has not been useful to anyone yet.  You are welcome to hack a custom kernel to disable klog for doing testing instrumentation.

> 2) impact because of running auditd - log format NOLOG
> 3) impact because of running audispd - small plugin is written which will just read the audit records and doesn't processes it.
> 
> -----Original Message-----
> From: Richard Guy Briggs [mailto:rgb@redhat.com]
> Sent: Tuesday, February 03, 2015 10:33 PM
> To: Satish Chandra Kilaru
> Cc: Viswanath, Logeswari P (MCOU OSTL); Steve Grubb; 
> linux-audit@redhat.com
> Subject: Re: Linux audit performance impact
> 
> On 15/02/03, Satish Chandra Kilaru wrote:
> > Thanks for The info. But my question was rhetorical... I meant to 
> > say that it would not be much... She is trying to bombard the system 
> > with open calls ... So lots and lots of events will be generated and 
> > kernel has to write down the events some where or discard them...
> 
> Exactly.  It is of little practical use.  You have to do I/O at some point, either to the same disk or another, or to a network interface or serial port, otherwise, just chuck it out.  You could do a performance measurement on a short burst, then drain the queue, but what will that actually tell us?
> 
> > On Tuesday, February 3, 2015, Richard Guy Briggs <rgb@redhat.com> wrote:
> > 
> > > On 15/02/03, Satish Chandra Kilaru wrote:
> > > > How many events can kernel accumulate without I/o ?
> > >
> > > The kernel default is 64 *buffers*, but I think Fedora and RHEL 
> > > set it to 320.  It is now possible to set it to "0" which means 
> > > limited only by system resources.  See "man auditctl", "-b"
> > > option.  An event can be made up of several buffers.
> > >
> > > Of course, how long a system lasts before the queue blows up 
> > > depends on your rule set...
> > >
> > > However, at the moment, it will still write out to klog if auditd 
> > > isn't running.
> > >
> > > > On Tuesday, February 3, 2015, Viswanath, Logeswari P (MCOU OSTL) 
> > > > < logeswari.pv@hp.com <javascript:;>> wrote:
> > > >
> > > > > I don't want to disable auditing (i.e. disable audit record
> > > collection),
> > > > > but just do not want the records to delivered to user space 
> > > > > since I
> > > want to
> > > > > remove the I/O overhead while running the performance test.
> > > > > Is there any option for this?
> > > > >
> > > > > -----Original Message-----
> > > > > From: Richard Guy Briggs [mailto:rgb@redhat.com <javascript:;>
> > > <javascript:;>]
> > > > > Sent: Thursday, January 29, 2015 10:23 PM
> > > > > To: Viswanath, Logeswari P (MCOU OSTL)
> > > > > Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
> > > <javascript:;>
> > > > > <javascript:;>
> > > > > Subject: Re: Linux audit performance impact
> > > > >
> > > > > On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> > > > > > Please read my question as “Is there any option to configure 
> > > > > > kaudit not to log audit records to syslog? when auditd not running.”
> > > > >
> > > > > Yeah, remove audit=1 from the kernel command line, or set
> > > > > audit=0 in
> > > its
> > > > > place.  This will stop all but AVCs and if auditd has ever run 
> > > > > since
> > > boot.
> > > > > If audit=0 is on the kernel boot line, it will be impossible 
> > > > > to run
> > > auditd.
> > > > >
> > > > > There is a feature request that is likely coming soon that 
> > > > > could be
> > > > > useful:
> > > > >
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> > > > > "If no audit daemon is running, but an audit multicast 
> > > > > subscriber is around, then the kernel shouldn't forward audit data to kmsg"
> > > > >
> > > > > > From: Viswanath, Logeswari P (MCOU OSTL)
> > > > > > Sent: Thursday, January 29, 2015 11:49 AM
> > > > > > To: 'Satish Chandra Kilaru'; Steve Grubb
> > > > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;>
> > > > > > Subject: RE: Linux audit performance impact
> > > > > >
> > > > > > Is there any option to configure kaudit not to log audit 
> > > > > > records to
> > > > > syslog when auditd is running?
> > > > > > This way we can assess the impact of enabling audit without 
> > > > > > involving
> > > > > disk I/o overhead.
> > > > > >
> > > > > > From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com
> > > <javascript:;> <javascript:;>]
> > > > > > Sent: Thursday, January 29, 2015 9:12 AM
> > > > > > To: Steve Grubb
> > > > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;><mailto:
> > > linux-audit@redhat.com <javascript:;>
> > > > > <javascript:;>>; Viswanath,
> > > > > > Logeswari P (MCOU OSTL)
> > > > > > Subject: Re: Linux audit performance impact
> > > > > >
> > > > > > I agree with you... but writing to disk can trigger further 
> > > > > > events
> > > > > leading spiralling of events...
> > > > > > I brought down my server few times with stupid rules...
> > > > > >
> > > > > > On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb 
> > > > > > <sgrubb@redhat.com
> > > <javascript:;>
> > > > > <javascript:;><mailto:sgrubb@redhat.com <javascript:;>
> > > <javascript:;>>> wrote:
> > > > > > On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra 
> > > > > > Kilaru
> > > wrote:
> > > > > > > Write your own program to receive audit events directly 
> > > > > > > without using auditd...
> > > > > > > That should be faster ....
> > > > > > > Auditd will log the events to disk causing more I/o than u need...
> > > > > >
> > > > > > But even that is configurable in many ways. You can decide 
> > > > > > if you
> > > want
> > > > > > logging to disk or not and what kind of assurance that it 
> > > > > > made it to disk and the priority of that audit daemon. Then 
> > > > > > you also have all
> > > the
> > > > > > normal tuning knobs for disk throughput that you would use 
> > > > > > for any disk performance critical system.
> > > > > >
> > > > > > -Steve
> > > > > >
> > > > > > > On Wednesday, January 28, 2015, Viswanath, Logeswari P 
> > > > > > > (MCOU
> > > > > > > OSTL)
> > > <
> > > > > > >
> > > > > > > logeswari.pv@hp.com <javascript:;> <javascript:;><mailto:
> > > logeswari.pv@hp.com <javascript:;>
> > > > > <javascript:;>>> wrote:
> > > > > > > >  Hi Steve,
> > > > > > > >
> > > > > > > > I am Logeswari working for HP.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > We want to know audit performance impact on RHEL and 
> > > > > > > > Suse linux
> > > to
> > > > > > > > help us evaluate linux audit as data source for our host 
> > > > > > > > based
> > > IDS.
> > > > > > > >
> > > > > > > > When we ran our own performance test with a test audispd 
> > > > > > > > plugin, we found if a system can perform 200000 
> > > > > > > > open/close system calls per second without auditing, 
> > > > > > > > system can perform only 3000 open/close system calls 
> > > > > > > > auditing is enabled for open/close system call which is 
> > > > > > > > a HUGE impact on the system performance. It would
> > > be
> > > > > > > > great if anyone can help us answering the following questions.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 1)      Is this performance impact expected? If yes, what is the
> > > > > reason
> > > > > > > > behind it and can we fix it?
> > > > > > > >
> > > > > > > > 2)      Have anyone done any benchmarking for performance
> > > impact? If
> > > > > yes,
> > > > > > > > can you please share the numbers and also the 
> > > > > > > > steps/programs used the run the same.
> > > > > > > >
> > > > > > > > 3)      Help us validating the performance test we have done in
> > > our
> > > > > test
> > > > > > > > setup using the steps mentioned along with the results attached.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Attached test program (loader.c) to invoke open and 
> > > > > > > > close system
> > > > > calls.
> > > > > > > >
> > > > > > > > Attached idskerndsp is the audispd plugin program.
> > > > > > > >
> > > > > > > > We used time command to determine how much time the 
> > > > > > > > system took
> > > to
> > > > > > > > complete 50000 open/close system calls without (results 
> > > > > > > > attached
> > > > > > > > Without-auditing) and with auditing enabled on the 
> > > > > > > > system (With-auditing-NOLOG-audispd-plugin and
> > > > > > > > With-auditing-RAW)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > System details:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 1 CPU machine
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > *OS Version*
> > > > > > > >
> > > > > > > > RHEL 6.5
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > *Kernel Version*
> > > > > > > >
> > > > > > > > uname –r
> > > > > > > >
> > > > > > > > 2.6.32-431.el6.x86_64
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Note: auditd was occupying 35% of CPU and was sleeping 
> > > > > > > > for most
> > > of
> > > > > > > > the time whereas kauditd was occupying 20% of the CPU.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks & Regards,
> > > > > > > >
> > > > > > > > Logeswari.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Please Donate to www.wikipedia.org<http://www.wikipedia.org>
> > > > >
> > > > > > --
> > > > > > Linux-audit mailing list
> > > > > > Linux-audit@redhat.com <javascript:;> <javascript:;> 
> > > > > > https://www.redhat.com/mailman/listinfo/linux-audit
> > > > >
> > > > >
> > > > > - RGB
> > > > >
> > > > > --
> > > > > Richard Guy Briggs <rbriggs@redhat.com <javascript:;> 
> > > > > <javascript:;>> Senior Software Engineer, Kernel Security, 
> > > > > AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, 
> > > > > Canada
> > > > > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: 
> > > > > +1.613.693.0684x3545
> > > > >
> > > >
> > > >
> > > > --
> > > > Please Donate to www.wikipedia.org
> > >
> > > - RGB
> > >
> > > --
> > > Richard Guy Briggs <rbriggs@redhat.com <javascript:;>> Senior 
> > > Software Engineer, Kernel Security, AMER ENG Base Operating 
> > > Systems, Red Hat Remote, Ottawa, Canada
> > > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: 
> > > +1.613.693.0684x3545
> > >
> > 
> > 
> > --
> > Please Donate to www.wikipedia.org
> 
> - RGB
> 
> --
> Richard Guy Briggs <rbriggs@redhat.com> Senior Software Engineer, 
> Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, 
> Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: 
> +1.613.693.0684x3545

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

^ permalink raw reply

* RE: Linux audit performance impact
From: Viswanath, Logeswari P (MCOU OSTL) @ 2015-02-06  6:47 UTC (permalink / raw)
  To: Richard Guy Briggs; +Cc: linux-audit@redhat.com
In-Reply-To: <20150204161557.GF18752@madcap2.tricolour.ca>

[-- Attachment #1: Type: text/plain, Size: 12600 bytes --]

Hi all,

Please find the below the details of the performance test we ran.
It would be great if we get help to identify the reason behind the degradation and the ways of improving it. 

Kernel Version:
root > uname -r
3.13.0-36-generic

OS Version:
Ubuntu 14.04.1

No. of CPUs: 
root > nproc
24

Audit Status:
root > auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=0 rate_limit=0 backlog_limit=320 lost=57190353 backlog=0

Rules Configured:
root > auditctl -l
LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=all

Attached is the program used to load the system.

Results:

Without enabling audit	12.29
With auditing enabled and no rules configured 12.31
With auditing enabled, 1 rule configured but auditd not running - kauditd logs audit records to syslog via printk	41.02		

The degradation is around 200%

Regards,
Logeswari.

-----Original Message-----
From: Richard Guy Briggs [mailto:rgb@redhat.com] 
Sent: Wednesday, February 04, 2015 9:46 PM
To: Viswanath, Logeswari P (MCOU OSTL)
Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
Subject: Re: Linux audit performance impact

On 15/02/04, Viswanath, Logeswari P (MCOU OSTL) wrote:
> The intent is to calculate the performance impact by the auditing 
> components such as
> 
> 1) impact because of kauditd without auditd - but kauditd writes to syslog, so we are unable to determine the impact just because of kauditd - It is fine even if the audit record is dropped by kauditd. Is there any way to do this?

Not yet.  That is a mode that has not been useful to anyone yet.  You are welcome to hack a custom kernel to disable klog for doing testing instrumentation.

> 2) impact because of running auditd - log format NOLOG
> 3) impact because of running audispd - small plugin is written which will just read the audit records and doesn't processes it.
> 
> -----Original Message-----
> From: Richard Guy Briggs [mailto:rgb@redhat.com]
> Sent: Tuesday, February 03, 2015 10:33 PM
> To: Satish Chandra Kilaru
> Cc: Viswanath, Logeswari P (MCOU OSTL); Steve Grubb; 
> linux-audit@redhat.com
> Subject: Re: Linux audit performance impact
> 
> On 15/02/03, Satish Chandra Kilaru wrote:
> > Thanks for The info. But my question was rhetorical... I meant to 
> > say that it would not be much... She is trying to bombard the system 
> > with open calls ... So lots and lots of events will be generated and 
> > kernel has to write down the events some where or discard them...
> 
> Exactly.  It is of little practical use.  You have to do I/O at some point, either to the same disk or another, or to a network interface or serial port, otherwise, just chuck it out.  You could do a performance measurement on a short burst, then drain the queue, but what will that actually tell us?
> 
> > On Tuesday, February 3, 2015, Richard Guy Briggs <rgb@redhat.com> wrote:
> > 
> > > On 15/02/03, Satish Chandra Kilaru wrote:
> > > > How many events can kernel accumulate without I/o ?
> > >
> > > The kernel default is 64 *buffers*, but I think Fedora and RHEL 
> > > set it to 320.  It is now possible to set it to "0" which means 
> > > limited only by system resources.  See "man auditctl", "-b" 
> > > option.  An event can be made up of several buffers.
> > >
> > > Of course, how long a system lasts before the queue blows up 
> > > depends on your rule set...
> > >
> > > However, at the moment, it will still write out to klog if auditd 
> > > isn't running.
> > >
> > > > On Tuesday, February 3, 2015, Viswanath, Logeswari P (MCOU OSTL) 
> > > > < logeswari.pv@hp.com <javascript:;>> wrote:
> > > >
> > > > > I don't want to disable auditing (i.e. disable audit record
> > > collection),
> > > > > but just do not want the records to delivered to user space 
> > > > > since I
> > > want to
> > > > > remove the I/O overhead while running the performance test.
> > > > > Is there any option for this?
> > > > >
> > > > > -----Original Message-----
> > > > > From: Richard Guy Briggs [mailto:rgb@redhat.com <javascript:;>
> > > <javascript:;>]
> > > > > Sent: Thursday, January 29, 2015 10:23 PM
> > > > > To: Viswanath, Logeswari P (MCOU OSTL)
> > > > > Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
> > > <javascript:;>
> > > > > <javascript:;>
> > > > > Subject: Re: Linux audit performance impact
> > > > >
> > > > > On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> > > > > > Please read my question as “Is there any option to configure 
> > > > > > kaudit not to log audit records to syslog? when auditd not running.”
> > > > >
> > > > > Yeah, remove audit=1 from the kernel command line, or set
> > > > > audit=0 in
> > > its
> > > > > place.  This will stop all but AVCs and if auditd has ever run 
> > > > > since
> > > boot.
> > > > > If audit=0 is on the kernel boot line, it will be impossible 
> > > > > to run
> > > auditd.
> > > > >
> > > > > There is a feature request that is likely coming soon that 
> > > > > could be
> > > > > useful:
> > > > >
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> > > > > "If no audit daemon is running, but an audit multicast 
> > > > > subscriber is around, then the kernel shouldn't forward audit data to kmsg"
> > > > >
> > > > > > From: Viswanath, Logeswari P (MCOU OSTL)
> > > > > > Sent: Thursday, January 29, 2015 11:49 AM
> > > > > > To: 'Satish Chandra Kilaru'; Steve Grubb
> > > > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;>
> > > > > > Subject: RE: Linux audit performance impact
> > > > > >
> > > > > > Is there any option to configure kaudit not to log audit 
> > > > > > records to
> > > > > syslog when auditd is running?
> > > > > > This way we can assess the impact of enabling audit without 
> > > > > > involving
> > > > > disk I/o overhead.
> > > > > >
> > > > > > From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com
> > > <javascript:;> <javascript:;>]
> > > > > > Sent: Thursday, January 29, 2015 9:12 AM
> > > > > > To: Steve Grubb
> > > > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;><mailto:
> > > linux-audit@redhat.com <javascript:;>
> > > > > <javascript:;>>; Viswanath,
> > > > > > Logeswari P (MCOU OSTL)
> > > > > > Subject: Re: Linux audit performance impact
> > > > > >
> > > > > > I agree with you... but writing to disk can trigger further 
> > > > > > events
> > > > > leading spiralling of events...
> > > > > > I brought down my server few times with stupid rules...
> > > > > >
> > > > > > On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb 
> > > > > > <sgrubb@redhat.com
> > > <javascript:;>
> > > > > <javascript:;><mailto:sgrubb@redhat.com <javascript:;>
> > > <javascript:;>>> wrote:
> > > > > > On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra 
> > > > > > Kilaru
> > > wrote:
> > > > > > > Write your own program to receive audit events directly 
> > > > > > > without using auditd...
> > > > > > > That should be faster ....
> > > > > > > Auditd will log the events to disk causing more I/o than u need...
> > > > > >
> > > > > > But even that is configurable in many ways. You can decide 
> > > > > > if you
> > > want
> > > > > > logging to disk or not and what kind of assurance that it 
> > > > > > made it to disk and the priority of that audit daemon. Then 
> > > > > > you also have all
> > > the
> > > > > > normal tuning knobs for disk throughput that you would use 
> > > > > > for any disk performance critical system.
> > > > > >
> > > > > > -Steve
> > > > > >
> > > > > > > On Wednesday, January 28, 2015, Viswanath, Logeswari P 
> > > > > > > (MCOU
> > > > > > > OSTL)
> > > <
> > > > > > >
> > > > > > > logeswari.pv@hp.com <javascript:;> <javascript:;><mailto:
> > > logeswari.pv@hp.com <javascript:;>
> > > > > <javascript:;>>> wrote:
> > > > > > > >  Hi Steve,
> > > > > > > >
> > > > > > > > I am Logeswari working for HP.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > We want to know audit performance impact on RHEL and 
> > > > > > > > Suse linux
> > > to
> > > > > > > > help us evaluate linux audit as data source for our host 
> > > > > > > > based
> > > IDS.
> > > > > > > >
> > > > > > > > When we ran our own performance test with a test audispd 
> > > > > > > > plugin, we found if a system can perform 200000 
> > > > > > > > open/close system calls per second without auditing, 
> > > > > > > > system can perform only 3000 open/close system calls 
> > > > > > > > auditing is enabled for open/close system call which is 
> > > > > > > > a HUGE impact on the system performance. It would
> > > be
> > > > > > > > great if anyone can help us answering the following questions.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 1)      Is this performance impact expected? If yes, what is the
> > > > > reason
> > > > > > > > behind it and can we fix it?
> > > > > > > >
> > > > > > > > 2)      Have anyone done any benchmarking for performance
> > > impact? If
> > > > > yes,
> > > > > > > > can you please share the numbers and also the 
> > > > > > > > steps/programs used the run the same.
> > > > > > > >
> > > > > > > > 3)      Help us validating the performance test we have done in
> > > our
> > > > > test
> > > > > > > > setup using the steps mentioned along with the results attached.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Attached test program (loader.c) to invoke open and 
> > > > > > > > close system
> > > > > calls.
> > > > > > > >
> > > > > > > > Attached idskerndsp is the audispd plugin program.
> > > > > > > >
> > > > > > > > We used time command to determine how much time the 
> > > > > > > > system took
> > > to
> > > > > > > > complete 50000 open/close system calls without (results 
> > > > > > > > attached
> > > > > > > > Without-auditing) and with auditing enabled on the 
> > > > > > > > system (With-auditing-NOLOG-audispd-plugin and 
> > > > > > > > With-auditing-RAW)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > System details:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 1 CPU machine
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > *OS Version*
> > > > > > > >
> > > > > > > > RHEL 6.5
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > *Kernel Version*
> > > > > > > >
> > > > > > > > uname –r
> > > > > > > >
> > > > > > > > 2.6.32-431.el6.x86_64
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Note: auditd was occupying 35% of CPU and was sleeping 
> > > > > > > > for most
> > > of
> > > > > > > > the time whereas kauditd was occupying 20% of the CPU.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks & Regards,
> > > > > > > >
> > > > > > > > Logeswari.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Please Donate to www.wikipedia.org<http://www.wikipedia.org>
> > > > >
> > > > > > --
> > > > > > Linux-audit mailing list
> > > > > > Linux-audit@redhat.com <javascript:;> <javascript:;> 
> > > > > > https://www.redhat.com/mailman/listinfo/linux-audit
> > > > >
> > > > >
> > > > > - RGB
> > > > >
> > > > > --
> > > > > Richard Guy Briggs <rbriggs@redhat.com <javascript:;> 
> > > > > <javascript:;>> Senior Software Engineer, Kernel Security, 
> > > > > AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, 
> > > > > Canada
> > > > > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: 
> > > > > +1.613.693.0684x3545
> > > > >
> > > >
> > > >
> > > > --
> > > > Please Donate to www.wikipedia.org
> > >
> > > - RGB
> > >
> > > --
> > > Richard Guy Briggs <rbriggs@redhat.com <javascript:;>> Senior 
> > > Software Engineer, Kernel Security, AMER ENG Base Operating 
> > > Systems, Red Hat Remote, Ottawa, Canada
> > > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: 
> > > +1.613.693.0684x3545
> > >
> > 
> > 
> > --
> > Please Donate to www.wikipedia.org
> 
> - RGB
> 
> --
> Richard Guy Briggs <rbriggs@redhat.com> Senior Software Engineer, 
> Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, 
> Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: 
> +1.613.693.0684x3545

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

[-- Attachment #2: loader.c --]
[-- Type: text/plain, Size: 8879 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>

void create_load(int iters);
void cleanup();

int   high_rate = 0;
int   num_iters = 100000;
int   fd1;
char  file1[50];
char  file2[50];
char  dir1[50];
char  symlink1[50];

/* Purpose: To create system load by invoking system calls used by templates.
 *
 * Note: The unlink(2) of a file can be an expensive operation (i.e., event 
 *       rate goes way down).
 */

main(int argc, char **argv) {

  int              num_children=1;
  int              iters;
  int              i;
  char             c;

  while ((c = getopt(argc, argv, "hi:")) != -1) {
    switch (c) {
    case 'h':
      /*
       * Desire "high" event rate
       */
      high_rate = 1;
      argc--;
      break;
    case 'i':
      /*
       * Desire a specified number of iterations
       */
      num_iters = atoi(optarg);
      argc--;
      break;
    default:
      fprintf(stderr,"Unknown option: %c\n",optarg);
      exit(1);
    }
  }


  /*if(argv[optind] != NULL) {
    num_children = atoi(argv[optind]);
  } else {
    num_children = 0;
  }
  Register cleanup routine */
  fprintf(stderr,"Registering cleanup routine...\n");
  if (atexit(cleanup) == -1) {
    fprintf(stderr,"Error calling atexit(), errno=%d(%s)\n",
	    errno,strerror(errno));
    exit(1);
  }
    

  /* fork child processes, if any requested */
  for(i=1; i < num_children; i++) {
    if(fork() == 0) {

      printf("child pid: %d\n",getpid());

      /* Setup file names based on child's pid */
      sprintf(file1,"./file1_%d",getpid());
      sprintf(file2,"./file2_%d",getpid());
      sprintf(dir1,"./dir1_%d",getpid());
      sprintf(symlink1,"./file1symlink_%d",getpid());

      /* each child creates load */	
      iters=0;
      if (num_iters == -1) {
	while(1) {
	  create_load(iters);
	  iters++;
	  if( (iters % 1000) == 0) {
	    printf("pid %d iteration %d\n",getpid(),iters);
	  }
	}
      } else {
	while(iters < num_iters) {
	  create_load(iters);
	  iters++;
	  if( (iters % 1000) == 0) {
	    printf("pid %d iteration %d\n",getpid(),iters);
	  }
	}
      }
    }
  }

  /* Parent creates load also */
  printf("parent pid: %d\n",getpid());

  /* Setup file names based on parent's pid */
  sprintf(file1,"./file1_%d",getpid());
  sprintf(file2,"./file2_%d",getpid());
  sprintf(dir1,"./dir1_%d",getpid());
  sprintf(symlink1,"./file1symlink_%d",getpid());

  iters=0;
  if (num_iters == -1) {
    while(1) {
      create_load(iters);
      iters++;
      if( (iters % 1000) == 0) {
	printf("pid %d iteration %d\n",getpid(),iters);
      }
    }
  } else {
    while(iters < num_iters) {
      create_load(iters);
      iters++;
      if( (iters % 1000) == 0) {
	printf("pid %d iteration %d\n",getpid(),iters);
      }
    }
  }

} /* main */


void create_load(int iters) {

  int pid;
  char *args[2];
  struct stat stat_buf;

  fd1 = creat(file1,0x644);
  if (fd1 == -1) {
    fprintf(stderr,"pid %d: creat() returned error for file %s, errno=%d(%s)\n",
	    getpid(),file1,errno,strerror(errno));
    exit(1);
  }
  if (close(fd1) == -1) {
    fprintf(stderr,"pid %d: close() returned error, errno=%d(%s)\n",
	    getpid(),errno,strerror(errno));
    exit(1);
  }
  fd1 = open(file1, O_RDWR, 0777);
  if (fd1 == -1) {
    fprintf(stderr,"pid %d: open() returned error, errno=%d(%s)\n",
	    getpid(),errno,strerror(errno));
    exit(1);
  }

  /* Chown this file to root instead of user ids so that we don't generate a 
   * non-owned alert when the file is truncated when invoking creat() again
   * as root on an existing file owned by another user.
   */
  if (chown(file1,0,0) == -1) {
    fprintf(stderr,"pid %d: chown(%d,%d) returned error, errno=%d(%s)\n",
	    getpid(),0,0,errno,strerror(errno));
    exit(1);
  }    
 
  if (fchown(fd1,0,0) == -1) {
    fprintf(stderr,"pid %d: fchown(%d,%d) returned error, errno=%d(%s)\n",
	    getpid(),0,0,errno,strerror(errno));
    exit(1);
  }   
   
  if (chmod(file1, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH) == -1) {
    fprintf(stderr,"pid %d: chmod(S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH) returned error, errno=%d(%s)\n",
	    getpid(),errno,strerror(errno));
    exit(1);
  }    
  if (fchmod(fd1,   S_IXUSR|S_IXGRP|S_IXOTH) == -1) {
    fprintf(stderr,"pid %d: fchmod(S_IXUSR|S_IXGRP|S_IXOTH) returned error, errno=%d(%s)\n",
	    getpid(),errno,strerror(errno));
    exit(1);
  }


  if (write(fd1,"Some stuff",strlen("Some stuff")) == -1) {
    fprintf(stderr,"pid %d: write() returned error, errno=%d(%s)\n",
	    getpid(),errno,strerror(errno));
    exit(1);
  }
  if (ftruncate(fd1,7) == -1) {
    fprintf(stderr,"pid %d: ftruncate() returned error, errno=%d(%s)\n",
	    getpid(),errno,strerror(errno));
    exit(1);
  }
  if (close(fd1) == -1) {
    fprintf(stderr,"pid %d: close() returned error, errno=%d(%s)\n",
	    getpid(),errno,strerror(errno));
    exit(1);
  }

  if (truncate(file1,3) == -1) {
    fprintf(stderr,"pid %d: truncate() returned error, errno=%d(%s)\n",
	    getpid(),errno,strerror(errno));
    exit(1);
  }
  if (rename(file1,file2) == -1) {
    fprintf(stderr,"pid %d: rename(%s,%s) returned error, errno=%d(%s)\n",
	    getpid(),file1,file2,errno,strerror(errno));
    exit(1);
  }
  if (rename(file2,file1) == -1) {
    fprintf(stderr,"pid %d: rename(%s,%s) returned error, errno=%d(%s)\n",
	    getpid(),file2,file1,errno,strerror(errno));
    exit(1);
  }
  if (link(file1,file2) == -1) {
    fprintf(stderr,"pid %d: link(%s,%s) returned error, errno=%d(%s)\n",
	    getpid(),file1,file2,errno,strerror(errno));
    exit(1);
  }
  if (symlink(file1,symlink1) == -1) {
    fprintf(stderr,"pid %d: symlink(%s,%s) returned error, errno=%d(%s)\n",
	    getpid(),file1,symlink1,errno,strerror(errno));
    exit(1);
  }
  if (lchown(symlink1,0,0) == -1) {
    fprintf(stderr,"pid %d: lchown(%s,%d,%d) returned error, errno=%d(%s)\n",
	    getpid(),symlink1,0,0,errno,strerror(errno));
    exit(1);
  }
  
  if (lstat(symlink1,&stat_buf) == -1) {
    fprintf(stderr,"pid %d: lstat(%s) returned error, errno=%d(%s)\n",
	    getpid(),symlink1,errno,strerror(errno));
    exit(1);
  }
  if (stat(file1,&stat_buf) == -1) {
    fprintf(stderr,"pid %d: stat(%s) returned error, errno=%d(%s)\n",
	    getpid(),file1,errno,strerror(errno));
    exit(1);
  }
  if (unlink(file1) == -1) {
    fprintf(stderr,"pid %d: unlink(%s) returned error, errno=%d(%s)\n",
	    getpid(),file1,errno,strerror(errno));
    exit(1);
  }
  if (unlink(file2) == -1) {
    fprintf(stderr,"pid %d: unlink(%s) returned error, errno=%d(%s)\n",
	    getpid(),file2,errno,strerror(errno));
    exit(1);
  }
  if (unlink(symlink1) == -1) {
    fprintf(stderr,"pid %d: unlink(%s) returned error, errno=%d(%s)\n",
	    getpid(),symlink1,errno,strerror(errno));
    exit(1);
  }
  if (mkdir(dir1,S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IXGRP) == -1) {
    fprintf(stderr,"pid %d: mkdir() returned error, errno=%d(%s)\n",
	    getpid(),errno,strerror(errno));
    exit(1);
  }
  if (rmdir(dir1) == -1) {
    fprintf(stderr,"pid %d: rmdir() returned error, errno=%d(%s)\n",
	    getpid(),errno,strerror(errno));
    exit(1);
  }

  /* Fork every 10000 iterations to not use up process resources too quickly */
  if ( (iters % 10000) == 0) {
    pid = fork();
    if(pid == 0) {
      fprintf(stderr,"child pid %d: fork!\n",getpid());
      // child
      args[0] = "/bin/ls";
      args[1] = NULL;
      close(1);
      close(2);    
      execve(args[0], args, NULL);
      fprintf(stderr,"pid %d: execve(%s) returned error, errno=%d(%s)\n",
	      getpid(),args[0],errno,strerror(errno));
      _exit(1);
    } else if (pid < 0) { 
      fprintf(stderr,"pid %d: fork() returned error, errno=%d(%s)\n",
	      getpid(),errno,strerror(errno));
      exit(1);
    } else {
      fprintf(stderr,"parent pid %d, child pid: %d: fork!\n",getpid(),pid);
    }

    pid = vfork();
    if(pid == 0) {
      args[0] = "/bin/pwd";
      args[1] = NULL;
      close(1);
      close(2);    
      execv(args[0], args);
      fprintf(stderr,"pid %d: execve(%s) returned error, errno=%d(%s)\n",
	      getpid(),args[0],errno,strerror(errno));
      _exit(1);
    } else if (pid < 0) { 
      fprintf(stderr,"pid %d: vfork() returned error, errno=%d(%s)\n",
	      getpid(),errno,strerror(errno));
      exit(1);
    }
  }

  /* Make sure everything is cleaned up and deleted before returning */
  cleanup();

} /* create_load() */

void cleanup() {
  close(fd1);
  unlink(file1);
  unlink(file2);
  unlink(symlink1);
  unlink(dir1);
  return;
}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: Filtering Connect syscalls for af_inet only
From: Paul Moore @ 2015-02-05 20:34 UTC (permalink / raw)
  To: Hassan Sultan; +Cc: linux-audit@redhat.com
In-Reply-To: <op.xtlpqulb1jp0b1@win8mac>

On Thu, Feb 5, 2015 at 3:26 PM, Hassan Sultan <hsultan@thefroid.net> wrote:
> Wouldn't x86 simply be a filter with 2 comparisons : one on a0 to filter
> only connect, and one on a3 for the sockaddr size ?
>
> Basically, on x86 you have one rule : the one with 2 comparisons
> On x64 you have 2 rules : one on the connect syscall, and one on the
> socketcall syscall with 2 comparisons

The socketcall() syscall take two arguments, the first indicates the
syscall (e.g. connect()) and the second is binary blob that contains
the arguments for the socket syscall.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply

* Re: Filtering Connect syscalls for af_inet only
From: Hassan Sultan @ 2015-02-05 20:26 UTC (permalink / raw)
  To: Paul Moore, F Rafi; +Cc: linux-audit@redhat.com
In-Reply-To: <CABXp1ctf0yhkdtwMscrPRq1-Pjm9hZNKPmwQ5yvTGaRz4MGomw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1719 bytes --]

Wouldn't x86 simply be a filter with 2 comparisons : one on a0 to filter  
only connect, and one on a3 for the sockaddr size ?

Basically, on x86 you have one rule : the one with 2 comparisons
On x64 you have 2 rules : one on the connect syscall, and one on the  
socketcall syscall with 2 comparisons

Thanks,

Hassan

On Thu, 05 Feb 2015 11:06:03 -0800, F Rafi <farhanible@gmail.com> wrote:

> I did some digging and now I understand the different size variations of  
> sockaddr_storage. I guess I can just filter on a2!=6e then.
>
> And we'd have to keep an eye out for x86 systems. I understand that  
> x86_64 does not use socketcall() but, do you know if multiarch support  
> somehow >allows 32bit apps on x86_64 to use / translate these calls?
>
> Thanks again!
> Farhan
>
> On Thu, Feb 5, 2015 at 10:38 AM, Paul Moore <paul@paul-moore.com> wrote:
>> On Thu, Feb 5, 2015 at 10:31 AM, F Rafi <farhanible@gmail.com> wrote:
>>> Ahh..thanks Paul!
>>>
>>> Is there a better way to intercept outbound network access calls while
>>> avoiding af_unix?
>>
>> I'm not sure, I'm not overly familiar with the auditd/auditctl
>> filtering capabilities.  There are several people on this list that
>> are far more knowledgeable about that than me.
>>
>>>>> I assume sockaddr_storage is just a different size (I think 128?)
>>
>> The idea behind the sockaddr_storage struct was to create a structure
>> that could be used to represent any address family that the system
>> supports.  I don't believe there is a standard size across OSes due to
>> different level of support, padding, etc; in other words, it's
>> probably best not to rely on a specific size of sockaddr_storage.
>>
>>>> --
>> paul moore
>> www.paul-moore.com

[-- Attachment #1.2.1: Type: text/html, Size: 2708 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: Filtering Connect syscalls for af_inet only
From: Paul Moore @ 2015-02-05 20:16 UTC (permalink / raw)
  To: F Rafi; +Cc: linux-audit@redhat.com
In-Reply-To: <CABXp1ctf0yhkdtwMscrPRq1-Pjm9hZNKPmwQ5yvTGaRz4MGomw@mail.gmail.com>

On Thu, Feb 5, 2015 at 2:06 PM, F Rafi <farhanible@gmail.com> wrote:
> I did some digging and now I understand the different size variations of
> sockaddr_storage. I guess I can just filter on a2!=6e then.

I assume 0x6e is the size of sockaddr_un?  I would still caution
against filtering on any particular size as you could still use
sockaddr_storage for AF_UNIX.  Granted, it's unlikely, but it is
possible.

> And we'd have to keep an eye out for x86 systems. I understand that x86_64
> does not use socketcall() but, do you know if multiarch support somehow
> allows 32bit apps on x86_64 to use / translate these calls?

32-bit x86 applications running on a x86_64 system use the 32-bit
socketcall() system call; there is no way around that, it's part of
the 32-bit x86 ABI for Linux.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply

* Re: Filtering Connect syscalls for af_inet only
From: F Rafi @ 2015-02-05 19:06 UTC (permalink / raw)
  To: Paul Moore; +Cc: linux-audit@redhat.com
In-Reply-To: <CAHC9VhSCv+Y7E98H_pPs+cZXYFbCw2nDu7O_FRmwjfB1mDouUw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1283 bytes --]

I did some digging and now I understand the different size variations of
sockaddr_storage. I guess I can just filter on a2!=6e then.

And we'd have to keep an eye out for x86 systems. I understand that x86_64
does not use socketcall() but, do you know if multiarch support somehow
allows 32bit apps on x86_64 to use / translate these calls?

Thanks again!
Farhan

On Thu, Feb 5, 2015 at 10:38 AM, Paul Moore <paul@paul-moore.com> wrote:

> On Thu, Feb 5, 2015 at 10:31 AM, F Rafi <farhanible@gmail.com> wrote:
> > Ahh..thanks Paul!
> >
> > Is there a better way to intercept outbound network access calls while
> > avoiding af_unix?
>
> I'm not sure, I'm not overly familiar with the auditd/auditctl
> filtering capabilities.  There are several people on this list that
> are far more knowledgeable about that than me.
>
> > I assume sockaddr_storage is just a different size (I think 128?)
>
> The idea behind the sockaddr_storage struct was to create a structure
> that could be used to represent any address family that the system
> supports.  I don't believe there is a standard size across OSes due to
> different level of support, padding, etc; in other words, it's
> probably best not to rely on a specific size of sockaddr_storage.
>
> --
> paul moore
> www.paul-moore.com
>

[-- Attachment #1.2: Type: text/html, Size: 1942 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: Filtering Connect syscalls for af_inet only
From: Paul Moore @ 2015-02-05 15:38 UTC (permalink / raw)
  To: F Rafi; +Cc: linux-audit@redhat.com
In-Reply-To: <CABXp1csszX4e-tJD8Gihz0vTdEvsHpTHS22OvNuZPetqmHpdwA@mail.gmail.com>

On Thu, Feb 5, 2015 at 10:31 AM, F Rafi <farhanible@gmail.com> wrote:
> Ahh..thanks Paul!
>
> Is there a better way to intercept outbound network access calls while
> avoiding af_unix?

I'm not sure, I'm not overly familiar with the auditd/auditctl
filtering capabilities.  There are several people on this list that
are far more knowledgeable about that than me.

> I assume sockaddr_storage is just a different size (I think 128?)

The idea behind the sockaddr_storage struct was to create a structure
that could be used to represent any address family that the system
supports.  I don't believe there is a standard size across OSes due to
different level of support, padding, etc; in other words, it's
probably best not to rely on a specific size of sockaddr_storage.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply

* Re: Filtering Connect syscalls for af_inet only
From: F Rafi @ 2015-02-05 15:31 UTC (permalink / raw)
  To: Paul Moore; +Cc: linux-audit@redhat.com
In-Reply-To: <CAHC9VhSdJOOJRAqCiUOD62T6caLjBtum4hQ=PbDfsnb3Jg0JtQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1395 bytes --]

Ahh..thanks Paul!

Is there a better way to intercept outbound network access calls while
avoiding af_unix?

I assume sockaddr_storage is just a different size (I think 128?)

Thanks
Farhan

On Thursday, February 5, 2015, Paul Moore <paul@paul-moore.com> wrote:

> On Wed, Feb 4, 2015 at 8:19 PM, F Rafi <farhanible@gmail.com
> <javascript:;>> wrote:
> > After some log analysis it looks like filtering on "a2=10" only shows
> > network activity. From what I understand, this is the address length (int
> > addrlen) argument in the sys_connect function.
> >
> > Traced it down to this comment in socket.c. Sounds like filtering for
> a2=10
> > and a2=18 (to account for IPv6) may work.
> >
> > #define MAX_SOCK_ADDR 128
> > /* 108 for Unix domain -
> > 16 for IP,
> > 16 for IPX,
> > 24 for IPv6,
> > about 80 for AX.
> > 25 must be at least one bigger than the AF_UNIX size (see
> netunix/af_unix.c
> > :unix_mkname())
> >  */
> >
> > 10 hex = 16 dec and 18 hex = 24 dec
> >
> > I hope someone can correct me if I sound like I'm not all there.
>
> [Ooops, hit "reply" instead of "reply-to-all"]
>
> A few things come to mind with this approach:
>
> * This will not work on x86 due to the socketcall() syscall multiplexer.
>
> * This doesn't solve the problem for applications that leverage the
> address family independent sockaddr_storage structure.
>
> --
> paul moore
> www.paul-moore.com
>

[-- Attachment #1.2: Type: text/html, Size: 2239 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: Filtering Connect syscalls for af_inet only
From: Paul Moore @ 2015-02-05 14:39 UTC (permalink / raw)
  To: F Rafi; +Cc: linux-audit
In-Reply-To: <CABXp1cuidB0ut_qG=fSd=qrPODGKdL62mWnowyOSkkZnABrMKw@mail.gmail.com>

On Wed, Feb 4, 2015 at 8:19 PM, F Rafi <farhanible@gmail.com> wrote:
> After some log analysis it looks like filtering on "a2=10" only shows
> network activity. From what I understand, this is the address length (int
> addrlen) argument in the sys_connect function.
>
> Traced it down to this comment in socket.c. Sounds like filtering for a2=10
> and a2=18 (to account for IPv6) may work.
>
> #define MAX_SOCK_ADDR 128
> /* 108 for Unix domain -
> 16 for IP,
> 16 for IPX,
> 24 for IPv6,
> about 80 for AX.
> 25 must be at least one bigger than the AF_UNIX size (see netunix/af_unix.c
> :unix_mkname())
>  */
>
> 10 hex = 16 dec and 18 hex = 24 dec
>
> I hope someone can correct me if I sound like I'm not all there.

[Ooops, hit "reply" instead of "reply-to-all"]

A few things come to mind with this approach:

* This will not work on x86 due to the socketcall() syscall multiplexer.

* This doesn't solve the problem for applications that leverage the
address family independent sockaddr_storage structure.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply

* Re: Filtering Connect syscalls for af_inet only
From: F Rafi @ 2015-02-05  1:19 UTC (permalink / raw)
  To: Peter Moody; +Cc: linux-audit
In-Reply-To: <CABXp1cszjrfR0G6aMc02ZXzxDxRF7B=uHbgXbs1NGQD9LKEHYg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3190 bytes --]

After some log analysis it looks like filtering on "a2=10" only shows
network activity. From what I understand, this is the address length (*int
addrlen*) argument in the sys_connect function.

Traced it down to this comment in socket.c. Sounds like filtering for a2=10
and a2=18 (to account for IPv6) may work.

#define MAX_SOCK_ADDR 128
/* 108 for Unix domain -
16 for IP,
16 for IPX,
24 for IPv6,
about 80 for AX.
25 must be at least one bigger than the AF_UNIX size (see netunix/af_unix.c
:unix_mkname())
 */

10 hex = 16 dec and 18 hex = 24 dec

I hope someone can correct me if I sound like I'm not all there.

Farhan



On Tue, Feb 3, 2015 at 6:53 PM, F Rafi <farhanible@gmail.com> wrote:

> Correction. Both filetype=socket and !=socket result in just saddr=0100..
> events. Seems like this is not the way to go.
>
> Farhan
>
> On Tue, Feb 3, 2015 at 6:24 PM, F Rafi <farhanible@gmail.com> wrote:
>
>> Sorry, I should have mentioned that I already tried that. That results in
>> no logs being generated for that rule.
>>
>> Thanks,
>> Farhan
>>
>> On Tue, Feb 3, 2015 at 6:21 PM, Peter Moody <pmoody@google.com> wrote:
>>
>>>
>>> On Tue, Feb 03 2015 at 14:57, F Rafi wrote:
>>> > Hi folks,
>>> >
>>> > <n00b alert>
>>> >
>>> > I have auditing for outbound connect requests working using the Connect
>>> > (sys_connect) syscall on a server running *Ubuntu precise 12.04 LTS*.
>>> >
>>> > The rule I'm using is:
>>> >
>>> > -a exit,always -F arch=b64 -S connect -k network_outbound
>>> >
>>> >
>>> >
>>> > I'm getting a substantial amount of saddr=0100.... logs, which I
>>> understand
>>> > are not  connections to a remote host but rather a local AF_UNIX socket
>>> > pointing to a file. Example log message is:
>>> >
>>> >
>>> >
>>> > type=SYSCALL msg=audit(1423002916.796:24545371): arch=c000003e
>>> syscall=42
>>> >> success=no exit=-2 a0=294 a1=7fff97f62680 a2=6e a3=7fff97f62860
>>> items=0
>>> >> ppid=20546 pid=21439 auid=4294967295 uid=33 gid=33 euid=33 suid=33
>>> fsuid=33
>>> >> egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="apache2"
>>> >> exe="/usr/lib/apache2/mpm-prefork/apache2" key="network_outbound"
>>> >
>>> > type=SOCKADDR msg=audit(1423002916.796:24545371):
>>> *saddr=0100*<truncated to
>>> >> remove the hex-encoded file path>
>>> >
>>> >
>>> > Is there an easy way to filter these out so that we only have
>>> saddr=0200...
>>> > messages left?
>>> >
>>> > I'm exporting the log to an external syslog server and it would help
>>> > considerably if I could eliminate this from all of our servers.
>>> >
>>> > I see that auditctl has a *filetype* filter which can be set to filter
>>> > *socket* or *file* types. Is that the right way to filter these
>>> messages?
>>> >
>>> > -a exit,always -F arch=b64 -F filetype=socket -S connect -k
>>> network_outbound
>>>
>>> does -F filetype!=socket work?
>>>
>>> > The above rule filters out everything but the af_unix connect syscalls,
>>> > which is the opposite of what I'm looking for.
>>> >
>>> > Any help would be appreciated.
>>> >
>>> > Thanks,
>>> > Farhan
>>> > --
>>> > Linux-audit mailing list
>>> > Linux-audit@redhat.com
>>> > https://www.redhat.com/mailman/listinfo/linux-audit
>>>
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 5354 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: confusing with open system call in Linux kernel
From: Paul Moore @ 2015-02-04 16:46 UTC (permalink / raw)
  To: Alan TaN; +Cc: linux-audit
In-Reply-To: <21a101d04026$9f45c8b0$ddd15a10$@gmail.com>

This is a known bug, at least upstream and in CentOS 7.x kernels.  We
have a fix in place which should be merged into Linus tree during the
next merge window (which likely starts next week).

On Tue, Feb 3, 2015 at 9:59 PM, Alan TaN <maillist.alan@gmail.com> wrote:
> Hi everyone,
>
>
>
> I am new here, so I am not exactly sure if this is the right place to ask
> this. I apologise in advance if this is not the right place.
>
> I would like to ask if anyone has encountered the issue below.
>
>
>
> I am trying to track a set of file accesses system calls in a Linux system
> (for experimental purposes) and used the following subset of rules with the
> audit.rules file.
>
>
>
> -a exit,always -F arch=b64 -S creat -S read -S write -S rename -S open -S
> close
>
>
>
> What I noticed was that for the open system call, when opening an existing
> file for writing purpose, the file name would result in a ‘null’ value like
> shown:
>
>
>
> type=SYSCALL msg=audit(1423018198.026:20826531): arch=c000003e syscall=2
> success=yes exit=4 a0=400865 a1=241 a2=1b6 a3=0 items=2 ppid=9093 pid=9169
> auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1
> ses=3805 comm="readfile" exe="/root/prov_project/script/readfile"
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
>
> type=CWD msg=audit(1423018198.026:20826531):
> cwd="/root/prov_project/script"
>
> type=PATH msg=audit(1423018198.026:20826531): item=0
> name="/root/prov_project/script" inode=311564 dev=fd:01 mode=040755 ouid=0
> ogid=0 rdev=00:00 obj=unconfined_u:object_r:admin_home_t:s0 nametype=PARENT
>
> type=PATH msg=audit(1423018198.026:20826531): item=1 name=(null)
> inode=269089 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
> obj=unconfined_u:object_r:admin_home_t:s0 nametype=NORMAL
>
>
>
>
>
> However, opening the same file with read only mode or opening a non-existing
> file (which in that case the open system call would create the file) would
> result in the file name being captured as shown:
>
>
>
> type=SYSCALL msg=audit(1423018196.556:20826486): arch=c000003e syscall=2
> success=yes exit=4 a0=400865 a1=241 a2=1b6 a3=0 items=2 ppid=9093 pid=9168
> auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1
> ses=3805 comm="readfile" exe="/root/prov_project/script/readfile"
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
>
> type=CWD msg=audit(1423018196.556:20826486):
> cwd="/root/prov_project/script"
>
> type=PATH msg=audit(1423018196.556:20826486): item=0
> name="/root/prov_project/script" inode=311564 dev=fd:01 mode=040755 ouid=0
> ogid=0 rdev=00:00 obj=unconfined_u:object_r:admin_home_t:s0 nametype=PARENT
>
> type=PATH msg=audit(1423018196.556:20826486): item=1 name="sample_text.txt"
> inode=269089 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
> obj=unconfined_u:object_r:admin_home_t:s0 nametype=CREATE
>
>
>
> Hence the question: Is this an intended feature or a bug?
>
>
>
> Appreciate if anyone can shed some light on this.
>
>
>
> To reproduce:  write to a non-existing file first, close it and then open
> and write to the same file again.
>
>
>
> I am running version 2.3.7-5 of the audit framework and on CentOS 6.4
> (kernel version 2.6.32-431)
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Alan
>
>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit



-- 
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

* Re: Linux audit performance impact
From: Richard Guy Briggs @ 2015-02-04 16:15 UTC (permalink / raw)
  To: Viswanath, Logeswari P (MCOU OSTL); +Cc: linux-audit@redhat.com
In-Reply-To: <9DBA79E0CE64AA42B07DEDAAD0F7DB914165B73B@G4W3222.americas.hpqcorp.net>

On 15/02/04, Viswanath, Logeswari P (MCOU OSTL) wrote:
> The intent is to calculate the performance impact by the auditing components such as 
> 
> 1) impact because of kauditd without auditd - but kauditd writes to syslog, so we are unable to determine the impact just because of kauditd - It is fine even if the audit record is dropped by kauditd. Is there any way to do this?

Not yet.  That is a mode that has not been useful to anyone yet.  You
are welcome to hack a custom kernel to disable klog for doing testing
instrumentation.

> 2) impact because of running auditd - log format NOLOG
> 3) impact because of running audispd - small plugin is written which will just read the audit records and doesn't processes it.
> 
> -----Original Message-----
> From: Richard Guy Briggs [mailto:rgb@redhat.com] 
> Sent: Tuesday, February 03, 2015 10:33 PM
> To: Satish Chandra Kilaru
> Cc: Viswanath, Logeswari P (MCOU OSTL); Steve Grubb; linux-audit@redhat.com
> Subject: Re: Linux audit performance impact
> 
> On 15/02/03, Satish Chandra Kilaru wrote:
> > Thanks for The info. But my question was rhetorical... I meant to say 
> > that it would not be much... She is trying to bombard the system with 
> > open calls ... So lots and lots of events will be generated and kernel 
> > has to write down the events some where or discard them...
> 
> Exactly.  It is of little practical use.  You have to do I/O at some point, either to the same disk or another, or to a network interface or serial port, otherwise, just chuck it out.  You could do a performance measurement on a short burst, then drain the queue, but what will that actually tell us?
> 
> > On Tuesday, February 3, 2015, Richard Guy Briggs <rgb@redhat.com> wrote:
> > 
> > > On 15/02/03, Satish Chandra Kilaru wrote:
> > > > How many events can kernel accumulate without I/o ?
> > >
> > > The kernel default is 64 *buffers*, but I think Fedora and RHEL set 
> > > it to 320.  It is now possible to set it to "0" which means limited 
> > > only by system resources.  See "man auditctl", "-b" option.  An 
> > > event can be made up of several buffers.
> > >
> > > Of course, how long a system lasts before the queue blows up depends 
> > > on your rule set...
> > >
> > > However, at the moment, it will still write out to klog if auditd 
> > > isn't running.
> > >
> > > > On Tuesday, February 3, 2015, Viswanath, Logeswari P (MCOU OSTL) < 
> > > > logeswari.pv@hp.com <javascript:;>> wrote:
> > > >
> > > > > I don't want to disable auditing (i.e. disable audit record
> > > collection),
> > > > > but just do not want the records to delivered to user space 
> > > > > since I
> > > want to
> > > > > remove the I/O overhead while running the performance test.
> > > > > Is there any option for this?
> > > > >
> > > > > -----Original Message-----
> > > > > From: Richard Guy Briggs [mailto:rgb@redhat.com <javascript:;>
> > > <javascript:;>]
> > > > > Sent: Thursday, January 29, 2015 10:23 PM
> > > > > To: Viswanath, Logeswari P (MCOU OSTL)
> > > > > Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
> > > <javascript:;>
> > > > > <javascript:;>
> > > > > Subject: Re: Linux audit performance impact
> > > > >
> > > > > On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> > > > > > Please read my question as “Is there any option to configure 
> > > > > > kaudit not to log audit records to syslog? when auditd not running.”
> > > > >
> > > > > Yeah, remove audit=1 from the kernel command line, or set 
> > > > > audit=0 in
> > > its
> > > > > place.  This will stop all but AVCs and if auditd has ever run 
> > > > > since
> > > boot.
> > > > > If audit=0 is on the kernel boot line, it will be impossible to 
> > > > > run
> > > auditd.
> > > > >
> > > > > There is a feature request that is likely coming soon that could 
> > > > > be
> > > > > useful:
> > > > >
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> > > > > "If no audit daemon is running, but an audit multicast 
> > > > > subscriber is around, then the kernel shouldn't forward audit data to kmsg"
> > > > >
> > > > > > From: Viswanath, Logeswari P (MCOU OSTL)
> > > > > > Sent: Thursday, January 29, 2015 11:49 AM
> > > > > > To: 'Satish Chandra Kilaru'; Steve Grubb
> > > > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;>
> > > > > > Subject: RE: Linux audit performance impact
> > > > > >
> > > > > > Is there any option to configure kaudit not to log audit 
> > > > > > records to
> > > > > syslog when auditd is running?
> > > > > > This way we can assess the impact of enabling audit without 
> > > > > > involving
> > > > > disk I/o overhead.
> > > > > >
> > > > > > From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com
> > > <javascript:;> <javascript:;>]
> > > > > > Sent: Thursday, January 29, 2015 9:12 AM
> > > > > > To: Steve Grubb
> > > > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;><mailto:
> > > linux-audit@redhat.com <javascript:;>
> > > > > <javascript:;>>; Viswanath,
> > > > > > Logeswari P (MCOU OSTL)
> > > > > > Subject: Re: Linux audit performance impact
> > > > > >
> > > > > > I agree with you... but writing to disk can trigger further 
> > > > > > events
> > > > > leading spiralling of events...
> > > > > > I brought down my server few times with stupid rules...
> > > > > >
> > > > > > On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb 
> > > > > > <sgrubb@redhat.com
> > > <javascript:;>
> > > > > <javascript:;><mailto:sgrubb@redhat.com <javascript:;>
> > > <javascript:;>>> wrote:
> > > > > > On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra 
> > > > > > Kilaru
> > > wrote:
> > > > > > > Write your own program to receive audit events directly 
> > > > > > > without using auditd...
> > > > > > > That should be faster ....
> > > > > > > Auditd will log the events to disk causing more I/o than u need...
> > > > > >
> > > > > > But even that is configurable in many ways. You can decide if 
> > > > > > you
> > > want
> > > > > > logging to disk or not and what kind of assurance that it made 
> > > > > > it to disk and the priority of that audit daemon. Then you 
> > > > > > also have all
> > > the
> > > > > > normal tuning knobs for disk throughput that you would use for 
> > > > > > any disk performance critical system.
> > > > > >
> > > > > > -Steve
> > > > > >
> > > > > > > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU 
> > > > > > > OSTL)
> > > <
> > > > > > >
> > > > > > > logeswari.pv@hp.com <javascript:;> <javascript:;><mailto:
> > > logeswari.pv@hp.com <javascript:;>
> > > > > <javascript:;>>> wrote:
> > > > > > > >  Hi Steve,
> > > > > > > >
> > > > > > > > I am Logeswari working for HP.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > We want to know audit performance impact on RHEL and Suse 
> > > > > > > > linux
> > > to
> > > > > > > > help us evaluate linux audit as data source for our host 
> > > > > > > > based
> > > IDS.
> > > > > > > >
> > > > > > > > When we ran our own performance test with a test audispd 
> > > > > > > > plugin, we found if a system can perform 200000 open/close 
> > > > > > > > system calls per second without auditing, system can 
> > > > > > > > perform only 3000 open/close system calls auditing is 
> > > > > > > > enabled for open/close system call which is a HUGE impact 
> > > > > > > > on the system performance. It would
> > > be
> > > > > > > > great if anyone can help us answering the following questions.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 1)      Is this performance impact expected? If yes, what is the
> > > > > reason
> > > > > > > > behind it and can we fix it?
> > > > > > > >
> > > > > > > > 2)      Have anyone done any benchmarking for performance
> > > impact? If
> > > > > yes,
> > > > > > > > can you please share the numbers and also the 
> > > > > > > > steps/programs used the run the same.
> > > > > > > >
> > > > > > > > 3)      Help us validating the performance test we have done in
> > > our
> > > > > test
> > > > > > > > setup using the steps mentioned along with the results attached.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Attached test program (loader.c) to invoke open and close 
> > > > > > > > system
> > > > > calls.
> > > > > > > >
> > > > > > > > Attached idskerndsp is the audispd plugin program.
> > > > > > > >
> > > > > > > > We used time command to determine how much time the system 
> > > > > > > > took
> > > to
> > > > > > > > complete 50000 open/close system calls without (results 
> > > > > > > > attached
> > > > > > > > Without-auditing) and with auditing enabled on the system 
> > > > > > > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > System details:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 1 CPU machine
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > *OS Version*
> > > > > > > >
> > > > > > > > RHEL 6.5
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > *Kernel Version*
> > > > > > > >
> > > > > > > > uname –r
> > > > > > > >
> > > > > > > > 2.6.32-431.el6.x86_64
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Note: auditd was occupying 35% of CPU and was sleeping for 
> > > > > > > > most
> > > of
> > > > > > > > the time whereas kauditd was occupying 20% of the CPU.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks & Regards,
> > > > > > > >
> > > > > > > > Logeswari.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Please Donate to www.wikipedia.org<http://www.wikipedia.org>
> > > > >
> > > > > > --
> > > > > > Linux-audit mailing list
> > > > > > Linux-audit@redhat.com <javascript:;> <javascript:;> 
> > > > > > https://www.redhat.com/mailman/listinfo/linux-audit
> > > > >
> > > > >
> > > > > - RGB
> > > > >
> > > > > --
> > > > > Richard Guy Briggs <rbriggs@redhat.com <javascript:;> 
> > > > > <javascript:;>> Senior Software Engineer, Kernel Security, AMER 
> > > > > ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada
> > > > > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: 
> > > > > +1.613.693.0684x3545
> > > > >
> > > >
> > > >
> > > > --
> > > > Please Donate to www.wikipedia.org
> > >
> > > - RGB
> > >
> > > --
> > > Richard Guy Briggs <rbriggs@redhat.com <javascript:;>> Senior 
> > > Software Engineer, Kernel Security, AMER ENG Base Operating Systems, 
> > > Red Hat Remote, Ottawa, Canada
> > > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: 
> > > +1.613.693.0684x3545
> > >
> > 
> > 
> > --
> > Please Donate to www.wikipedia.org
> 
> - RGB
> 
> --
> Richard Guy Briggs <rbriggs@redhat.com>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

^ permalink raw reply

* RE: Linux audit performance impact
From: Viswanath, Logeswari P (MCOU OSTL) @ 2015-02-04  8:52 UTC (permalink / raw)
  To: Richard Guy Briggs, Satish Chandra Kilaru; +Cc: linux-audit@redhat.com
In-Reply-To: <20150203170258.GB18752@madcap2.tricolour.ca>

The intent is to calculate the performance impact by the auditing components such as 

1) impact because of kauditd without auditd - but kauditd writes to syslog, so we are unable to determine the impact just because of kauditd - It is fine even if the audit record is dropped by kauditd. Is there any way to do this?
2) impact because of running auditd - log format NOLOG
3) impact because of running audispd - small plugin is written which will just read the audit records and doesn't processes it.

-----Original Message-----
From: Richard Guy Briggs [mailto:rgb@redhat.com] 
Sent: Tuesday, February 03, 2015 10:33 PM
To: Satish Chandra Kilaru
Cc: Viswanath, Logeswari P (MCOU OSTL); Steve Grubb; linux-audit@redhat.com
Subject: Re: Linux audit performance impact

On 15/02/03, Satish Chandra Kilaru wrote:
> Thanks for The info. But my question was rhetorical... I meant to say 
> that it would not be much... She is trying to bombard the system with 
> open calls ... So lots and lots of events will be generated and kernel 
> has to write down the events some where or discard them...

Exactly.  It is of little practical use.  You have to do I/O at some point, either to the same disk or another, or to a network interface or serial port, otherwise, just chuck it out.  You could do a performance measurement on a short burst, then drain the queue, but what will that actually tell us?

> On Tuesday, February 3, 2015, Richard Guy Briggs <rgb@redhat.com> wrote:
> 
> > On 15/02/03, Satish Chandra Kilaru wrote:
> > > How many events can kernel accumulate without I/o ?
> >
> > The kernel default is 64 *buffers*, but I think Fedora and RHEL set 
> > it to 320.  It is now possible to set it to "0" which means limited 
> > only by system resources.  See "man auditctl", "-b" option.  An 
> > event can be made up of several buffers.
> >
> > Of course, how long a system lasts before the queue blows up depends 
> > on your rule set...
> >
> > However, at the moment, it will still write out to klog if auditd 
> > isn't running.
> >
> > > On Tuesday, February 3, 2015, Viswanath, Logeswari P (MCOU OSTL) < 
> > > logeswari.pv@hp.com <javascript:;>> wrote:
> > >
> > > > I don't want to disable auditing (i.e. disable audit record
> > collection),
> > > > but just do not want the records to delivered to user space 
> > > > since I
> > want to
> > > > remove the I/O overhead while running the performance test.
> > > > Is there any option for this?
> > > >
> > > > -----Original Message-----
> > > > From: Richard Guy Briggs [mailto:rgb@redhat.com <javascript:;>
> > <javascript:;>]
> > > > Sent: Thursday, January 29, 2015 10:23 PM
> > > > To: Viswanath, Logeswari P (MCOU OSTL)
> > > > Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
> > <javascript:;>
> > > > <javascript:;>
> > > > Subject: Re: Linux audit performance impact
> > > >
> > > > On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> > > > > Please read my question as “Is there any option to configure 
> > > > > kaudit not to log audit records to syslog? when auditd not running.”
> > > >
> > > > Yeah, remove audit=1 from the kernel command line, or set 
> > > > audit=0 in
> > its
> > > > place.  This will stop all but AVCs and if auditd has ever run 
> > > > since
> > boot.
> > > > If audit=0 is on the kernel boot line, it will be impossible to 
> > > > run
> > auditd.
> > > >
> > > > There is a feature request that is likely coming soon that could 
> > > > be
> > > > useful:
> > > >
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> > > > "If no audit daemon is running, but an audit multicast 
> > > > subscriber is around, then the kernel shouldn't forward audit data to kmsg"
> > > >
> > > > > From: Viswanath, Logeswari P (MCOU OSTL)
> > > > > Sent: Thursday, January 29, 2015 11:49 AM
> > > > > To: 'Satish Chandra Kilaru'; Steve Grubb
> > > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;>
> > > > > Subject: RE: Linux audit performance impact
> > > > >
> > > > > Is there any option to configure kaudit not to log audit 
> > > > > records to
> > > > syslog when auditd is running?
> > > > > This way we can assess the impact of enabling audit without 
> > > > > involving
> > > > disk I/o overhead.
> > > > >
> > > > > From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com
> > <javascript:;> <javascript:;>]
> > > > > Sent: Thursday, January 29, 2015 9:12 AM
> > > > > To: Steve Grubb
> > > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;><mailto:
> > linux-audit@redhat.com <javascript:;>
> > > > <javascript:;>>; Viswanath,
> > > > > Logeswari P (MCOU OSTL)
> > > > > Subject: Re: Linux audit performance impact
> > > > >
> > > > > I agree with you... but writing to disk can trigger further 
> > > > > events
> > > > leading spiralling of events...
> > > > > I brought down my server few times with stupid rules...
> > > > >
> > > > > On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb 
> > > > > <sgrubb@redhat.com
> > <javascript:;>
> > > > <javascript:;><mailto:sgrubb@redhat.com <javascript:;>
> > <javascript:;>>> wrote:
> > > > > On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra 
> > > > > Kilaru
> > wrote:
> > > > > > Write your own program to receive audit events directly 
> > > > > > without using auditd...
> > > > > > That should be faster ....
> > > > > > Auditd will log the events to disk causing more I/o than u need...
> > > > >
> > > > > But even that is configurable in many ways. You can decide if 
> > > > > you
> > want
> > > > > logging to disk or not and what kind of assurance that it made 
> > > > > it to disk and the priority of that audit daemon. Then you 
> > > > > also have all
> > the
> > > > > normal tuning knobs for disk throughput that you would use for 
> > > > > any disk performance critical system.
> > > > >
> > > > > -Steve
> > > > >
> > > > > > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU 
> > > > > > OSTL)
> > <
> > > > > >
> > > > > > logeswari.pv@hp.com <javascript:;> <javascript:;><mailto:
> > logeswari.pv@hp.com <javascript:;>
> > > > <javascript:;>>> wrote:
> > > > > > >  Hi Steve,
> > > > > > >
> > > > > > > I am Logeswari working for HP.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > We want to know audit performance impact on RHEL and Suse 
> > > > > > > linux
> > to
> > > > > > > help us evaluate linux audit as data source for our host 
> > > > > > > based
> > IDS.
> > > > > > >
> > > > > > > When we ran our own performance test with a test audispd 
> > > > > > > plugin, we found if a system can perform 200000 open/close 
> > > > > > > system calls per second without auditing, system can 
> > > > > > > perform only 3000 open/close system calls auditing is 
> > > > > > > enabled for open/close system call which is a HUGE impact 
> > > > > > > on the system performance. It would
> > be
> > > > > > > great if anyone can help us answering the following questions.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 1)      Is this performance impact expected? If yes, what is the
> > > > reason
> > > > > > > behind it and can we fix it?
> > > > > > >
> > > > > > > 2)      Have anyone done any benchmarking for performance
> > impact? If
> > > > yes,
> > > > > > > can you please share the numbers and also the 
> > > > > > > steps/programs used the run the same.
> > > > > > >
> > > > > > > 3)      Help us validating the performance test we have done in
> > our
> > > > test
> > > > > > > setup using the steps mentioned along with the results attached.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Attached test program (loader.c) to invoke open and close 
> > > > > > > system
> > > > calls.
> > > > > > >
> > > > > > > Attached idskerndsp is the audispd plugin program.
> > > > > > >
> > > > > > > We used time command to determine how much time the system 
> > > > > > > took
> > to
> > > > > > > complete 50000 open/close system calls without (results 
> > > > > > > attached
> > > > > > > Without-auditing) and with auditing enabled on the system 
> > > > > > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > System details:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 1 CPU machine
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > *OS Version*
> > > > > > >
> > > > > > > RHEL 6.5
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > *Kernel Version*
> > > > > > >
> > > > > > > uname –r
> > > > > > >
> > > > > > > 2.6.32-431.el6.x86_64
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Note: auditd was occupying 35% of CPU and was sleeping for 
> > > > > > > most
> > of
> > > > > > > the time whereas kauditd was occupying 20% of the CPU.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thanks & Regards,
> > > > > > >
> > > > > > > Logeswari.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Please Donate to www.wikipedia.org<http://www.wikipedia.org>
> > > >
> > > > > --
> > > > > Linux-audit mailing list
> > > > > Linux-audit@redhat.com <javascript:;> <javascript:;> 
> > > > > https://www.redhat.com/mailman/listinfo/linux-audit
> > > >
> > > >
> > > > - RGB
> > > >
> > > > --
> > > > Richard Guy Briggs <rbriggs@redhat.com <javascript:;> 
> > > > <javascript:;>> Senior Software Engineer, Kernel Security, AMER 
> > > > ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada
> > > > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: 
> > > > +1.613.693.0684x3545
> > > >
> > >
> > >
> > > --
> > > Please Donate to www.wikipedia.org
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rbriggs@redhat.com <javascript:;>> Senior 
> > Software Engineer, Kernel Security, AMER ENG Base Operating Systems, 
> > Red Hat Remote, Ottawa, Canada
> > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: 
> > +1.613.693.0684x3545
> >
> 
> 
> --
> Please Donate to www.wikipedia.org

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

^ permalink raw reply

* confusing with open system call in Linux kernel
From: Alan TaN @ 2015-02-04  2:59 UTC (permalink / raw)
  To: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 2883 bytes --]

Hi everyone,

 

I am new here, so I am not exactly sure if this is the right place to ask
this. I apologise in advance if this is not the right place. 

I would like to ask if anyone has encountered the issue below. 

 

I am trying to track a set of file accesses system calls in a Linux system
(for experimental purposes) and used the following subset of rules with the
audit.rules file.

 

-a exit,always -F arch=b64 -S creat -S read -S write -S rename -S open -S
close

 

What I noticed was that for the open system call, when opening an existing
file for writing purpose, the file name would result in a 'null' value like
shown:

 

type=SYSCALL msg=audit(1423018198.026:20826531): arch=c000003e syscall=2
success=yes exit=4 a0=400865 a1=241 a2=1b6 a3=0 items=2 ppid=9093 pid=9169
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1
ses=3805 comm="readfile" exe="/root/prov_project/script/readfile"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

type=CWD msg=audit(1423018198.026:20826531):
cwd="/root/prov_project/script"

type=PATH msg=audit(1423018198.026:20826531): item=0
name="/root/prov_project/script" inode=311564 dev=fd:01 mode=040755 ouid=0
ogid=0 rdev=00:00 obj=unconfined_u:object_r:admin_home_t:s0 nametype=PARENT

type=PATH msg=audit(1423018198.026:20826531): item=1 name=(null)
inode=269089 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
obj=unconfined_u:object_r:admin_home_t:s0 nametype=NORMAL

 

 

However, opening the same file with read only mode or opening a non-existing
file (which in that case the open system call would create the file) would
result in the file name being captured as shown:  

 

type=SYSCALL msg=audit(1423018196.556:20826486): arch=c000003e syscall=2
success=yes exit=4 a0=400865 a1=241 a2=1b6 a3=0 items=2 ppid=9093 pid=9168
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1
ses=3805 comm="readfile" exe="/root/prov_project/script/readfile"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

type=CWD msg=audit(1423018196.556:20826486):
cwd="/root/prov_project/script"

type=PATH msg=audit(1423018196.556:20826486): item=0
name="/root/prov_project/script" inode=311564 dev=fd:01 mode=040755 ouid=0
ogid=0 rdev=00:00 obj=unconfined_u:object_r:admin_home_t:s0 nametype=PARENT

type=PATH msg=audit(1423018196.556:20826486): item=1 name="sample_text.txt"
inode=269089 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
obj=unconfined_u:object_r:admin_home_t:s0 nametype=CREATE

 

Hence the question: Is this an intended feature or a bug? 

 

Appreciate if anyone can shed some light on this.

 

To reproduce:  write to a non-existing file first, close it and then open
and write to the same file again.

 

I am running version 2.3.7-5 of the audit framework and on CentOS 6.4
(kernel version 2.6.32-431) 

 

Thank you.

 

Cheers,

Alan

 


[-- Attachment #1.2: Type: text/html, Size: 6034 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: Filtering Connect syscalls for af_inet only
From: F Rafi @ 2015-02-03 23:53 UTC (permalink / raw)
  To: Peter Moody; +Cc: linux-audit
In-Reply-To: <CABXp1csz7aTWDVn24P0T0os6Sde_2sT5No8scOHqaaw7auUQWw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2403 bytes --]

Correction. Both filetype=socket and !=socket result in just saddr=0100..
events. Seems like this is not the way to go.

Farhan

On Tue, Feb 3, 2015 at 6:24 PM, F Rafi <farhanible@gmail.com> wrote:

> Sorry, I should have mentioned that I already tried that. That results in
> no logs being generated for that rule.
>
> Thanks,
> Farhan
>
> On Tue, Feb 3, 2015 at 6:21 PM, Peter Moody <pmoody@google.com> wrote:
>
>>
>> On Tue, Feb 03 2015 at 14:57, F Rafi wrote:
>> > Hi folks,
>> >
>> > <n00b alert>
>> >
>> > I have auditing for outbound connect requests working using the Connect
>> > (sys_connect) syscall on a server running *Ubuntu precise 12.04 LTS*.
>> >
>> > The rule I'm using is:
>> >
>> > -a exit,always -F arch=b64 -S connect -k network_outbound
>> >
>> >
>> >
>> > I'm getting a substantial amount of saddr=0100.... logs, which I
>> understand
>> > are not  connections to a remote host but rather a local AF_UNIX socket
>> > pointing to a file. Example log message is:
>> >
>> >
>> >
>> > type=SYSCALL msg=audit(1423002916.796:24545371): arch=c000003e
>> syscall=42
>> >> success=no exit=-2 a0=294 a1=7fff97f62680 a2=6e a3=7fff97f62860 items=0
>> >> ppid=20546 pid=21439 auid=4294967295 uid=33 gid=33 euid=33 suid=33
>> fsuid=33
>> >> egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="apache2"
>> >> exe="/usr/lib/apache2/mpm-prefork/apache2" key="network_outbound"
>> >
>> > type=SOCKADDR msg=audit(1423002916.796:24545371):
>> *saddr=0100*<truncated to
>> >> remove the hex-encoded file path>
>> >
>> >
>> > Is there an easy way to filter these out so that we only have
>> saddr=0200...
>> > messages left?
>> >
>> > I'm exporting the log to an external syslog server and it would help
>> > considerably if I could eliminate this from all of our servers.
>> >
>> > I see that auditctl has a *filetype* filter which can be set to filter
>> > *socket* or *file* types. Is that the right way to filter these
>> messages?
>> >
>> > -a exit,always -F arch=b64 -F filetype=socket -S connect -k
>> network_outbound
>>
>> does -F filetype!=socket work?
>>
>> > The above rule filters out everything but the af_unix connect syscalls,
>> > which is the opposite of what I'm looking for.
>> >
>> > Any help would be appreciated.
>> >
>> > Thanks,
>> > Farhan
>> > --
>> > Linux-audit mailing list
>> > Linux-audit@redhat.com
>> > https://www.redhat.com/mailman/listinfo/linux-audit
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3652 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: Filtering Connect syscalls for af_inet only
From: F Rafi @ 2015-02-03 23:24 UTC (permalink / raw)
  To: Peter Moody; +Cc: linux-audit
In-Reply-To: <r3na90uvaxh.fsf@perdido.sfo.corp.google.com>


[-- Attachment #1.1: Type: text/plain, Size: 2120 bytes --]

Sorry, I should have mentioned that I already tried that. That results in
no logs being generated for that rule.

Thanks,
Farhan

On Tue, Feb 3, 2015 at 6:21 PM, Peter Moody <pmoody@google.com> wrote:

>
> On Tue, Feb 03 2015 at 14:57, F Rafi wrote:
> > Hi folks,
> >
> > <n00b alert>
> >
> > I have auditing for outbound connect requests working using the Connect
> > (sys_connect) syscall on a server running *Ubuntu precise 12.04 LTS*.
> >
> > The rule I'm using is:
> >
> > -a exit,always -F arch=b64 -S connect -k network_outbound
> >
> >
> >
> > I'm getting a substantial amount of saddr=0100.... logs, which I
> understand
> > are not  connections to a remote host but rather a local AF_UNIX socket
> > pointing to a file. Example log message is:
> >
> >
> >
> > type=SYSCALL msg=audit(1423002916.796:24545371): arch=c000003e syscall=42
> >> success=no exit=-2 a0=294 a1=7fff97f62680 a2=6e a3=7fff97f62860 items=0
> >> ppid=20546 pid=21439 auid=4294967295 uid=33 gid=33 euid=33 suid=33
> fsuid=33
> >> egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="apache2"
> >> exe="/usr/lib/apache2/mpm-prefork/apache2" key="network_outbound"
> >
> > type=SOCKADDR msg=audit(1423002916.796:24545371): *saddr=0100*<truncated
> to
> >> remove the hex-encoded file path>
> >
> >
> > Is there an easy way to filter these out so that we only have
> saddr=0200...
> > messages left?
> >
> > I'm exporting the log to an external syslog server and it would help
> > considerably if I could eliminate this from all of our servers.
> >
> > I see that auditctl has a *filetype* filter which can be set to filter
> > *socket* or *file* types. Is that the right way to filter these messages?
> >
> > -a exit,always -F arch=b64 -F filetype=socket -S connect -k
> network_outbound
>
> does -F filetype!=socket work?
>
> > The above rule filters out everything but the af_unix connect syscalls,
> > which is the opposite of what I'm looking for.
> >
> > Any help would be appreciated.
> >
> > Thanks,
> > Farhan
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>

[-- Attachment #1.2: Type: text/html, Size: 3147 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: Filtering Connect syscalls for af_inet only
From: Peter Moody @ 2015-02-03 23:21 UTC (permalink / raw)
  To: F Rafi; +Cc: linux-audit
In-Reply-To: <CABXp1cs4rj_BN+QLvHSFnYJhigQpjL2kcFGbE1EPm8rJGnfP2A@mail.gmail.com>


On Tue, Feb 03 2015 at 14:57, F Rafi wrote:
> Hi folks,
>
> <n00b alert>
>
> I have auditing for outbound connect requests working using the Connect
> (sys_connect) syscall on a server running *Ubuntu precise 12.04 LTS*.
>
> The rule I'm using is:
>
> -a exit,always -F arch=b64 -S connect -k network_outbound
>
>
>
> I'm getting a substantial amount of saddr=0100.... logs, which I understand
> are not  connections to a remote host but rather a local AF_UNIX socket
> pointing to a file. Example log message is:
>
>
>
> type=SYSCALL msg=audit(1423002916.796:24545371): arch=c000003e syscall=42
>> success=no exit=-2 a0=294 a1=7fff97f62680 a2=6e a3=7fff97f62860 items=0
>> ppid=20546 pid=21439 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33
>> egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="apache2"
>> exe="/usr/lib/apache2/mpm-prefork/apache2" key="network_outbound"
>
> type=SOCKADDR msg=audit(1423002916.796:24545371): *saddr=0100*<truncated to
>> remove the hex-encoded file path>
>
>
> Is there an easy way to filter these out so that we only have saddr=0200...
> messages left?
>
> I'm exporting the log to an external syslog server and it would help
> considerably if I could eliminate this from all of our servers.
>
> I see that auditctl has a *filetype* filter which can be set to filter
> *socket* or *file* types. Is that the right way to filter these messages?
>
> -a exit,always -F arch=b64 -F filetype=socket -S connect -k network_outbound

does -F filetype!=socket work?

> The above rule filters out everything but the af_unix connect syscalls,
> which is the opposite of what I'm looking for.
>
> Any help would be appreciated.
>
> Thanks,
> Farhan
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

^ permalink raw reply

* Filtering Connect syscalls for af_inet only
From: F Rafi @ 2015-02-03 22:57 UTC (permalink / raw)
  To: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 1543 bytes --]

Hi folks,

<n00b alert>

I have auditing for outbound connect requests working using the Connect
(sys_connect) syscall on a server running *Ubuntu precise 12.04 LTS*.

The rule I'm using is:

-a exit,always -F arch=b64 -S connect -k network_outbound



I'm getting a substantial amount of saddr=0100.... logs, which I understand
are not  connections to a remote host but rather a local AF_UNIX socket
pointing to a file. Example log message is:



type=SYSCALL msg=audit(1423002916.796:24545371): arch=c000003e syscall=42
> success=no exit=-2 a0=294 a1=7fff97f62680 a2=6e a3=7fff97f62860 items=0
> ppid=20546 pid=21439 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33
> egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="apache2"
> exe="/usr/lib/apache2/mpm-prefork/apache2" key="network_outbound"

type=SOCKADDR msg=audit(1423002916.796:24545371): *saddr=0100*<truncated to
> remove the hex-encoded file path>


Is there an easy way to filter these out so that we only have saddr=0200...
messages left?

I'm exporting the log to an external syslog server and it would help
considerably if I could eliminate this from all of our servers.

I see that auditctl has a *filetype* filter which can be set to filter
*socket* or *file* types. Is that the right way to filter these messages?

-a exit,always -F arch=b64 -F filetype=socket -S connect -k network_outbound


The above rule filters out everything but the af_unix connect syscalls,
which is the opposite of what I'm looking for.

Any help would be appreciated.

Thanks,
Farhan

[-- Attachment #1.2: Type: text/html, Size: 2756 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: Linux audit performance impact
From: Richard Guy Briggs @ 2015-02-03 17:02 UTC (permalink / raw)
  To: Satish Chandra Kilaru
  Cc: linux-audit@redhat.com, Viswanath, Logeswari P (MCOU OSTL)
In-Reply-To: <CAAnai+XEVPsW7JcU-N9yHf4O44CQ=jVSAvH9C13OR0MmmpS=1Q@mail.gmail.com>

On 15/02/03, Satish Chandra Kilaru wrote:
> Thanks for The info. But my question was rhetorical... I meant to say that
> it would not be much... She is trying to bombard the system with open calls
> ... So lots and lots of events will be generated and kernel has to write
> down the events some where or discard them...

Exactly.  It is of little practical use.  You have to do I/O at some
point, either to the same disk or another, or to a network interface or
serial port, otherwise, just chuck it out.  You could do a performance
measurement on a short burst, then drain the queue, but what will that
actually tell us?

> On Tuesday, February 3, 2015, Richard Guy Briggs <rgb@redhat.com> wrote:
> 
> > On 15/02/03, Satish Chandra Kilaru wrote:
> > > How many events can kernel accumulate without I/o ?
> >
> > The kernel default is 64 *buffers*, but I think Fedora and RHEL set it
> > to 320.  It is now possible to set it to "0" which means limited only by
> > system resources.  See "man auditctl", "-b" option.  An event can be
> > made up of several buffers.
> >
> > Of course, how long a system lasts before the queue blows up depends on
> > your rule set...
> >
> > However, at the moment, it will still write out to klog if auditd isn't
> > running.
> >
> > > On Tuesday, February 3, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> > > logeswari.pv@hp.com <javascript:;>> wrote:
> > >
> > > > I don't want to disable auditing (i.e. disable audit record
> > collection),
> > > > but just do not want the records to delivered to user space since I
> > want to
> > > > remove the I/O overhead while running the performance test.
> > > > Is there any option for this?
> > > >
> > > > -----Original Message-----
> > > > From: Richard Guy Briggs [mailto:rgb@redhat.com <javascript:;>
> > <javascript:;>]
> > > > Sent: Thursday, January 29, 2015 10:23 PM
> > > > To: Viswanath, Logeswari P (MCOU OSTL)
> > > > Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
> > <javascript:;>
> > > > <javascript:;>
> > > > Subject: Re: Linux audit performance impact
> > > >
> > > > On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> > > > > Please read my question as “Is there any option to configure kaudit
> > > > > not to log audit records to syslog? when auditd not running.”
> > > >
> > > > Yeah, remove audit=1 from the kernel command line, or set audit=0 in
> > its
> > > > place.  This will stop all but AVCs and if auditd has ever run since
> > boot.
> > > > If audit=0 is on the kernel boot line, it will be impossible to run
> > auditd.
> > > >
> > > > There is a feature request that is likely coming soon that could be
> > > > useful:
> > > >
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> > > > "If no audit daemon is running, but an audit multicast subscriber is
> > > > around, then the kernel shouldn't forward audit data to kmsg"
> > > >
> > > > > From: Viswanath, Logeswari P (MCOU OSTL)
> > > > > Sent: Thursday, January 29, 2015 11:49 AM
> > > > > To: 'Satish Chandra Kilaru'; Steve Grubb
> > > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;>
> > > > > Subject: RE: Linux audit performance impact
> > > > >
> > > > > Is there any option to configure kaudit not to log audit records to
> > > > syslog when auditd is running?
> > > > > This way we can assess the impact of enabling audit without involving
> > > > disk I/o overhead.
> > > > >
> > > > > From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com
> > <javascript:;> <javascript:;>]
> > > > > Sent: Thursday, January 29, 2015 9:12 AM
> > > > > To: Steve Grubb
> > > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;><mailto:
> > linux-audit@redhat.com <javascript:;>
> > > > <javascript:;>>; Viswanath,
> > > > > Logeswari P (MCOU OSTL)
> > > > > Subject: Re: Linux audit performance impact
> > > > >
> > > > > I agree with you... but writing to disk can trigger further events
> > > > leading spiralling of events...
> > > > > I brought down my server few times with stupid rules...
> > > > >
> > > > > On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com
> > <javascript:;>
> > > > <javascript:;><mailto:sgrubb@redhat.com <javascript:;>
> > <javascript:;>>> wrote:
> > > > > On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru
> > wrote:
> > > > > > Write your own program to receive audit events directly without
> > > > > > using auditd...
> > > > > > That should be faster ....
> > > > > > Auditd will log the events to disk causing more I/o than u need...
> > > > >
> > > > > But even that is configurable in many ways. You can decide if you
> > want
> > > > > logging to disk or not and what kind of assurance that it made it to
> > > > > disk and the priority of that audit daemon. Then you also have all
> > the
> > > > > normal tuning knobs for disk throughput that you would use for any
> > > > > disk performance critical system.
> > > > >
> > > > > -Steve
> > > > >
> > > > > > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL)
> > <
> > > > > >
> > > > > > logeswari.pv@hp.com <javascript:;> <javascript:;><mailto:
> > logeswari.pv@hp.com <javascript:;>
> > > > <javascript:;>>> wrote:
> > > > > > >  Hi Steve,
> > > > > > >
> > > > > > > I am Logeswari working for HP.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > We want to know audit performance impact on RHEL and Suse linux
> > to
> > > > > > > help us evaluate linux audit as data source for our host based
> > IDS.
> > > > > > >
> > > > > > > When we ran our own performance test with a test audispd plugin,
> > > > > > > we found if a system can perform 200000 open/close system calls
> > > > > > > per second without auditing, system can perform only 3000
> > > > > > > open/close system calls auditing is enabled for open/close system
> > > > > > > call which is a HUGE impact on the system performance. It would
> > be
> > > > > > > great if anyone can help us answering the following questions.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 1)      Is this performance impact expected? If yes, what is the
> > > > reason
> > > > > > > behind it and can we fix it?
> > > > > > >
> > > > > > > 2)      Have anyone done any benchmarking for performance
> > impact? If
> > > > yes,
> > > > > > > can you please share the numbers and also the steps/programs used
> > > > > > > the run the same.
> > > > > > >
> > > > > > > 3)      Help us validating the performance test we have done in
> > our
> > > > test
> > > > > > > setup using the steps mentioned along with the results attached.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Attached test program (loader.c) to invoke open and close system
> > > > calls.
> > > > > > >
> > > > > > > Attached idskerndsp is the audispd plugin program.
> > > > > > >
> > > > > > > We used time command to determine how much time the system took
> > to
> > > > > > > complete 50000 open/close system calls without (results attached
> > > > > > > Without-auditing) and with auditing enabled on the system
> > > > > > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > System details:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 1 CPU machine
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > *OS Version*
> > > > > > >
> > > > > > > RHEL 6.5
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > *Kernel Version*
> > > > > > >
> > > > > > > uname –r
> > > > > > >
> > > > > > > 2.6.32-431.el6.x86_64
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Note: auditd was occupying 35% of CPU and was sleeping for most
> > of
> > > > > > > the time whereas kauditd was occupying 20% of the CPU.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thanks & Regards,
> > > > > > >
> > > > > > > Logeswari.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Please Donate to www.wikipedia.org<http://www.wikipedia.org>
> > > >
> > > > > --
> > > > > Linux-audit mailing list
> > > > > Linux-audit@redhat.com <javascript:;> <javascript:;>
> > > > > https://www.redhat.com/mailman/listinfo/linux-audit
> > > >
> > > >
> > > > - RGB
> > > >
> > > > --
> > > > Richard Guy Briggs <rbriggs@redhat.com <javascript:;> <javascript:;>>
> > > > Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> > > > Systems, Red Hat Remote, Ottawa, Canada
> > > > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
> > > >
> > >
> > >
> > > --
> > > Please Donate to www.wikipedia.org
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rbriggs@redhat.com <javascript:;>>
> > Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> > Systems, Red Hat
> > Remote, Ottawa, Canada
> > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
> >
> 
> 
> -- 
> Please Donate to www.wikipedia.org

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

^ permalink raw reply

* Re: Linux audit performance impact
From: Satish Chandra Kilaru @ 2015-02-03 16:54 UTC (permalink / raw)
  To: Richard Guy Briggs
  Cc: linux-audit@redhat.com, Viswanath, Logeswari P (MCOU OSTL)
In-Reply-To: <20150203164531.GZ18752@madcap2.tricolour.ca>


[-- Attachment #1.1: Type: text/plain, Size: 8263 bytes --]

Thanks for The info. But my question was rhetorical... I meant to say that
it would not be much... She is trying to bombard the system with open calls
... So lots and lots of events will be generated and kernel has to write
down the events some where or discard them...

On Tuesday, February 3, 2015, Richard Guy Briggs <rgb@redhat.com> wrote:

> On 15/02/03, Satish Chandra Kilaru wrote:
> > How many events can kernel accumulate without I/o ?
>
> The kernel default is 64 *buffers*, but I think Fedora and RHEL set it
> to 320.  It is now possible to set it to "0" which means limited only by
> system resources.  See "man auditctl", "-b" option.  An event can be
> made up of several buffers.
>
> Of course, how long a system lasts before the queue blows up depends on
> your rule set...
>
> However, at the moment, it will still write out to klog if auditd isn't
> running.
>
> > On Tuesday, February 3, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> > logeswari.pv@hp.com <javascript:;>> wrote:
> >
> > > I don't want to disable auditing (i.e. disable audit record
> collection),
> > > but just do not want the records to delivered to user space since I
> want to
> > > remove the I/O overhead while running the performance test.
> > > Is there any option for this?
> > >
> > > -----Original Message-----
> > > From: Richard Guy Briggs [mailto:rgb@redhat.com <javascript:;>
> <javascript:;>]
> > > Sent: Thursday, January 29, 2015 10:23 PM
> > > To: Viswanath, Logeswari P (MCOU OSTL)
> > > Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
> <javascript:;>
> > > <javascript:;>
> > > Subject: Re: Linux audit performance impact
> > >
> > > On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> > > > Please read my question as “Is there any option to configure kaudit
> > > > not to log audit records to syslog? when auditd not running.”
> > >
> > > Yeah, remove audit=1 from the kernel command line, or set audit=0 in
> its
> > > place.  This will stop all but AVCs and if auditd has ever run since
> boot.
> > > If audit=0 is on the kernel boot line, it will be impossible to run
> auditd.
> > >
> > > There is a feature request that is likely coming soon that could be
> > > useful:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> > > "If no audit daemon is running, but an audit multicast subscriber is
> > > around, then the kernel shouldn't forward audit data to kmsg"
> > >
> > > > From: Viswanath, Logeswari P (MCOU OSTL)
> > > > Sent: Thursday, January 29, 2015 11:49 AM
> > > > To: 'Satish Chandra Kilaru'; Steve Grubb
> > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;>
> > > > Subject: RE: Linux audit performance impact
> > > >
> > > > Is there any option to configure kaudit not to log audit records to
> > > syslog when auditd is running?
> > > > This way we can assess the impact of enabling audit without involving
> > > disk I/o overhead.
> > > >
> > > > From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com
> <javascript:;> <javascript:;>]
> > > > Sent: Thursday, January 29, 2015 9:12 AM
> > > > To: Steve Grubb
> > > > Cc: linux-audit@redhat.com <javascript:;> <javascript:;><mailto:
> linux-audit@redhat.com <javascript:;>
> > > <javascript:;>>; Viswanath,
> > > > Logeswari P (MCOU OSTL)
> > > > Subject: Re: Linux audit performance impact
> > > >
> > > > I agree with you... but writing to disk can trigger further events
> > > leading spiralling of events...
> > > > I brought down my server few times with stupid rules...
> > > >
> > > > On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com
> <javascript:;>
> > > <javascript:;><mailto:sgrubb@redhat.com <javascript:;>
> <javascript:;>>> wrote:
> > > > On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru
> wrote:
> > > > > Write your own program to receive audit events directly without
> > > > > using auditd...
> > > > > That should be faster ....
> > > > > Auditd will log the events to disk causing more I/o than u need...
> > > >
> > > > But even that is configurable in many ways. You can decide if you
> want
> > > > logging to disk or not and what kind of assurance that it made it to
> > > > disk and the priority of that audit daemon. Then you also have all
> the
> > > > normal tuning knobs for disk throughput that you would use for any
> > > > disk performance critical system.
> > > >
> > > > -Steve
> > > >
> > > > > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL)
> <
> > > > >
> > > > > logeswari.pv@hp.com <javascript:;> <javascript:;><mailto:
> logeswari.pv@hp.com <javascript:;>
> > > <javascript:;>>> wrote:
> > > > > >  Hi Steve,
> > > > > >
> > > > > > I am Logeswari working for HP.
> > > > > >
> > > > > >
> > > > > >
> > > > > > We want to know audit performance impact on RHEL and Suse linux
> to
> > > > > > help us evaluate linux audit as data source for our host based
> IDS.
> > > > > >
> > > > > > When we ran our own performance test with a test audispd plugin,
> > > > > > we found if a system can perform 200000 open/close system calls
> > > > > > per second without auditing, system can perform only 3000
> > > > > > open/close system calls auditing is enabled for open/close system
> > > > > > call which is a HUGE impact on the system performance. It would
> be
> > > > > > great if anyone can help us answering the following questions.
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1)      Is this performance impact expected? If yes, what is the
> > > reason
> > > > > > behind it and can we fix it?
> > > > > >
> > > > > > 2)      Have anyone done any benchmarking for performance
> impact? If
> > > yes,
> > > > > > can you please share the numbers and also the steps/programs used
> > > > > > the run the same.
> > > > > >
> > > > > > 3)      Help us validating the performance test we have done in
> our
> > > test
> > > > > > setup using the steps mentioned along with the results attached.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Attached test program (loader.c) to invoke open and close system
> > > calls.
> > > > > >
> > > > > > Attached idskerndsp is the audispd plugin program.
> > > > > >
> > > > > > We used time command to determine how much time the system took
> to
> > > > > > complete 50000 open/close system calls without (results attached
> > > > > > Without-auditing) and with auditing enabled on the system
> > > > > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > > > > >
> > > > > >
> > > > > >
> > > > > > System details:
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1 CPU machine
> > > > > >
> > > > > >
> > > > > >
> > > > > > *OS Version*
> > > > > >
> > > > > > RHEL 6.5
> > > > > >
> > > > > >
> > > > > >
> > > > > > *Kernel Version*
> > > > > >
> > > > > > uname –r
> > > > > >
> > > > > > 2.6.32-431.el6.x86_64
> > > > > >
> > > > > >
> > > > > >
> > > > > > Note: auditd was occupying 35% of CPU and was sleeping for most
> of
> > > > > > the time whereas kauditd was occupying 20% of the CPU.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks & Regards,
> > > > > >
> > > > > > Logeswari.
> > > >
> > > >
> > > >
> > > > --
> > > > Please Donate to www.wikipedia.org<http://www.wikipedia.org>
> > >
> > > > --
> > > > Linux-audit mailing list
> > > > Linux-audit@redhat.com <javascript:;> <javascript:;>
> > > > https://www.redhat.com/mailman/listinfo/linux-audit
> > >
> > >
> > > - RGB
> > >
> > > --
> > > Richard Guy Briggs <rbriggs@redhat.com <javascript:;> <javascript:;>>
> > > Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> > > Systems, Red Hat Remote, Ottawa, Canada
> > > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
> > >
> >
> >
> > --
> > Please Donate to www.wikipedia.org
>
> - RGB
>
> --
> Richard Guy Briggs <rbriggs@redhat.com <javascript:;>>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
>


-- 
Please Donate to www.wikipedia.org

[-- Attachment #1.2: Type: text/html, Size: 12271 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply

* Re: Linux audit performance impact
From: Richard Guy Briggs @ 2015-02-03 16:45 UTC (permalink / raw)
  To: Satish Chandra Kilaru
  Cc: linux-audit@redhat.com, Viswanath, Logeswari P (MCOU OSTL)
In-Reply-To: <CAAnai+XxzpQQq_-0=MCr2FBwxA0yfW_Y3ET6QiLBmC4fSrtc8w@mail.gmail.com>

On 15/02/03, Satish Chandra Kilaru wrote:
> How many events can kernel accumulate without I/o ?

The kernel default is 64 *buffers*, but I think Fedora and RHEL set it
to 320.  It is now possible to set it to "0" which means limited only by
system resources.  See "man auditctl", "-b" option.  An event can be
made up of several buffers.

Of course, how long a system lasts before the queue blows up depends on
your rule set...

However, at the moment, it will still write out to klog if auditd isn't
running.

> On Tuesday, February 3, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> logeswari.pv@hp.com> wrote:
> 
> > I don't want to disable auditing (i.e. disable audit record collection),
> > but just do not want the records to delivered to user space since I want to
> > remove the I/O overhead while running the performance test.
> > Is there any option for this?
> >
> > -----Original Message-----
> > From: Richard Guy Briggs [mailto:rgb@redhat.com <javascript:;>]
> > Sent: Thursday, January 29, 2015 10:23 PM
> > To: Viswanath, Logeswari P (MCOU OSTL)
> > Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
> > <javascript:;>
> > Subject: Re: Linux audit performance impact
> >
> > On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> > > Please read my question as “Is there any option to configure kaudit
> > > not to log audit records to syslog? when auditd not running.”
> >
> > Yeah, remove audit=1 from the kernel command line, or set audit=0 in its
> > place.  This will stop all but AVCs and if auditd has ever run since boot.
> > If audit=0 is on the kernel boot line, it will be impossible to run auditd.
> >
> > There is a feature request that is likely coming soon that could be
> > useful:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> > "If no audit daemon is running, but an audit multicast subscriber is
> > around, then the kernel shouldn't forward audit data to kmsg"
> >
> > > From: Viswanath, Logeswari P (MCOU OSTL)
> > > Sent: Thursday, January 29, 2015 11:49 AM
> > > To: 'Satish Chandra Kilaru'; Steve Grubb
> > > Cc: linux-audit@redhat.com <javascript:;>
> > > Subject: RE: Linux audit performance impact
> > >
> > > Is there any option to configure kaudit not to log audit records to
> > syslog when auditd is running?
> > > This way we can assess the impact of enabling audit without involving
> > disk I/o overhead.
> > >
> > > From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com <javascript:;>]
> > > Sent: Thursday, January 29, 2015 9:12 AM
> > > To: Steve Grubb
> > > Cc: linux-audit@redhat.com <javascript:;><mailto:linux-audit@redhat.com
> > <javascript:;>>; Viswanath,
> > > Logeswari P (MCOU OSTL)
> > > Subject: Re: Linux audit performance impact
> > >
> > > I agree with you... but writing to disk can trigger further events
> > leading spiralling of events...
> > > I brought down my server few times with stupid rules...
> > >
> > > On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com
> > <javascript:;><mailto:sgrubb@redhat.com <javascript:;>>> wrote:
> > > On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> > > > Write your own program to receive audit events directly without
> > > > using auditd...
> > > > That should be faster ....
> > > > Auditd will log the events to disk causing more I/o than u need...
> > >
> > > But even that is configurable in many ways. You can decide if you want
> > > logging to disk or not and what kind of assurance that it made it to
> > > disk and the priority of that audit daemon. Then you also have all the
> > > normal tuning knobs for disk throughput that you would use for any
> > > disk performance critical system.
> > >
> > > -Steve
> > >
> > > > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> > > >
> > > > logeswari.pv@hp.com <javascript:;><mailto:logeswari.pv@hp.com
> > <javascript:;>>> wrote:
> > > > >  Hi Steve,
> > > > >
> > > > > I am Logeswari working for HP.
> > > > >
> > > > >
> > > > >
> > > > > We want to know audit performance impact on RHEL and Suse linux to
> > > > > help us evaluate linux audit as data source for our host based IDS.
> > > > >
> > > > > When we ran our own performance test with a test audispd plugin,
> > > > > we found if a system can perform 200000 open/close system calls
> > > > > per second without auditing, system can perform only 3000
> > > > > open/close system calls auditing is enabled for open/close system
> > > > > call which is a HUGE impact on the system performance. It would be
> > > > > great if anyone can help us answering the following questions.
> > > > >
> > > > >
> > > > >
> > > > > 1)      Is this performance impact expected? If yes, what is the
> > reason
> > > > > behind it and can we fix it?
> > > > >
> > > > > 2)      Have anyone done any benchmarking for performance impact? If
> > yes,
> > > > > can you please share the numbers and also the steps/programs used
> > > > > the run the same.
> > > > >
> > > > > 3)      Help us validating the performance test we have done in our
> > test
> > > > > setup using the steps mentioned along with the results attached.
> > > > >
> > > > >
> > > > >
> > > > > Attached test program (loader.c) to invoke open and close system
> > calls.
> > > > >
> > > > > Attached idskerndsp is the audispd plugin program.
> > > > >
> > > > > We used time command to determine how much time the system took to
> > > > > complete 50000 open/close system calls without (results attached
> > > > > Without-auditing) and with auditing enabled on the system
> > > > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > > > >
> > > > >
> > > > >
> > > > > System details:
> > > > >
> > > > >
> > > > >
> > > > > 1 CPU machine
> > > > >
> > > > >
> > > > >
> > > > > *OS Version*
> > > > >
> > > > > RHEL 6.5
> > > > >
> > > > >
> > > > >
> > > > > *Kernel Version*
> > > > >
> > > > > uname –r
> > > > >
> > > > > 2.6.32-431.el6.x86_64
> > > > >
> > > > >
> > > > >
> > > > > Note: auditd was occupying 35% of CPU and was sleeping for most of
> > > > > the time whereas kauditd was occupying 20% of the CPU.
> > > > >
> > > > >
> > > > >
> > > > > Thanks & Regards,
> > > > >
> > > > > Logeswari.
> > >
> > >
> > >
> > > --
> > > Please Donate to www.wikipedia.org<http://www.wikipedia.org>
> >
> > > --
> > > Linux-audit mailing list
> > > Linux-audit@redhat.com <javascript:;>
> > > https://www.redhat.com/mailman/listinfo/linux-audit
> >
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rbriggs@redhat.com <javascript:;>>
> > Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> > Systems, Red Hat Remote, Ottawa, Canada
> > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
> >
> 
> 
> -- 
> Please Donate to www.wikipedia.org

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox