February 2013 - Linux-audit - Linux-Audit List Archives

[PATCH] Support for auditing on the actions of a not-yet-executed process.

by Peter Moody

eg: -a exit,always -F arch=b64 -S socket -F 'a0!=1' -F exe=/bin/bash -F success=1 to see instances of /bin/bash opening a non-local socket. Or -a exit,always -F arch=b64 -S socket -F 'a0!=1' -F exe_children=/bin/bash -F success=1 to instances of /bin/bash, and any descendant processes, opening a non local socket. proposed https://www.redhat.com/archives/linux-audit/2012-June/msg00002.html and it seemed like there was interest. Signed-off-by: Peter Moody <pmoody(a)google.com> --- trunk/lib/errormsg.h | 2 +- trunk/lib/fieldtab.h | 2 ++ trunk/lib/libaudit.c | 11 +++++++++++ trunk/lib/libaudit.h | 7 ++++++- 4 files changed, 20 insertions(+), 2 deletions(-) diff --git a/trunk/lib/errormsg.h b/trunk/lib/errormsg.h index 4d996d5..cd595ec 100644 --- a/trunk/lib/errormsg.h +++ b/trunk/lib/errormsg.h @@ -51,7 +51,7 @@ static const struct msg_tab err_msgtab[] = { { -15, 2, "-F unknown errno -"}, { -16, 2, "-F unknown file type - " }, { -17, 1, "can only be used with exit and entry filter list" }, - { -18, 1, "" }, // Unused + { -18, 1, "only takes = operator" }, { -19, 0, "Key field needs a watch or syscall given prior to it" }, { -20, 2, "-F missing value after operation for" }, { -21, 2, "-F value should be number for" }, diff --git a/trunk/lib/fieldtab.h b/trunk/lib/fieldtab.h index c0432cc..245b541 100644 --- a/trunk/lib/fieldtab.h +++ b/trunk/lib/fieldtab.h @@ -66,3 +66,5 @@ _S(AUDIT_ARG3, "a3" ) _S(AUDIT_FILTERKEY, "key" ) _S(AUDIT_FIELD_COMPARE, "field_compare" ) +_S(AUDIT_EXE, "exe" ) +_S(AUDIT_EXE_CHILDREN, "exe_children" ) diff --git a/trunk/lib/libaudit.c b/trunk/lib/libaudit.c index 20eaf5f..06eed86 100644 --- a/trunk/lib/libaudit.c +++ b/trunk/lib/libaudit.c @@ -1400,6 +1400,17 @@ int audit_rule_fieldpair_data(struct audit_rule_data **rulep, const char *pair, else return -21; break; + case AUDIT_EXE_CHILDREN: + case AUDIT_EXE: + { + struct stat buf; + if ((stat(v, &buf)) < 0) + return -2; + if (op != AUDIT_EQUAL) + return -18; + rule->values[rule->field_count] = (unsigned long)buf.st_ino; + } + break; case AUDIT_DEVMAJOR...AUDIT_INODE: case AUDIT_SUCCESS: if (flags != AUDIT_FILTER_EXIT) diff --git a/trunk/lib/libaudit.h b/trunk/lib/libaudit.h index 89dd588..2c8a802 100644 --- a/trunk/lib/libaudit.h +++ b/trunk/lib/libaudit.h @@ -243,6 +243,12 @@ extern "C" { #ifndef AUDIT_FIELD_COMPARE #define AUDIT_FIELD_COMPARE 111 #endif +#ifndef AUDIT_EXE +#define AUDIT_EXE 112 +#endif +#ifndef AUDIT_EXE_CHILDREN +#define AUDIT_EXE_CHILDREN 113 +#endif #ifndef AUDIT_COMPARE_UID_TO_OBJ_UID #define AUDIT_COMPARE_UID_TO_OBJ_UID 1 @@ -524,4 +530,3 @@ extern void audit_rule_free_data(struct audit_rule_data *rule); #endif #endif - -- 1.7.7.3

10 years, 7 months

3
3
0 / 0

[PATCH] audit: audit on the future execution of a binary.

by Peter Moody

