audit 0.9.3 released
by Steve Grubb
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit It will also be in rawhide
tomorrow. The Changelog is:
- Change filename handling to use linked list in ausearch
- Add man pages for audit_setloginuid & audit_getloginuid
- Fix problem where you couldn't set rule on unset loginuid's
- Adjust memory management for sighup needs
- Fix problem where netlink timeout counter wasn't being reset
This is mostly bug fixes. This version requires having the new
glibc-kernheaders audit.h. I will place a link to that file if you need it.
Just install it to /usr/include/linux/audit.h and you should be set.
-Steve
19 years, 6 months
rename syscall error with the .55.and .56 kernels
by Loulwa Salem
Hi,
Marly (our intern) discovered a problem in the rename syscall. We tried
many versions, and up to 51 this problem was not happening (52 and 53
did not boot for us).
The test we are running is part of LTP and it is rename04.c (under
ltp-full/testcases/kernel/syscalls/rename)
The test does the following:
- create temp directory (ex /tmp/dir1)
- create another temp directory ( ex /tmp/dir2) and create a file in it
(ex /tmp/dir2/foo)
- perform the rename syscall
rename(/tmp/dir1, /tmp/dir2)
The test is expecting this call to fail with an errno of ENOTEMPTY (As
documented in the man pages). This call returns an unexpected 0, however
the renaming does not actually occur and the two directories remain
unchanged.
We saw this behavior on x86_64, i386
- loulwa & Marly
19 years, 6 months
adding syscall rules
by Amy Griffis
Hello,
I've noticed some odd behavior when adding medium to large numbers of
syscall rules. I'm doing my testing on an ia64 system with the
audit.56 kernel and the audit-0.9.2 package.
When adding the 31st rule, the 'No watches' message is not printed
following the auditctl command to add the rule, or any subsequent
auditctl -l calls. This seems to happen for any number of rules
greater than 30.
When the 61st rule is added, it does not appear in the rules list when
adding the rule, or any following auditctl -l calls. 60 seems to be
the maximum number of rules that can be listed. I do see an 'added an
audit rule' message in the audit log for the 61st rule, and can
generate audit records from it.
After adding the 116th rule, I can no longer delete all the rules with
auditctl -D. In fact, the command appears to hang, with no output
going to the audit log. If I bring the number of rules down to 115,
then -D will work again.
On a related note, I've been working on putting together a default
CAPP configuration that can be loaded via auditctl, similar to LAuS's
filter.conf file. Has anyone else been working on this? Are there
plans to provide something like this?
Thanks,
Amy
19 years, 6 months
audit.56 merged with audit-2.6.git
by Timothy R. Chavez
Alright,
Cardinal sin here... I've not only attached the patch, but I've tarred and gzipped it :)
I merged all the changes in audit.56 that were not in audit-2.6.git for the LKML RFC.
If you could please look over this and maybe even build and test a little to make sure
it works, that'd be good! I did a little testing and things seem to be in good order,
but it doesn't hurt to have an extra set of eyes and what-not.
There is a problem that hasn't been worked out yet that is preventing us from adding a
large number of watches... it bombs at around ~360 insertions IF we're triggering those
watches (adding watches, touching the watch file), but works perfectly fine when we
simply add them without triggering them.
There are still some other things that need to be done, minor things, with regards to
auditfs (like logging when implicit watch removals occur), but other then that I think
David and I feel this is probably ready for an LKML RFC.
Should I remove all parts of this patch that do not pertain to auditfs? Should we
push Chris's netlink work to the git tree and then patch against that for RFC?
19 years, 6 months
File system audit loses watches
by Steve Grubb
Hi,
>From a session I just run on the .56 kernel:
[root@endeavor ~]# auditctl -w /media/cdrecorder/eula.txt -k test -p wrea
No rules
AUDIT_WATCH_LIST: dev=22:64, path=/media/cdrecorder/eula.txt, filterkey=test,
perms=rwea, valid=0
[root@endeavor ~]# auditctl -l
No rules
AUDIT_WATCH_LIST: dev=22:64, path=/media/cdrecorder/eula.txt, filterkey=test,
perms=rwea, valid=0
[root@endeavor ~]# eject
[root@endeavor ~]# auditctl -l
No rules
No watches
Looking through the audit logs, the is one CONFIG_CHANGE record with watch
insert. No records with watch remove. The removal of a rule is a config
change and should have a corresponding audit event. But...rules should never
be lost unless they are explicitly deleted by the admin should they?
-Steve
19 years, 6 months
Boundary tests for filename/pathname
by Loulwa Salem
Sorry ... the first copy of this was under a non related thread ... my
clue to go home ..
Hi,
I am adding the new test cases to check for the boundary conditions on
filename and pathname when inserting watches...
I am trying the following scenarios:
Filename > NAME_MAX (260)
Filename = NAME_MAX (255)
Filename = NAME_MAX+1 (256)
Filename = NAME_MAX-1 (254)
Pathname > PATH_MAX (4098)
Pathname = PATH_MAX (4095)
Pathname = PATH_MAX+1 (4096)
Pathname = PATH_MAX-1 (4094)
The values in () are the strlen() output of what I am actually supplying
the auditctl command (now I am passing those values, assuming that the
null character will bring the value up to what I am testing)
Then I thought to get the latest audit and I look in auditctl.c file, it
seems that it is comparing against strlen() output, so not counting NULL.
Based on what I found, I am thinking my initial assumption above is not
valid, and I need to supply enough characters (without the null) to meet
my test scenario ... Is this correct?
-loulwa
19 years, 6 months
execve
by Steve Grubb
Hello,
ran another test on .56 kernel. I wanted to make sure we are logging
parameters for execve so we can see what is being executed:
type=PATH msg=audit(06/07/05 14:14:28.592:5004271) : item=1 inode=770531
dev=03:02 mode=file,755 ouid=root ogid=root rdev=00:00
type=PATH msg=audit(06/07/05 14:14:28.592:5004271) : item=0 name=/bin/ls
inode=1048599 dev=03:02 mode=file,755 ouid=root ogid=root rdev=00:00
type=CWD msg=audit(06/07/05 14:14:28.592:5004271) : cwd=/root
type=SYSCALL msg=audit(06/07/05 14:14:28.592:5004271) : arch=i386
syscall=execve success=yes exit=0 a0=9195ab8 a1=91a9838 a2=91b1900 a3=91a9838
items=2 pid=4167 auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root
egid=root sgid=root fsgid=root comm=ls exe=/bin/ls
What is the first PATH record showing? I was expecting only 1 item, not 2.
There is no name, yet the mode says its a file. I've checked several apps
doing execve, they all have the same first record with same inode no matter
what I run.
-Steve
19 years, 6 months
.56 kernel FS_WATCH records
by Steve Grubb
Hi,
Testing with the .56 kernel. I did a watch on a file and then did a move:
type=PATH msg=audit(06/07/05 13:54:22.683:3988791) : item=1
name=/mnt/target/etc/passwd.old inode=393217 dev=03:09 mode=dir,755 ouid=root
ogid=root rdev=00:00
type=PATH msg=audit(06/07/05 13:54:22.683:3988791) : item=0
name=/mnt/target/etc/passwd inode=393217 dev=03:09 mode=dir,755 ouid=root
ogid=root rdev=00:00
type=CWD msg=audit(06/07/05 13:54:22.683:3988791) : cwd=/home/sgrubb
type=FS_WATCH msg=audit(06/07/05 13:54:22.683:3988791) : inode=393220
inode_uid=root inode_gid=root inode_dev=03:09 inode_rdev=00:00
type=FS_WATCH msg=audit(06/07/05 13:54:22.683:3988791) : watch_inode=393220
watch=passwd filterkey=test perm=read,write,exec,append perm_mask=write
type=SYSCALL msg=audit(06/07/05 13:54:22.683:3988791) : arch=i386
syscall=rename success=yes exit=0 a0=bfff3be6 a1=bfff3bfd a2=80562a4
a3=bffeea30 items=2 pid=4137 auid=sgrubb uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root comm=mv exe=/bin/mv
Why does FS_WATCH have 2 formats? Both are the same type and have totally
different name/value pairs. This messes up parsing. If they represent 2
different pieces of information, they have to have 2 different message types.
Besides, why are they split like this? They weren't like this last week. This
introduces another 46 byte overhead to diskspace consumption for each record.
Also, in the path record, it is a file - not a dir. The permissions are wrong
as well. sb 0644.
-Steve
19 years, 6 months
audit.56 kernel
by David Woodhouse
* Tue Jun 7 2005 David Woodhouse <dwmw2(a)redhat.com> audit.56
- Consolidate auditfs patches
- Multiple watches per inode, locking simplification (Tim)
--
dwmw2
19 years, 6 months
fsaudit patch against audit.53 RPM
by Timothy R. Chavez
Hello,
I already see two little bugs in my code in audit_remove_watch. David,
before you build can you add in the spin_unlock() before the goto?
kernel/auditfs.c: audit_remove_watch()
+
+ spin_lock(&auditfs_lock);
+ real = audit_fetch_watch(nd.last.name, data);
+ if (!real)
-> spin_unlock(&auditfs_lock);
goto audit_remove_watch_release;
- }
audit_destroy_watch(real);
+ spin_unlock(&auditfs_lock);
And, place before the kfree an audit_watch_put()
kernel/auditsc.c: audit_attach_wdata()
+
+auditfs_attach_wdata_fail:
+ hlist_for_each_entry_safe(this, pos, tmp, &ax->watches, node) {
+ hlist_del(&this->node);
-> audit_watch_put(this);
+ kfree(this);
+ }
+
+ return -ENOMEM
This patch includes David's Implicit unpinning patch.
Changelog:
* Removed a fundamental mathematical operation embedded in
a debugging statement ;)
* Removed the local lock on inode audit data in favor of of a global
auditfs_lock spinlock
* Added a list of watches that could be associated with any given
inode in favor of a pointer to just one
* Attempt to remove watches first via the master watchlist and then
by path lookup
* Remove watch from inode, master watchlist, and local watchlist
when removing watch via administrator action
* Altered record in kernel/auditsc.c to support watches per inode per
record
-tim
19 years, 6 months
