August 2007 - Linux-audit - Linux-Audit List Archives

by Henning, Arthur C. (CSL)

RHEL 5 Have two events having difficulty capturing or reviewing with the audit sub-system. 1. su - "non_existent_account". Using the nispom.rules provided by audit 1.5.6-1. Using various ausearch parameters, am unable to find a corresponding failure when attempting to "su" to a non-existent account. 2. Non-privileged user attempting to change the date/time on the server. Of course the user fails to be able to do so, but am unable to capture or review the event. Not sure if these are audit rule configuration or search unknowns or audit sub-system limitations. Thank you Art Henning (CSL) Enterprise IT Solutions Northrop Grumman Corporation art.henning(a)ngc.com

17 years, 11 months

2
3
0 / 0

Dictionary of audit records

by John Dennis

Is there a dictionary of audit records which lists every audit record and every field in that record as well as how to interpret that field? Does the audit data follow any type of regular schema and is that regularity enforced in any manner? -- John Dennis <jdennis(a)redhat.com>

17 years, 12 months

2
1
0 / 0

init and its direct children not audited?

by Matthew Booth

I have the following in my test audit configuration on RHEL4 U5: -a entry,always -S exit -S exit_group -S execve -S fork -S vfork -S clone My first observation is that I've never seen an audit record with pid=1. It's fairly easy to reproduce this one. Log in at the console, then log out. You'll see a process execve() a new mingetty, but you won't see the fork, vfork or clone which created it. My second observation is a bit more complex. I have a box running Oracle RAC. RAC runs some particularly nasty scripts on a regular basis (once per second). In outline, it does this: In inittab: respawn:init.cssd In init.cssd: while true; do init.cssd runcheck done I see that a process execs 'init.cssd runcheck' once per second. However, I do not see a process fork, vfork or clone that process. This suggests that audit data isn't being produced for the top level init.cssd job. Does this ring any bells? Is there some other method of process creation I'm not aware of? Is init intentionally not audited, and if so, how do I audit it? Thanks, Matt -- Matthew Booth, RHCA, RHCSS Red Hat, Global Professional Services M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

17 years, 12 months

2
1
0 / 0

[PATCH] Renumber AUDIT_TTY_[GS]ET

by Miloslav Trmac

Renumber AUDIT_TTY_[GS]ET to avoid a conflict with netlink message types already used in the wild.

17 years, 12 months

1
0
0 / 0

Audit with path exception rule

by Ameel Kamboh

I would like to audit the file system for anyone creating new files However I would like to exclude a directory from the watch list. Here is the sample I have: #3. create/Remove any files -a exit,always -S creat -F path!=/var/myApp <--- line 21 -a exit,always -S unlink -F path!=/var/myApp This is giving me the following error: auditctl -R test.rules No rules AUDIT_STATUS: enabled=1 flag=1 pid=3413 rate_limit=0 backlog_limit=1024 lost=0 backlog=0 Error sending add rule data request (Invalid argument) There was an error in line 21 of test.rules Ameel Kamboh SIP Core Network and Security Phone: 972.685.4922 (esn 445-4922) Mobile: 978-590-2280 SIP: akamboh(a)techtrial.com email: akamboh(a)nortel.com

17 years, 12 months

3
2
0 / 0

certification test suite

by Linda Knippers

HP has posted the test suite we used for the audit and MLS portions of our recent RHEL5 CAPP/LSPP/RBACPP certification. http://sourceforge.net/projects/audit-test/ We used this suite in combination with the LTP and a handful of manual tests to provide the necessary test coverage for our evaluation. Although this suite is called 'audit-test' and includes coverage of all the security relevant system calls, it also includes tests for other components such as NetLabel/CIPSO, IPsec, and CUPS. The suite is available as a tarball, a source rpm, and as a noarch rpm which will install files into /usr/local/eal4_testing/audit-test. There are 3 README files which describe how to run the tests, how to develop tests, and how to configure the test server for network tests. These tests are known to pass on RHEL5 plus the updated packages listed in our security target in both CAPP mode (optional targeted policy) and LSPP mode (mls policy) on i386, x86_64 and ia64 architectures. The tests are known to run on the RHEL5.1 beta with about 17 failures due to changes in some of the pam audit records. Items on our TODO list include updating the suite to support multiple versions of some of the interesting packages (such as audit and pam), providing more intuitive subsets of the test cases for specific components, and separating the test harness into its own package. We would appreciate feedback as well as patches through the sourceforge project trackers if you use and update the suite. We are especially interested in hearing from people running the tests on other distros, with or without SELinux. Thanks, -- ljk

18 years

3
2
0 / 0

Assorted questions

by Matthew Booth

Questions relate to RHEL4 (unless they don't). What are the meanings of the following fields from the SYSCALL record: * items * fsuid * fsgid What are the meanings of the following fields from the PATH record: * flags * rdev How can I programmatically translate an architecture into human, eg 40000003 => 'i686'? Is there a way of doing a syscall name lookup without having root? In RHEL5, what's the equivalent of 'auditctl -t'? Is there any master documentation I've missed? I'm only aware of the man pages. Thanks, Matt -- Matthew Booth, RHCA, RHCSS Red Hat, Global Professional Services M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

18 years

3
2
0 / 0

High-level audit parser module

by John D. Ramsdell

John, I'm working on a high-level audit reading Python library built on top of the auparse module. I suspect it could be made to be useful to others besides myself. I have enclosed the generated documentation for the relevant classes in my module. If you think it could be generally useful, the key question is what methods should be defined in the AuditEvent and AuditRecord classes. Some of the current ones are too specific to my needs. CLASSES class AuditEvent(__builtin__.list) | AuditEvent(AuEvent) | | An audit event is represented as a list of AuditRecord's. Each | AuditRecord is a dictionary that represents one of the records | that make up the event. | | Method resolution order: | AuditEvent | __builtin__.list | __builtin__.object | | Methods defined here: | | __init__(self, timestamp) | | find_record_of_type(self, typ) | Find record of type | | Returns a record in the event that has the given type. | Returns None when there is no such record. | | find_value(self, name) | Find a value | | Returns a value associated with the given name in some record | in the event. Raises KeyError if no field has the given name. | | get_timestamp(self) | Get the timestamp associated with this event. | | path_name(self, item) | Find name and security context in PATH record | | Return the name and the security context in a PATH record that | matches the given item number. Raises KeyError if PATH record | cannot be found. | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) | | ---------------------------------------------------------------------- | Methods inherited from __builtin__.list: !!! inherited methods omitted !!! class AuditLog(__builtin__.object) | AuditLog(AuParser or file, bool) | | Encapsulates a log accessed by the auparse module. It provides an | interator to the log's events. Each call to the next method of | the interator returns an AuditEvent. The boolean determines if | numeric entities in fields are interpreted. | | Methods defined here: | | __init__(self, au, interpret=False) | | __iter__(self) | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) class AuditLogIter(__builtin__.object) | AuditLogIter(AuditLog) | | An iterator for an audit log. | | Methods defined here: | | __init__(self, aulog) | | next(self) | Returns an AuditEvent | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) class AuditRecord(__builtin__.dict) | AuditRecord(AuditEvent) | | An audit record is a dictionary. | | Method resolution order: | AuditRecord | __builtin__.dict | __builtin__.object | | Methods defined here: | | __init__(self, event) | | get_event(self) | Get the event associated with this record. | | path_name_record(self, item) | Find name and security context in PATH record | | Return the name and the security context in a PATH record that | matches the given item number. Raises KeyError if PATH record | cannot be found. | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) | | ---------------------------------------------------------------------- | Methods inherited from __builtin__.dict: !!! inherited methods omitted !!!

18 years

1
1
0 / 0

Fwd: Re: Upstreaming shared LSM interfaces

by Casey Schaufler

--- Casey Schaufler <casey(a)schaufler-ca.com> wrote: > Date: Thu, 9 Aug 2007 11:43:53 -0700 (PDT) > From: Casey Schaufler <casey(a)schaufler-ca.com> > Subject: Re: Upstreaming shared LSM interfaces > To: "David P. Quigley" <dpquigl(a)tycho.nsa.gov>, > Stephen Smalley <sds(a)tycho.nsa.gov>, James Morris > <jmorris(a)namei.org>, > David Howells <dhowells(a)redhat.com>, > Casey Schaufler <casey(a)schaufler-ca.com> > > > --- "David P. Quigley" <dpquigl(a)tycho.nsa.gov> wrote: > > > Hello Everyone, > > Between Casey's Audit patches, the FS-Cache patches and the Labeled NFS > > patches there are a bunch of new LSM interfaces being proposed that some > > combination of us seem to need. I would like to propose that we agree on > > the interfaces and send them to James to be upstreamed. The interfaces > > and the proposed prototypes are listed below > > I was wrong to propose the hooks that get the secids to feed to > the audit system. I had hoped that I could contain the scope of > the changes required to the audit system to pull SELinux dependencies > out by allowing the continued use of secids in that case. I see > now the error in my ways and will shortly proposed an alternative > patch set for the deselinixifation of audit. > > The secid is an internal SELinux data structure (albeit one with > many favorable characteristics) and the LSM interface ought not > be exposing it. > > > Interfaces: > > > > inode_{get,set}secid: From Labeled NFS patches > > void (*inode_getsecid)(struct inode *inode, u32 *secid); > > void (*inode_setsecid)(struct inode *inode, u32 secid); > > > > > > ipc_getsecid: From Audit patches > > void (*ipc_getsecid) (struct kern_ipc_perm *p, u32 *secid); > > > > {get,set}_fscreate_secid: From FS-Cache patches > > u32 (*get_fscreate_secid)(void); > > u32 (*set_fscreate_secid)(u32 secid); > > > > > > secctx_to_secid: From Labeled NFS patches > > int (*secctx_to_secid)(u32 *secid, char *secdata, u32 seclen); > > > > act_as_{secid,self}: From FS-Cache patches > > u32 (*act_as_secid)(u32 secid); > > u32 (*act_as_self)(void); > > > > > > Dave Quigley > > > > > > > > > Casey Schaufler > casey(a)schaufler-ca.com > > > Casey Schaufler casey(a)schaufler-ca.com

18 years

1
0
0 / 0

autrace

by John D. Ramsdell

I've been successfully using the audit package to trace programs that fork by using the ptrace system call to add audit rules. As a result of tracing ever more programs, I notice I have added three features to my program that may be of use in the autrace program. To trace a program that behaves like a server, I exercise the server, and then send it a keyboard interrupt. If nothing special is done, the tracing process terminates, but not the traced processes. To handle this situation, I make the first child a process group leader with: if (setpgid(0, 0)) { /* Make child a process group leader */ perror("setpgid of child"); /* so that signals can be sent to */ return -1; /* the group */ } The tracing process stores the pid of the first child in the group variable, and then registers the following handler with SIGINT: static void signal_group(int signum) { if (group && kill(-group, signum)) perror("kill group"); if (signal(signum, SIG_DFL) == SIG_ERR) fprintf(stderr, "Setting signal %d to its default failed\n", signum); } The group variable is set to zero whenever it is known no child is running, such as when rules are being deleted. For some of the programs I trace, it is important they not be run as root. I have a -u username option, and before the first child executes the traced program, I use the following code to make use of the option's value. static int set_id(const char *username) /* Sets the group and user ID */ { /* when given a user name. */ struct passwd *pent; /* Setuid and setgid bits are */ if (!username) /* ignored on the executable file */ return 0; /* containing the program being */ else if ((pent = getpwnam(username)) == NULL) { /* traced. */ fprintf(stderr, "Cannot find user `%s'\n", username); return -1; } else if (setregid(pent->pw_gid, pent->pw_gid)) { perror("setregid"); return -1; } else if (setreuid(pent->pw_uid, pent->pw_uid)) { perror("setreuid"); return -1; } else return 0; } Finally, when printing the command to retrieve the records associated with the trace for process P, I would print ausearch -i -p P > P.txt rather than 'ausearch -i -p P' I almost always want to place the output into a file, and when I don't, it's easy to copy only part of the command. Also, the single quotes force one to be more precise with the mouse than I like to be when cutting and pasting within a terminal window. If any or all of these suggestions seem useful, I am willing to implement them in the autrace source file and send patches. On the other hand, I tried to put enough detail into this message so you can easily make the changes. John

18 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Linux-audit August 2007