lib/audit.c (kernel)
Hi
I'm working on audit/seccomp support for AArch64 as you see in
[0/4] arm64: Add audit support
https://www.redhat.com/archives/linux-audit/2013-November/msg00040.html
ARM sub-system maintainer asked me whether it would be possible
to re-work lib/audit.c to work with "compat" syscalls.
My question is, "Is this reasonable to think about?"
(I know all the existing architectures already have their own
implementations.)
I'd like to get any comments before going further.
One of possible solutions is
* Add lib/compat_audit.c, where
#include "asm/unistd32.h" <= it seems somewhat arch-specific.
static unsigned dir_class[] = {
...
int audit_classify_compat_syscall() {
...
static int __init audit_compat_classes_init() {
...
__initcall(audit_compat_classes_init);
* In lib/audit.c,
#include
#include
...
int audit_classify_arch(arch) {
#ifdef CONFIG_COMPAT
if (audit_is_compat(arch))
return 1;
#endif
return 0;
}
int audit_classify_syscall(abi, syscall) {
#ifdef CONFIG_COMPAT
if (audit_is_compat(arch))
return audit_classify_compat_syscall(abi, syscall);
#endif
...
}
* In arch/*/include/asm/audit.h,
#inlcude
...
#define audit_is_compat(arch) \
((arch == AUDIT_ARCH_x) || (arch == AUDIT_ARCH_y))
-Takahiro AKASHI
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
missing system call defs in audit(userspace)
Hi Steve As I mentioned in my patch, [0/4] arm64: Add audit support there are missing system call definitions in lib/aarch64_table.h. All those syscalls have the same attribute, __NR3264_*. It seems intentional, right? -Takahiro AKASHI -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
[PATCH 1/1] Added exe field to audit core dump signal log
Currently when the coredump signals are logged by the audit system , the
actual path to the executable is not logged. Without details of exe , the
system admin may not have an exact idea on what program failed.
This patch changes the audit_log_task() so that the path to the exe is also
logged.
Signed-off-by: Paul Davies C
---
kernel/auditsc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 9845cb3..988de72 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2353,6 +2353,7 @@ static void audit_log_task(struct audit_buffer *ab)
kuid_t auid, uid;
kgid_t gid;
unsigned int sessionid;
+ struct mm_struct *mm = current->mm;
auid = audit_get_loginuid(current);
sessionid = audit_get_sessionid(current);
@@ -2366,6 +2367,12 @@ static void audit_log_task(struct audit_buffer *ab)
audit_log_task_context(ab);
audit_log_format(ab, " pid=%d comm=", current->pid);
audit_log_untrustedstring(ab, current->comm);
+ if (mm) {
+ down_read(&mm->mmap_sem);
+ if (mm->exe_file)
+ audit_log_d_path(ab, " exe=", &mm->exe_file->f_path);
+ up_read(&mm->mmap_sem);
+ }
}
static void audit_log_abend(struct audit_buffer *ab, char *reason, long signr)
--
1.7.9.5
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
Re: order of entries output from ausearch -i
On Wednesday, November 13, 2013 05:14:13 PM AKASHI Takahiro wrote: > Hi Steve > > I followed your advise and verified my patch of AArch64 audit support > by comparing the output from > # autrace /bin/ls > # ausearch -i -p XXX | grep SYSCALL > with the output from > # strace /bin/ls > > Here I found that the entries shown by "ausearch -i" are listed > partially in the order of lifo (Last In First Out?). > I don't think this behavior is "intuitive". > (As you know, ausearch without -i generates fifo order of outputs.) > Is there any good reason? Yes, the syscall record is often the most important. Its better to scroll the auxiliary records off the screen leaving just the syscall record. For example, if you triggered a syscall event against kill(-1, SIGTERM) you could have a 100 or more OBJ_PID records with that syscall. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: logging changes in tty logging status
On Wednesday, November 13, 2013 03:04:18 PM Richard Guy Briggs wrote: > Hi Steve, > > I'm reviewing audit_receive_msg() and noticing that the AUDIT_TTY_SET > case doesn't log a configuration change. Should it? Yes, it should. Any change in config should be recorded with subject, old value, new value, and results. It should match other config change events. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
logging changes in tty logging status
Hi Steve, I'm reviewing audit_receive_msg() and noticing that the AUDIT_TTY_SET case doesn't log a configuration change. Should it? - RGB -- Richard Guy Briggs 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
order of entries output from ausearch -i
Hi Steve I followed your advise and verified my patch of AArch64 audit support by comparing the output from # autrace /bin/ls # ausearch -i -p XXX | grep SYSCALL with the output from # strace /bin/ls Here I found that the entries shown by "ausearch -i" are listed partially in the order of lifo (Last In First Out?). I don't think this behavior is "intuitive". (As you know, ausearch without -i generates fifo order of outputs.) Is there any good reason? Thanks, -Takahiro AKASHI -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
