auditing a specific file on Tru64

[Aladdin_2]

Hello everyone:
I have a Tru64 system, and I have auditing is enabled on it, ( though I still have pbms in generating required reports), can I regardless of my current running auditing, make an auditing on a specific file on the system, to monitor which users accessed this file, is there like some special option I have to use with the "audit" for this file, or I should use some tools??

Thanks a lot.

[Ivan Ferreira]

Please see "Auditing File Operations" (auditmask -x filename) in the Tru64 Unix Security Administration Guide.

[Ann Majeske]

Also check out the man page for auditmask. Specifically the information for -s obj_sel
and the -x and -X options.

Ann

[Aladdin_2]

THX alot for your replies,


After search,I tried the auditmask -x command, and here is the result I got:

#root@billing2# auditmask -x /tmp/alaa [:1|:0]
selection: on => on -- /tmp/alaa
Can't find event #
Can't find event This
Can't find event is
Can't find event a
Can't find event SAMPLE
Can't find event alias
Can't find event list.
Can't find event Your
Can't find event alias
Can't find event list
Can't find event should
Can't find event be
Can't find event built
Can't find event to

is somthing still missing here, or I issued the wrong command??

Thanks in advance

[Aladdin_2]

ooops, this will sound so dummy.
It seems I overwrote some existing audit policy my system already has.
I issued the following command:

#auditmask -x /tmp/alaa

thought that will audit the file /tmp/alaa.

however I ended up finding such process running:

root 1291907 1048577 0.0 07:37:22 ?? 0:00.02 /usr/sbin/auditd -l /var/audit/auditlog -c syslog -o overwrite

so I killed this process, but when I checked the file /tmp/alaa
I fouond it full of auditing records, so now it is contains the auditing recoreds instead of being audited.

any advise??

Thanks

[Aladdin_2]

I checked the man pages, seems all files i need to restore.
but I have the following log message:


Quote:
Jul 12 22:01:07 billing2 vmunix: warning: /dev/audit closed (pid 1291907), but audit still enabled

what do you think??

[Ann Majeske · Accepted solution]

You need the auditd process running on the system if you are going to do auditing. You will always see this process running on the system when you have Auditing enabled. The message you're getting is because auditing is enabled but the auditd is not running because you killed it. Changing the auditmask should not change where audit records are going (this is done by auditd). Are you sure that the command you entered was "auditmask -x" and not "auditd -x" or something similar??

To restart auditd with the original parameters try running:
# /sbin/init.d/audit stop
# /sbin/init.d/audit start

Please read the chapter on auditing in the Security Administration manual: http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/ARH95ETE/TITLE.HTM

You may also want to consult with your system administrator about making these changes so that you don't interfere with the normal auditing done on the system.

[Aladdin_2]

Thanks alot Ann Majeske.
I really appreciate your help, seems things are going worse with me.
I became suddenly the system administrator, now the users are complaining they cant log in to the system, after they enter user name and passowrd, the system just display their last log in info, and dsnt log them to the session. However As a root Im still able to log in.
I tried stop the audit process, it froze for like 30 mnts and didnt stop it.

Do you have any idea why other users are not being able to log in??
Im sure that I used the -x option with the auditmask command not the "-X"

Thanks again for your help and concern.

[Ann Majeske]

If you haven't already fixed this, you can try restarting the auditd by restarting an auditd process with the same parameters as the one you killed, i.e.:
#/usr/sbin/auditd -l /var/audit/auditlog -c syslog -o overwrite
But, it's hard to know if this will fix the problem with users being able to log in or not. Depending on how much grief you're getting from users not being able to log in VS how much grief you'd get if the system went down, I'd be tempted to just reboot the system and see how things go from there.

Ann