This adds the ability audit the actions of a not-yet-running process, as well as the children of a not-yet-running process. Signed-off-by: Peter Moody <pmoody(a)google.com> --- include/linux/audit.h | 2 ++ kernel/auditfilter.c | 6 ++++++ kernel/auditsc.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 55 insertions(+), 0 deletions(-) diff --git a/include/linux/audit.h b/include/linux/audit.h index 22f292a..5506cb1 100644 --- a/include/linux/audit.h +++ b/include/linux/audit.h @@ -260,6 +260,8 @@ #define AUDIT_OBJ_UID 109 #define AUDIT_OBJ_GID 110 #define AUDIT_FIELD_COMPARE 111 +#define AUDIT_EXE 112 +#define AUDIT_EXE_CHILDREN 113 #define AUDIT_ARG0 200 #define AUDIT_ARG1 (AUDIT_ARG0+1) diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c index a6c3f1a..1e6c571 100644 --- a/kernel/auditfilter.c +++ b/kernel/auditfilter.c @@ -546,6 +546,12 @@ static struct audit_entry *audit_data_to_entry(struct audit_rule_data *data, if (f->val > AUDIT_MAX_FIELD_COMPARE) goto exit_free; break; + case AUDIT_EXE: + case AUDIT_EXE_CHILDREN: + if (f->op != Audit_equal) { + goto exit_free; + } + break; default: goto exit_free; } diff --git a/kernel/auditsc.c b/kernel/auditsc.c index 4b96415..9cebe95 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -46,6 +46,7 @@ #include <asm/types.h> #include <linux/atomic.h> #include <linux/fs.h> +#include <linux/dcache.h> #include <linux/namei.h> #include <linux/mm.h> #include <linux/export.h> @@ -68,6 +69,7 @@ #include <linux/capability.h> #include <linux/fs_struct.h> #include <linux/compat.h> +#include <linux/sched.h> #include "audit.h" @@ -592,6 +594,35 @@ static int audit_field_compare(struct task_struct *tsk, return 0; } +int audit_match_exe(struct task_struct *tsk, struct audit_field *f) +{ + int result = 0; + struct mm_struct *mm; + struct vm_area_struct *vma; + + if (!tsk) + goto out; + + mm = tsk->mm; + if (!mm) + goto out; + + down_read(&mm->mmap_sem); + vma = mm->mmap; + while (vma) { + if ((vma->vm_flags & VM_EXECUTABLE) && + vma->vm_file) { + struct inode *ino = vma->vm_file->f_path.dentry->d_inode; + result = audit_comparator(ino->i_ino, f->op, f->val); + break; + } + vma = vma->vm_next; + } + up_read(&mm->mmap_sem); +out: + return result; +} + /* Determine if any context name data matches a rule's watch data */ /* Compare a task_struct with an audit_rule. Return 1 on match, 0 * otherwise. @@ -629,6 +660,22 @@ static int audit_filter_rules(struct task_struct *tsk, result = audit_comparator(ctx->ppid, f->op, f->val); } break; + case AUDIT_EXE: + result = audit_match_exe(tsk, f); + break; + case AUDIT_EXE_CHILDREN: + { + struct task_struct *ptsk; + for (ptsk = tsk; + ptsk->parent->pid > 0; + ptsk = find_task_by_vpid(ptsk->parent->pid)) { + if (audit_match_exe(ptsk, f)) { + ++result; + break; + } + } + } + break; case AUDIT_UID: result = audit_comparator(cred->uid, f->op, f->val); break; -- 1.7.7.3

11 years, 3 months

4
9
0 / 0

user message limits

by LC Bruzenak

I know I can go look at the code, however I figured I'd ask here first about the limits on the user message in both audit_log_user_message and ausearch. With audit_log_user_message the maximum length allowed appears to be around MAX_AUDIT_MESSAGE_LENGTH-100. I think it may depend on the executable name length (and other stuff auto-pushed into the string) which is why I say "around". Even when I get a successful return value (from audit_log_user_message), I don't get my string back out in "ausearch" unless it is WAY smaller - ~1K or less I think. Any ideas/thoughts? This is the latest (1.7.11-2) audit package. Thx, LCB. -- LC (Lenny) Bruzenak lenny(a)magitekltd.com

11 years, 3 months

5
17
0 / 0

Audit Viewer no horizontal scroll bar

by Brown, Curtis (cbrown31)

I'm running on Centos 6.3 with gtk2-2.18.9-10.el6 and audit-viewer 0.7.4. I have no horizontal scroll bar even though there is data.

11 years, 10 months

1
0
0 / 0

User msg in Audit Viewer

by Brown, Curtis (cbrown31)

I don't know if this the correct forum for questions about the Audit Viewer but here goes. I wrote a test app to write an audit user message (audit_log_user_message). This is successful. I'm trying to display the msg="" portion of the audit record in Audit Viewer without success. The msg portion doesn't show up in the "Other Fields" displayed by Audit Viewer but is present in the actual audit record. Any help would be appreciated or please point me to a forum that can answer my question.

11 years, 10 months

2
2
0 / 0

[RFC]: extend iptables' AUDIT target functionality

by Mr Dash Four

As it stands currently, when a NETFILTER_PKT type message is logged by the audit daemon for ICMP type 3 messages (destination unreachable), I get absolutely no information in that log as to who/what caused that to be triggered by the kernel, apart from, may be, the SELinux context. I get something like: type=NETFILTER_PKT msg=audit(16/02/2013 07:10:28.004:7802) : action=0 hook=3 len=80 inif=? outif=eth4 saddr=10.2.7.2 daddr=10.3.0.6 ipid=21794 proto=icmp icmptype=destination-unreachable icmpcode=1 obj=system_u:object_r:web_client_pkt_t:s0 I have managed to successfully change the AUDIT iptables target to include additional information from the original connection which caused this ICMP type message to be emitted, though before committing and issuing the relevant patches, I thought to seek more broad consensus as to what I should include as additional information in that audit log. When ICMP type 3 message is triggered (that is also valid for type 4 - "source quench", and type 11 - "time exceeded" ICMP messages), and also depending on the type of the original connection, the following information is available to the modified AUDIT iptables target and could be transferred in the audit log for that (original) connection: IP-related properties: ~~~~~~~ 1. Source IP address; 2. Destination IP address; 3. Protocol used; 4. Type of service (TOS) value of the original packet; 5. Time-to-live (TTL) value of the original packet; 6. Checksum; 7. Total length of the original packet; TCP-related (valid only when the original connection was TCP): ~~~~~~~~~ 1. Source port; 2. Destination port; 3. TCP flags of the original packet; 4. TCP sequence value of the original packet; 5. Acknowledgement sequence number of the original packet; 6. Checksum; 7. Window size value; UDP-related (valid only when the original connection was UDP): ~~~~~~~~~ 1. Source port; 2. Destination port; 3. Packet length (header + payload) of the original packet; 4. Checksum; SCTP-related (valid only when the original connection was SCTP): ~~~~~~~~~~ 1. Source port; 2. Destination port; 3. Checksum; Please note that this is *all* the data available to the AUDIT target, not what is (or should be) included in the audit logs! As it stands, I have currently included the following in the AUDIT target to be logged, though this is not final, as I am still seeking more broad consensus, hence this email: IP-related properties: Source & destination IP addresses, protocol and total length of the original packet; TCP-related: Source & destination ports, TCP flags; UDP-related: Source & destination ports; SCTP-related: Source & destination ports; As already mentioned, there are at least two things I am still considering: 1) should I add/exclude some of what I just listed above?; and 2) what should be the structure of the audit message? For the latter, I have currently placed everything in a single audit message: the properties of the ICMP audit message (as shown in the example above), plus the field name/value pairs of the original connection added after that. They are currently named as "oX=V", where "X" is the brief description of the property in question and "V" is its value (in other words, TCP source port with a value of 443 of the original connection is constructed as "osport=443" in the final audit message). I would like to know whether there are any objections, new ideas or suggestions to the above before committing this and issuing the relevant patches. Thanks!

11 years, 10 months

1
0
0 / 0

Embedded libev library

by Laurent Bigonville

Hello, I've a question about the embedded version of libev. Is there any particular reason you are shipping it? Or is it only for convenience? The Debian archive is containing already containing libev (4.11) and it's usually considered bad practice to embed libraries that are already contained in the archive. Would you accept a patch to allow building audit against the system libev library? Cheers Laurent Bigonville

11 years, 10 months

3
2
0 / 0

[PATCH 0/3] Fix userspace audit compiler warnings

by Tyler Hicks

These patches fix the majority of compiler warnings seen when building audit on Ubuntu. The audit codebase rarely checked the return value of asprintf(), which can cause problems if memory allocation fails. Most of the missing checks are in libauparse, which is probably fine but who knows what will use it in the future. Also, all of these warnings clutter up the build output and make it more difficult to see more serious warnings. The second patch contains some other ignored return value warnings fixes, as well. These show up on Ubuntu when the -D_FORTIFY_SOURCE=2 and -Wunused-return flags are in use. They don't seem to show up on Fedora in the same situation, but I believe that they should, despite casting the function's return value to (void). Despite that, they looked to be areas in the code that should at least log a message or even prevent auditd from running in some situations. The last patch cleans up two const warnings. There are still a number of warnings in the zos-remote audispd plugin that I didn't get to and a few that look ok to me in the embedded libev code. Tyler

11 years, 10 months

2
7
0 / 0

[PATCH] Fix a typo in aureport.8

by Oren Held

=================================================================== --- aureport.8 (revision 740) +++ aureport.8 (working copy) @@ -40,7 +40,7 @@ Interpret numeric entities into text. For example, uid is converted to account name. The conversion is done using the current resources of the machine where the search is being run. If you have renamed the accounts, or don't have the same accounts on your machine, you could get misleading results. .TP .BR \-if ,\ \-\-input \ \fIfile\fP -Use the given \fIfile\fP instead if the logs. This is to aid analysis where the logs have been moved to another machine or only part of a log was saved. +Use the given \fIfile\fP instead of the logs. This is to aid analysis where the logs have been moved to another machine or only part of a log was saved. .TP .B \-\-input\-logs Use the log file location from auditd.conf as input for analysis. This is needed if you are using aureport from a cron job.

11 years, 10 months

2
1
0 / 0

[PATCH 0/3] Several manpages fixes

by Laurent Bigonville

From: Laurent Bigonville <bigon(a)bigon.be> Hi, Please find here some patches for the audit manpages. Cheers, Laurent Bigonville

11 years, 10 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Linux-audit February 2013