audit-0.6.2 released
by Steve Grubb
Hi,
A new version of auditd has been released. You can download it from:
http://people.redhat.com/sgrubb/audit
Some of the changes:
- Add R option to auditctl to allow reading rules from file.
- Do not allow task creation list to have syscall auditing
- Add D option to allow deleting all rules with 1 command
- Added pam_audit man page & sample.rules
- Mod initscript to call auditctl to load rules at start-up
- Write message to log file for daemon start up
- Write message that daemon is shutting down
- Modify auditd shutdown to wait until logger thread is finished
- Fix bug where extra info was appended to some messages
This version now supports reading a set of rules when the daemon is started.
Edit the file: /etc/audit.rules and place the audit ctl commands. There is a
sample audit rules file included. Look for sample.rules.
Compiled versions will be available in rawhide tomorrow morning.
-Steve Grubb
20 years, 11 months
[PATCH] fix ia64 syscall auditing
by Amy Griffis
Hello,
Attached is a patch against David's audit.17 kernel that adds checks
for the TIF_SYSCALL_AUDIT thread flag to the ia64 system call and
signal handling code paths. The patch enables auditing of system
calls set up via fsys_bubble_down, as well as ensuring that
audit_syscall_exit() is called on return from sigreturn.
Neglecting to check for TIF_SYSCALL_AUDIT at these points results in
incorrect information in audit_context, causing frequent system panics
when system call auditing is enabled on an ia64 system.
I have tested this patch and have seen no problems with it.
Thanks,
Amy
21 years
[RFC][PATCH 0/3] CAPP-compliant file system auditing
by Timothy R. Chavez
Hello,
.:: Introduction ::.
In its present state, the Linux audit subsystem cannot be used in a Common
Criteria (ISO/IEC 15408)[1] CAPP/EAL4+[2] evaluation. This patch addresses a
blocking deficiency in the current implementation regarding the inability to
audit file system objects by "name". Currently, one is limited to using a
(inode,device) filter rule to audit syscall access to the object. This is
insufficient for CAPP because (1) the object is not being audited by "name"
nor (2) will it remain auditable if the underlying inode changes. What
follows from this requirement is the ability to better observe the _behavior_
of the "named" object, rather then just access to the "named" object.
Here is a relevant example show casing the deficiency:
The administrator audits "/etc/shadow". To do so, she adds the filter rule
using /etc/shadow's current inode and device. Then, she runs 'passwd' to
change her password. She consults the audit log and sees that some records
have been generated, but when she runs 'passwd' again, she notices that no
longer are audit records being generated. She does an 'ls -i /etc/shadow'
and notices that the inode has changed. She then decides to consult the
audit log and comes to the realization that what's there is incomplete and
does not tell the complete story of /etc/shadow during the execuation of
'passwd'.
The patch is broken into two parts.
Part 1: The actual implementation of the file system auditing piece
Part 2: The hooks
+ + + +
[1] Common Criteria is an internationally recognized ISO centered around IT
security evaluations (http://csrc.nist.gov/cc/)
[2] CAPP/EAL4 (Controlled Access Protection Profile)/Evaluation Assurance
Level 4+ is for generalized environments with a moderate level of risk to the
assets. For more information about CAPP requirements:
http://www.commoncriteriaportal.org/public/files/ppfiles/capp.pdf)
-tim
21 years
Getting the program name in audit messages
by Steve Grubb
Hello,
This topic has already been discussed on the SE Linux mail list. Because the
attached patch affects the audit code, I want to put it out here for
discussion as well. I started with a patch to put the program name into avc
messages and Stephen Smalley changed the patch to put the processing in
audit_log_exit.
There is a minor problem in the SE Linux avc messages that makes it hard to
interpret what has failed. For example, if you have a shell script that tries
to read a file that's in a different context, you get a message with
exe=/bin/sh. This causes trouble tracking down the rogue script.
The attached patch against 2.6.11 changes the output of an AVC denial message
so that it looks like this:
type=KERNEL msg=audit(1112293183.500:1591315): item=0 name=/usr/X11R6/bin/id
inode=573518 dev=03:02 mode=040755 uid=0 gid=0 rdev=00:00
type=KERNEL msg=audit(1112293183.500:1591315): syscall=195 exit=-13 a0=9ef71e8
a1=bfe1e850 a2=b6cff4 a3=9ef71e8 items=1 pid=3583 loginuid=525 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm=named exe=/bin/bash
type=KERNEL msg=audit(1112293183.500:1591315): avc: denied { search } for
name=bin dev=hda2 ino=573518 scontext=root:system_r:named_t
tcontext=system_u:object_r:bin_t tclass=dir
To get this, I deleted named, replaced it with a shell script that tries
to cat /etc/shadow. As you can see, it now says comm=named. You also get
the syscall information which could help policy writers correct problems
with less guessing. All around, its a plus for SE Linux.
How does this affect auditing? The audit record now has 2 new fields.
I put the following rules into the audit system:
-a entry,always -S execve
-a entry,always -S open
And within seconds got this:
type=KERNEL msg=audit(1112294058.648:2278762): syscall=5 exit=-2 a0=961f198
a1=18800 a2=2086b9 a3=18800 items=1 pid=3336 loginuid=525 uid=525 gid=525
euid=525 suid=525 fsuid=525 egid=525 sgid=525 fsgid=525 comm=gam_server
exe=/usr/libexec/gam_server
type=KERNEL msg=audit(1112294059.206:2279059): item=0 name=/dev/hdd inode=1357
dev=00:0d mode=060600 uid=525 gid=6 rdev=16:40
type=KERNEL msg=audit(1112294059.206:2279059): syscall=5 exit=4 a0=890b2f0
a1=8880 a2=0 a3=8880 items=1 pid=2744 loginuid=-1 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 comm=hald exe=/usr/sbin/hald
You now see what the exe's path is and what the program calls itself. This can
help interpret the audit messages since now you know that pid 2744 was the
hal daemon. So, I think this will be a big plus for auditing, too.
What do you guys think?
-Steve Grubb
21 years
[RFC][PATCH 0/2] (#6 U2) filesystem auditing
by Timothy R. Chavez
Hello,
:: TERMINOLOGY ::
watch : data that describes a file or directory that should be audited
watchlist : a linked list of watchlist entries residing on a directory
watchlist entry (wentry): an entry to a watchlist that contains a watch
:: INTRODUCTION ::
In an effort to make the mainline kernel's audit subsystem Controlled Access
Protection Profile (CAPP)/Evaluation Assurance Level (EAL) 4 compliant, this
patch adds file system auditing support to the audit subsystem. Such
support is essential in meeting certification requirements because it allows
the evaluator to confirm all claims made about the Target of Evaluation (TOE)
regarding the behavior of file system objects (which are outlined in the
Security Target for the given evaluation) by consulting the audit log.
To achieve such results, it's necessary for the audit subsystem to identify
and keep track of such objects. Due to the abstract nature of "identity"
with regards to file system objects and how that "identity" translates
between the user's perspective and the kernel's perspective and visa-versa, a
fairly strict definition is devised. This implementation uses a scheme by
which parent directories have a "watchlist" that qualifying children may
point into at the "watchlist entry" that holds their "watch". Pointing at a
"watchlist entry" translates into "being watched".
It is also important to keep in mind that in a CAPP environment, we assume the
administrator to be benign and that we are preventing subversion of the audit
subsystem for the purpose of evaluation and not user/process malice.
This component is not designed for filesystem notifications, process/user
snooping, intrusion detection, etc.
:: DESCRIPTION ::
Below is a basic description of this patches capabilities. These capabilities
are enabled by the user space program, auditctl, which is available in the
audit package (found at: http://people.redhat.com/sgrubb).
1. Insertions
When the administrator targets a file system object for audit, they do so by
<path> name. This is an absolute target -- meaning, the administrator targets
the file system object by name, on a given device, in a given namespace.
Provided the parent directory of the targeted object exists, we add to it's
"watchlist" the "watch" for our targeted object. Thus, all information about
the watched object is stored on inodes, in memory, and not on disk. When
adding a "watch" at <path>, the terminating file or directory at <path> need
not exist. (ie: if we wish to watch /tmp/foo, /tmp must exist, but 'foo'
does not have too). This is reasonable in a CAPP environment.
2. Removal
Likewise to inserting watches, we may remove a watch in the same fashion.
If the terminating file or directory name was found in its parent's watchlist,
the corresponding "watchlist entry" is unhashed. Once this "watchlist entry"
is unhashed, it becomes invalid (ie: it may be overwritten and will no longer
generate audit records).
3. Listings
It'd be helpful for the administrator to be able to determine what watches
already exist directly under a directory, on a given device, in a given
namespace. To do so, the admistrator must target a specific directory via a
path (using the given device, in the given namespace) and a list of any
watches in that directory's watchlist will be returned.
4. Hooks
To make this all work, there are three sets of hooks the audit subsystem uses.
1. The first set of hooks manage the inode's audit_data memory. Two hooks:
one to allocate memory and one to free memory.
2. The second set of hooks is used in the dcache to attach watches to a
dentry's inode->i_audit->wentry field (ie: these hooks are responsible for
*watching* a file system object).
Creation:
We use hooks in d_instantiate() and d_splice_alias() to immediately attach
watches, if they exist, to newly created / spliced dentries.
Watch/removal:
We use the __d_lookup() hook for two reasons: to assign a new "watch", if one
exists at this location (ie: a hardlink that's just become "unwatched" exists
in a location that has a "watch") and to detach unhashed (invalid) watchlist
entries (wentries) on inodes.
Deletion:
The d_delete() hook is used to drain watchlists and detach from a "watch".
We've effectively left the "watch".
Movement:
The d_move() hook is used to remove the "watch" and drain the "watchlist" from
a dentry prior to "moving" it (leaving the "watch"), and then attach to it, a
new "watch", if the location it's now at is being "watched".
3. The third set of hooks are all used to notify the audit subsystem about
access to a "watched" object. These hooks tell the audit subsystem to
generate a record.
Permissions:
This is a good junction to place a hook that generates audit records. These
functions are consulted before we commit to action, thus, whether we fail or
not, we get records. Not always can we map a permissions check one-to-one
with a watched file system object (ie: unlink), thus other hooks are
required.
An added benefit of hooking permission functions, is the ability to "watch"
the parent directory of a "watched" file, to see how it was consulted when
attempting access of the "watched" file. We have hooks at permission() and
exec_permission_lite().
Creation:
For creation, we have hooks in vfs_link()/symlink()/create()/mkdir()/mknod().
Once we have the inode (post creation), and we're attached (post
audit_attach_watch), we want to generate a record.
Deletion:
For deletion, we hook may_delete(). We do so because vfs_unlink()/rmdir()
both make use of this function; it is a good junction.
Rename:
For renaming, we hook vfs_rename_other()/rename_dir() to genereate audit
records describing the rename in to a "watched" location, and rely on the
may_delete() hook to give us an audit record describing the rename out of a
"watched" location.
Open:
I think these hooks can be dropped. Will do before we send out to
linux-fsdevel.
5. Notable Behavior
This system allows for only one type of implicit watch; hardlinks. One may
create a hardlink to a "watched" file and it too, will be watched. They can
"move" this hardlink around, and it will remain watched. This is because
both the watched object and the hardlink share the same inode. However,
should the "watched" object (ie: the dentry belonging to this inode that meets
the aforementioned criteria) no longer meet this criteria, the hardlink will
no longer be attached to this "watch" -- In fact, the next time the inode is
accessed, should a hardlink exist in another "watched" location, the inode
would attach to this "watch" (See, 4. Hooks). This makes sense, but in a
subtle way. If we create a dentry, such that we become watched again, even
though there are now at least two files on the system that could contain the
same content, our one time hardlink, has effectively become a separate object
to us. Thus it is important to realize that we are not auditing access to
specific content.
This being said, if we decide to "move" in any way, out of a "watched"
location, we lose the "watch" -- Thus, if we: mv, cp, rm (or use their
underlying syscalls), we'll lose the "watch" and thus, we will no longer be
audited. It's important, however, to keep in mind that we will get final
records based on these actions (ie: if we do mv /tmp/foo to /tmp/bar
and /tmp/foo is being watched, we will see a record for the rename out
of /tmp/foo. And, if we do mv /tmp/bar /tmp/foo, we will see a record for
the rename into /tmp/foo).
-tim
21 years
Supporting linux-audit in our 2.6 kernel
by Joe Porter
Hello linux-audit,
We are suddenly under a lot of time pressure to
demonstrate linux-audit working in our 2.6.6 kernel.
This kernel is booted with a RHEL 3 update 3 userland.
Obviously there is a mismatch between our userland
and kernel with respect to supporting linux-audit.
Here's what I've done:
1. I built our kernel with the CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y config options.
2. I removed the laus-0.1-65RHEL3 rpm and installed
the audit-0.5-1 rpm.
3. I booted the mix and got the auditd daemon running
4. I tried some auditctl commands, but had no clue how to
test the mix. I have no idea how to configure this and I
can't find any documentation on the interface.
Am I on the right track?
Where can I find documentation?
How do I do at least a sanity check? (login and passwd file)
Do I need any kernel patches for 2.6.6 and audit-0.5-1?
Should I try the audit-0.6.5 and are there any kernel patches needed?
We have to be ready by Friday.
Thanks a million for any advice. If we are successful, I'm fairly
certain this will ship with our product from now on. We'd be glad to
provide testing feedback to you.
Thank You,
Joe Porter
Senior Software Engineer
Concurrent Computer Corporation
21 years
[RFC][PATCH 1/2] (#6 U2) filesystem auditing
by Timothy R. Chavez
Hello,
Here is the patch that implements the filesystem auditing component of the
audit subsystem. For this list, attached as a file /w CHANGELOG. Patched
against linux-2.6.11.5 -- Please note, this is untested in SMP (sorry
Stephen, haven't had the time; will do tomorrow).
CHANGELOG
+ Changed naming convention (most notably, removed my initials)
-> linux-2.6.11.5-auditfs-tc1-6-2.patch to linux-2.6.11.5-auditfs.6.2.patch
+ Unconditionally allocate inode->i_audit, initialize to NULL
-> Hook (1) in inode_alloc() : audit_inode_alloc()
-> Hook (1) in destroy_inode() : audit_inode_free()
+ Additional placement of audit_notify_watch() hooks
-> Hook (2) open_namei() : catch on succ/fail paths
-> Hook (1) vfs_create() : catch post create
-> Hook (1) vfs_mkdir() : catch post mkdir
-> Hook (1) vfs_mknod() : catch post mknod
-> Hook (1) vfs_symlink(): catch post symlink
-> Hook (1) vfs_link() : catch post link
-> Hook (1) vfs_rename_dir : post rename
-> Hook (1) vfs_rename_other : post rename
+ Modified placement of audit_attach_watch() hooks
-> Hook (1) d_move() : catch post move to attach watch
+ Added support for audit_context.aux (but did not add IPC portion)
+ Shifted audit_notify_watch() back to kernel/auditsc.c
-> Store accessed audit_watch information on audit_context.aux to dump at
audit_log_exit(), rather then instant delivery to user space.
+ Changed audit_watch *req field of audit_receive_watch() to void *
+ Shifted sanity checking / copying of watch data from userspace back into
audit_watch_insert() and audit_watch_remove()
+ Added AUDIT_WATCH_LST support
-> Added to switch statement in audit_receive_msg(), audit_netlink_ok(),
and audit_receive_watch()
+ Added audit_watch_to_string() to convert watch to string
+ Added audit_list_watches() to send watches on a given directory back to user
space in the form of strings
+ Added AUDIT_WATCH_ERR support - generic channel to send messages about watch
actions to userspace; convert audit_receive_watch() to use this
+ Moved placement of locked audit_fetch_watch of parent above write_lock on
child to prevent deadlock if parent == child in audit_attach_watch. Have not
tested code on SMP, however.
--
-tim
21 years
[RFC][PATCH 2/2] (#6 U2) filesystem auditing
by Timothy R. Chavez
Hello,
Here is the patch that adds new functionality to the audit-0.6.9 as well as
changes some old. Patched against audit-0.6.9.
CHANGELOG
+ The major addition is the ability to "list" watches on a given directory.
-> Added AUDIT_WATCH_LST macro
+ Defined new -L option
-> Added a new "watch" field to the audit_reply struct
-> Added new function audit_list_watches() to libaudit
-> Added support for watch listing in auditctl
+ Gave ability for auditctl to receive AUDIT_WATCH_ERR messages
-> Made it so the kernel could send AUDIT_WATCH_ERR messages regarding
AUDIT_WATCH_INS/REM/LST in the same fashion.
+ Changed types in libaudit to be identical to the types of audit_watch in
audit.h
--
-tim
21 years
what's in the works
by Timothy R. Chavez
Hello,
1. LIST WATCHES
I'm just finishing up the "list watches" feature and I have a question. With
the current design, there is no way to tell the kernel, "give me a list of
all watches". Currently, a watch is a structure with these fields:
name : the name of dentry->d_name that's to be watched
filterkey : an arbitrary string no greater then 32 bytes (including
terminating \0)
perms : permissions filter
Thus you really wouldn't know the location of these watches. So, perhaps I
could add a 'path' field which just kept the path I specified when the watch
was inserted. But, this too might be misleading (if we are to every change
namespaces) or the administrator uses a relative path. We technically do
support relative paths when inserting/removing a watch (even though auditctl
warns otherwise). Furthermore, would this look bad when trying to sell this
to fsdevel or LKML?
So, the compromise I came up with is to add an option to auditctl, '-L' which
would allow the admin to check the watches on a given path. I think this
fits decently with the idea behind this feature: to help the administrator
remember what watches they set. So now, it looks like this:
./auditctl -w /audit/foo
./auditctl -w /audit/bar
./auditctl -L /audit
AUDIT_WATCH : LIST : /audit/foo
AUDIT_WATCH : LIST : /audit/bar
I'm working on getting the entire struct exported to userspace so we can also
say something about the perms filter and filterkey.
2. HOOKS
So I've been experimenting around and have hooks capturing what I think is
required by CAPP. Klaus, when this patch is released we REALLY need your
input and appraisal. One of the problems we face here is that "access" can
generate multiple records and for some reason it feels like the administrator
would have to have some sort of knowledge of what's going on in the kernel
that extends past intuition. For this reason, I feel like perhaps I should
have another field that provides some sort of context to the record. So for
instance, if the record was generated from a permissions function, we'd set
the "context" field to show that. Is this a good idea?
When I post the patch, I'll post it with a list of hooks and what each does.
-tim
21 years
Joint Venture Partners
by Shaun Anthony
I hope this finds you well, as you may already know, we specialized in assisting small businesses in Going Public. We also assist with Private Placement preparation and public company filings. The President of our company is a very experienced securities and corporate law attorney.
We would like to propose a joint venture with you. If you or a associate of yours are interested in taking a company public, please let us know. We are happy, for you to be very generously compensated for any referral.
Many people are not aware that any company can go public including a start up or development stage company. Please visit our site or email us to receive our Go Public Report and our Advantages of Going Public Report.
I wish I could convey to you, all the many benefits of going public in a brief letter. I am not sure if you can imagine how valuable and powerful a public company can be in achieving your goals and objectives.
Since we provide such an outstanding service and have a great deal of experience, you may want to pass this email on to an associate or you can send us their information.
We look forward to hearing from you soon.
Sincerely,
Shaun Anthony
http://www.goingpublicinformation.net/
#CSCGIBF-0326CP
We also have newsletter available.
P.S. If you prefer not to hear from us any longer, email us with no longer in the subject.
takeoff(a)goingpublicinformation.net
8721 Santa Monica Bl. #359 Los Angeles, CA90069
21 years
