[PATCH] include/linux/audit.h: Move dummy audit_file() from !AUDIT area to !AUDITSYSCALL area
by Chen Gang
audit_file() is related with AUDITSYSCALL, not related with AUDIT, so
need move dummy one from !AUDIT area to !AUDITSYSCALL area. Or it will
cause issue if CONFIG_AUDIT with !CONFIG_AUDITSYSCALL.
The related error (with allmodconfig under tile):
CC fs/open.o
fs/open.c: In function 'SYSC_fchmod':
fs/open.c:530:3: error: implicit declaration of function 'audit_file' [-Werror=implicit-function-declaration]
audit_file(f.file);
^
Signed-off-by: Chen Gang <gang.chen.5i5j(a)gmail.com>
---
include/linux/audit.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 295ae1c..7b1d0d1 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -363,6 +363,8 @@ static inline void audit_inode(struct filename *name,
const struct dentry *dentry,
unsigned int parent)
{ }
+static inline void audit_file(struct file *file)
+{ }
static inline void audit_inode_parent_hidden(struct filename *name,
const struct dentry *dentry)
{ }
@@ -538,9 +540,6 @@ static inline void audit_log_task_info(struct audit_buffer *ab,
struct task_struct *tsk)
{ }
#define audit_enabled 0
-static inline void audit_file(struct file *file)
-{
-}
#endif /* CONFIG_AUDIT */
static inline void audit_log_string(struct audit_buffer *ab, const char *buf)
{
--
1.9.3
9 years, 12 months
- 3
- 4
Implementing audit rules (/etc/audit/audit.rules) effectively
by Jan Lieskovsky
Hello folks,
within the effort to provide an implementation for some task
implying from my daily job recently I started to face the following
question related with auditd - how to write audit rules in most
effective way. I am mainly interested if there's some comparison / research
wrt to if there's is some performance penalty when (syscall, but
in general case doesn't need to be limited to syscall calls) audit
rules are created in the way having just one syscall rule (one -S argument
is provided per audit rule) versus the case when there are more
(compatible) -S arguments provided simultaneously in the particular
audit.rules row?
To provide an example, let's suppose the *chown category of rules:
* the "all-in-one" case:
-a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
vs
* the "one-rule-per-one-row" case:
-a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
Does the fact how the -S arguments are layered across the /etc/audit/audit.rules
file (IOW if being provided within one row or spread within multiple rows) have
some (negative) impact on the audit system's efficiency? [*] If so, is there some
way how to measure the performance penalty in the second case?
Thank you for your time & possible hints in advance.
Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] Not familiar with audit internals, but translating the request to log / audit
the event of particular system call occurrence from the Linux kernel PoV's
it looks this might correspond to the problem of searching for a key / value
in the hash table (having particular system call occurred, insert new entry
under particular hash table's field taking -k keyname argument as the hash
table key). If this analogy is at least a bit appropriate, the all -S's arguments
case above would correspond to a hash table having just one value for each key,
while separating the desired -S arguments into multiple rows would mean to
have a hash table where one key (-k keyname) would have bucket containing
multiple values (e.g. array of them). In this case to locate the particular
value would mean to locate the bucket in the hash table & then subsequently
yet locate the proper value in that array of items (which seems to be more
time / operation expensive than the case of one rule having multiple -S arguments).
Thus could audit upstream clarify, if there's some performance penalty in
the case of multiple -S being split / spread across multiple rules?
9 years, 12 months
- 2
- 1
peculiar disappearance of most audit rules
by Peter Grandi
Hi, I have started using 'auditd', mostly to monitor various directories
where packages get installed to check for changes in their contents,
with rules like:
-w /bin -p wa -k pkg-s
-w /boot -p wa -k pkg-s
-w /etc -p wa -k pkg-s
-w /lib -p wa -k pkg-s
-w /lib32 -p wa -k pkg-s
-w /lib64 -p wa -k pkg-s
-w /opt -p wa -k pkg-s
-w /usr -p wa -k pkg-s
-w /fs/sozan/loc -p wa -k pkg-l
-w /fs/sozan/loc32-el5 -p wa -k pkg-l
-w /fs/sozan/loc64-u12 -p wa -k pkg-l
-w /fs/sozan/com -p wa -k pkg-l
-w /fs/sozan/com32-el5 -p wa -k pkg-l
-w /fs/sozan/com64-u12 -p wa -k pkg-l
After setting them, I can verify that for example creating, updating and
deleting a file in '/boot' or '/opt' gets reported.
Wheat then happens is that even if I set 'auditctl -e 2' some of the
rules disappear, usually at around the same time as 'cron.daily' scripts
run, and some more disappear later. This usually seems to relate to
times where there some significant IO activity ('mlocate' scan, backup),
but this is a guess.
For example:
time->Thu Apr 17 07:58:44 2014
type=CONFIG_CHANGE msg=audit(1397717924.255:37148): op="remove rule" dir="/boot" key="pkg-s" list=4 res=1
time->Thu Apr 17 07:59:04 2014
type=CONFIG_CHANGE msg=audit(1397717944.762:37151): op="remove rule" dir="/opt" key="pkg-s" list=4 res=1
time->Thu Apr 17 10:01:02 2014
type=CONFIG_CHANGE msg=audit(1397725262.301:37157): op="remove rule" dir="/fs/sozan/loc64-u12" key="pkg-l" list=4 res=1
time->Thu Apr 17 10:01:02 2014
type=CONFIG_CHANGE msg=audit(1397725262.301:37156): op="remove rule" dir="/fs/sozan/loc32-el5" key="pkg-l" list=4 res=1
There is no equivalent line in 'dmesg'.
I understand that the 'audit' kernel modules may remove rules if they
refer to invalid paths, but all the relevant directories do exist, as
for example '/boot' and '/opt' are the standard usual directories in the
"root" tree itself:
$ ls -ldn /boot /opt /fs/sozan/loc64-u12 /fs/sozan/loc32-el5
drwxr-xr-x 3 0 0 4096 Apr 21 07:22 /boot
drwxrwsr-x 7 1 1 61 Jul 30 2011 /fs/sozan/loc32-el5
drwxrwsr-x 5 1 1 39 Oct 4 2011 /fs/sozan/loc64-u12
drwxr-xr-x 7 0 0 4096 Apr 20 14:52 /opt
$ df /boot/. /opt/. /fs/sozan/loc64-u12/. /fs/sozan/loc32-el5/.
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/sda3 24815 16853 4106 81% /
/dev/sda3 24815 16853 4106 81% /
/dev/sda6 90048 82355 7694 92% /fs/sozan
/dev/sda6 90048 82355 7694 92% /fs/sozan
This is happening on two similarly configured Ubuntu 12.04 systems with
both 3.2 and 3.11 Ubuntu "official" kernels. I also have an AppArmor
configuration which seem to trigger bugs in AppArmor, but all the
relative profiles are essentially unchanged.
Eventually around almost all of the rules I have set "disappear". For
example of all these rules:
LIST_RULES: exit,always dir=/fs/sozan/search (0x10) perm=r key=pkg-r
LIST_RULES: exit,always dir=/fs/sozan/mlocate (0x11) perm=r key=pkg-r
....
LIST_RULES: exit,always dir=/bin (0x4) perm=wa key=pkg-s
LIST_RULES: exit,always dir=/boot (0x5) perm=wa key=pkg-s
LIST_RULES: exit,always dir=/etc (0x4) perm=wa key=pkg-s
LIST_RULES: exit,always dir=/lib (0x4) perm=wa key=pkg-s
LIST_RULES: exit,always dir=/lib32 (0x6) perm=wa key=pkg-s
LIST_RULES: exit,always dir=/lib64 (0x6) perm=wa key=pkg-s
LIST_RULES: exit,always dir=/opt (0x4) perm=wa key=pkg-s
LIST_RULES: exit,always dir=/usr (0x4) perm=wa key=pkg-s
LIST_RULES: exit,always dir=/fs/sozan/loc (0xd) perm=wa key=pkg-l
LIST_RULES: exit,always dir=/fs/sozan/loc32-el5 (0x13) perm=wa key=pkg-l
LIST_RULES: exit,always dir=/fs/sozan/loc64-u12 (0x13) perm=wa key=pkg-l
LIST_RULES: exit,always dir=/fs/sozan/com (0xd) perm=wa key=pkg-l
LIST_RULES: exit,always dir=/fs/sozan/com32-el5 (0x13) perm=wa key=pkg-l
LIST_RULES: exit,always dir=/fs/sozan/com64-u12 (0x13) perm=wa key=pkg-l
Only the first two have not "disappeared" on one of the systems.
This is rather peculiar, please let me know if it is a configuration
error, an issue, and any fixes or workaround if available (other than
running 'auditctl -R /etc/audit/audit.rules' every few minutes via CRON).
9 years, 12 months
- 5
- 10