LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
LinkBack Search this Thread
Old 06-11-2010, 07:49 PM   #1
ichrispa
Member
 
Registered: Mar 2005
Location: Dresden, Germany
Distribution: OpenSuse 11.2/3, Debian 5.0 , Debian 1.3.1, OpenBSD
Posts: 270

Rep: Reputation: 31
auditd missing syscalls?


Hi everyone,

I want to monitor a part of my filesystem for changes, including file opening and attempts to open files/dirs without necessary permissions.

Since every read/write/open is run by syscalls i figured that running the auditd would be the simplest way to do this. I installed auditd and added a rule:

Code:
auditctl -w /srv -p warx
However I do not get any writes reported via ausearch -i. As a simple example, if I run

Code:
touch /srv/afile; echo abcd >> /srv/afile
I only see an "open" syscall. I expected an open, then a write and then a close (correct me if i'm wrong please).

Did I misunderstand the concept of auditd and auditctl, is the rule wrong or what did I do wrong here?

Thanks in advance.

Last edited by ichrispa; 06-11-2010 at 08:19 PM.
 
Old 06-12-2010, 04:06 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,549
Blog Entries: 51

Rep: Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610
If you add a rule '-w /some/path/ -k log_tag' then auditd will translate that as '-a exit,always -F dir=/some/path/ -p rwxa -k log_tag' so basically you don't need to specify "rwxa" anyway. However 'man 8 auditctl', "-p" says: "Set permissions filter for a file system watch. r=read, w=write, x=execute, a=attribute change. These permissions are not the standard file permissions, but rather the kind of syscall that would do this kind of thing. The read & write syscalls are omitted from this set since they would overwhelm the logs. But rather for reads or writes, the open flags are looked at to see what permission was requested.". To illustrate this: even an explicit rule for open, close and write syscalls ('ausyscall 4') with exits based on EACCESS / EPERM DAC mismatch like '-a exit,always -S open -S close -S write -F dir=/some/path/ -F exit=-1 -F exit=-13 -k log_tag' won't show me type=SYSCALL log entries other than syscall=5 success=.* exit=.*.
 
Old 06-12-2010, 08:08 AM   #3
pixellany
LQ Veteran
 
Registered: Nov 2005
Location: Annapolis, MD
Distribution: Arch/XFCE
Posts: 17,802

Rep: Reputation: 728Reputation: 728Reputation: 728Reputation: 728Reputation: 728Reputation: 728Reputation: 728
Moved to Linux-Security
 
Old 06-12-2010, 10:48 AM   #4
ichrispa
Member
 
Registered: Mar 2005
Location: Dresden, Germany
Distribution: OpenSuse 11.2/3, Debian 5.0 , Debian 1.3.1, OpenBSD
Posts: 270

Original Poster
Rep: Reputation: 31
i see. so the omitting of the syscalls is less a mistake then means to keep the log size reasonable.

The scenario I am trying to cover is the following:
- I want to know when a user accesses a file (as in "I read the memo")
- When a user modifies a file (as in "but I did update the statistics this morning")
- When a user deletes a file (as in "I never got that piece of informations")

I am aware of the "Big Brother"-implications that procedure brings with it, but this is a high sec server with non-public projects on it. Management insists on the ability to track user behavior to that detail when they are working on it.

The problem is that I am interested particularly in modifications along with the access.

Tripwire or FAM can tell me if the data has been modified, but I lack the info of whether it was just read. Also, it would also track only a single change between scans.
inotify can tell me both if a file was accessed or modified, but it can't track the uid along with it.
auditd can tell me who opened a file, but without the write-syscall I can't differentiate between just opening with write permissions open(filename, O_RW) an the actual modification.

I hoped that I could make auditd show me that, but that does not seem to be the case. Is there any other way to interrogate the kernels audit-structures so I dont's need to create a hyprib inotify/audit log?
 
Old 06-13-2010, 06:51 AM   #5
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,549
Blog Entries: 51

Rep: Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610Reputation: 2610
OK, here's FUSE-based LoggedFS started as './loggedfs -f -l ./loggedfs.log -c ./loggedfs.xml -p /path/' showing subject executing a 'ls' and then a 'vi filename':
Code:
00:01:28 (src/loggedfs.cpp:699) LoggedFS log file : ./loggedfs.log
00:01:28 (src/loggedfs.cpp:693) Configuration file : ./loggedfs.xml
00:01:28 (src/loggedfs.cpp:684) LoggedFS running as a public filesystem
00:01:28 (src/loggedfs.cpp:818) LoggedFS starting at /path/.
00:01:28 (src/loggedfs.cpp:838) Using configuration file ./loggedfs.xml.
00:01:28 (src/loggedfs.cpp:843) chdir to /path/
00:01:39 (src/loggedfs.cpp:138) readdir /path/dir {SUCCESS} [ pid = 7165 /bin/ls uid = 501 ] 
00:01:46 (src/loggedfs.cpp:138) open /path/dir/filename {SUCCESS} [ pid = 7168 file uid = 501 ] 
00:01:46 (src/loggedfs.cpp:138) read 4096 bytes from /path/dir/filename at offset 0 {SUCCESS} [ pid = 7168 file uid = 501 ] 
00:01:46 (src/loggedfs.cpp:138) 1085 bytes read from /path/dir/filename at offset 0 {SUCCESS} [ pid = 7168 file uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) open /path/dir/filename {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) mknod /path/dir/.filename.swp 100600 S_IFREG (normal file creation) {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) open readwrite /path/dir/.filename.swp {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) mknod /path/dir/.filename.swpx 100600 S_IFREG (normal file creation) {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) open readwrite /path/dir/.filename.swpx {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) unlink /path/dir/.filename.swpx {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) unlink /path/dir/.filename.swp {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) mknod /path/dir/.filename.swp 100600 S_IFREG (normal file creation) {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) open readwrite /path/dir/.filename.swp {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) write 4096 bytes to /path/dir/.filename.swp at offset 0 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) 4096 bytes written to /path/dir/.filename.swp at offset 0 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) chmod /path/dir/.filename.swp to 100640 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) open /path/dir/filename {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) read 4096 bytes from /path/dir/filename at offset 0 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:51 (src/loggedfs.cpp:138) 1085 bytes read from /path/dir/filename at offset 0 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:55 (src/loggedfs.cpp:138) write 4096 bytes to /path/dir/.filename.swp at offset 4096 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:55 (src/loggedfs.cpp:138) 4096 bytes written to /path/dir/.filename.swp at offset 4096 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:55 (src/loggedfs.cpp:138) write 4096 bytes to /path/dir/.filename.swp at offset 8192 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:55 (src/loggedfs.cpp:138) 4096 bytes written to /path/dir/.filename.swp at offset 8192 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) mknod /path/dir/4913 100640 S_IFREG (normal file creation) {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) open writeonly /path/dir/4913 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) chown /path/dir/4913 to 501:501 username:username {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) unlink /path/dir/4913 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) rename /path/dir/filename to /path/dir/filename~ {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) mknod /path/dir/filename 100640 S_IFREG (normal file creation) {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) open writeonly /path/dir/filename {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) write 1085 bytes to /path/dir/filename at offset 0 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) 1085 bytes written to /path/dir/filename at offset 0 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) chmod /path/dir/filename to 100640 {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) unlink /path/dir/filename~ {SUCCESS} [ pid = 7169 vim uid = 501 ] 
00:01:57 (src/loggedfs.cpp:138) unlink /path/dir/.filename.swp {SUCCESS} [ pid = 7169 vim uid = 501 ]
You see it logs everything you requested.

HTH

* For anyone wanting to try LoggedFS using RPM, the .spec file is here.
 
Old 06-13-2010, 10:31 AM   #6
ichrispa
Member
 
Registered: Mar 2005
Location: Dresden, Germany
Distribution: OpenSuse 11.2/3, Debian 5.0 , Debian 1.3.1, OpenBSD
Posts: 270

Original Poster
Rep: Reputation: 31
Looks like we have a winner.

Thank you very much guys.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] No rule to make target `missing-syscalls'. Stop. rubadub Programming 5 06-08-2010 05:31 PM
auditd: auditd startup failed cmschube Red Hat 2 05-11-2009 07:08 AM
syscalls palisetty_suman Linux - Newbie 2 01-27-2009 10:35 PM
Missing Auditd Command AmdMhz Linux - Newbie 1 11-19-2008 11:31 AM
syscalls.h ashlesha Programming 3 04-03-2007 10:56 AM


All times are GMT -5. The time now is 11:58 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration