Audit config for NISPOM req's

Audit config for NISPOM req's

[Curtas, Anthony R.]

[-- Attachment #1.1: Type: text/plain, Size: 1340 bytes --]

Hello all,

I've been a linux sysadmin for a while for a small network of systems
under the oversight of the Defense Security Service (DSS).  They have
always given us grief over Linux's inability to log certain events.  A
year ago, I implemented Snare with good results, but lack of a Kernel
panic on audit failure always had them second guessing our setup.  So
I'm encouraged to see the progress made here and am preparing to try
again.

 

Basically, the requirements are to log improper read access to certain
files (audit logs, shadow) and write access to many others (most of
/etc), and in some cases attempts to execute programs like stunnel and
su.

 

My main confusion on getting started is the difference between syscalls
and watches.  It seems watches can do almost all of what I need, but
they seem to be less "configurable" than the syscalls (like ignoring if
root changes anything).  Can someone explain the difference and where
one is more appropriate than the other.

 

I have the CAPP documents from HP and IBM, which seem to be a good
starting point (especially the conf files) - but I'm trying to
understand it all before implementation in case I need to tweak it.

 

Thanks in advance for any help,

Anthony

 

 

_____________

Anthony Curtas

SAIC, Division 35

 


[-- Attachment #1.2: Type: text/html, Size: 4293 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Audit config for NISPOM req's

[Steve Grubb]

On Friday 22 December 2006 08:38, Curtas, Anthony R. wrote:
> My main confusion on getting started is the difference between syscalls
> and watches.

Syscalls audit syscalls based on the various parameters accessible during the 
syscall. This means that every syscall is affected since it has to be 
analyzed to determine if it meets the criteria to trigger or suppress an 
audit event. If you use syscalls to audit files, you have to do it by inode. 
This is fine for files that do not move. You can also use devmajor/minor to 
watch whole disks or devices.

Watches solve the problem by allowing you to audit a file by its name. The 
kernel then converts it to inode auditing internally and changes the inode 
that is being audited whenever the file is moved/renamed. Watches also do not 
affect the performance of every syscall.

> It seems watches can do almost all of what I need, but they seem to be
> less "configurable" than the syscalls (like ignoring if root changes
> anything).

This is true in RHEL4. RHEL5/FC6 is more configurable.

> Can someone explain the difference and where one is more appropriate than
> the other.

Syscalls are appropriate whenever you have something global to audit. Watches 
are more appropriate when you are interested in specific files.

-Steve

RE: Audit config for NISPOM req's

[Curtas, Anthony R.]

Thanks for the response.  What it looks like I need is a few syscalls
and a lot of file watches.  The sample capp.rules I was looking at seems
to fit the bill, although I'll have to add some extra watches to the
/etc directory.

One thing that still confuses me is how "possible" is implemented.  From
what I've read in the documentation, it looks like if you set a rule for
entry,possible -- the audit system waits until a file watch is thrown,
then it writes the event.  Do I have this right?  If I always want to
see when /etc/shadow is opened:

-w /etc/shadow -rwxa
-a entry,possible -S open 

Will that work?  And if I understand the mechanism correctly, that would
log an open of ANY file that has a watch on it?

One last thing, if I only want unsuccessful open attempts on the watch
files, would this work?
-a entry,possible -S open -F success!=1

Thanks again,
Anthony


_____________
Anthony Curtas
SAIC, Division 35


-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Friday, December 22, 2006 9:20 AM
To: linux-audit@redhat.com
Cc: Curtas, Anthony R.
Subject: Re: Audit config for NISPOM req's

On Friday 22 December 2006 08:38, Curtas, Anthony R. wrote:
> My main confusion on getting started is the difference between
syscalls
> and watches.

Syscalls audit syscalls based on the various parameters accessible
during the 
syscall. This means that every syscall is affected since it has to be 
analyzed to determine if it meets the criteria to trigger or suppress an

audit event. If you use syscalls to audit files, you have to do it by
inode. 
This is fine for files that do not move. You can also use devmajor/minor
to 
watch whole disks or devices.

Watches solve the problem by allowing you to audit a file by its name.
The 
kernel then converts it to inode auditing internally and changes the
inode 
that is being audited whenever the file is moved/renamed. Watches also
do not 
affect the performance of every syscall.

> It seems watches can do almost all of what I need, but they seem to be
> less "configurable" than the syscalls (like ignoring if root changes
> anything).

This is true in RHEL4. RHEL5/FC6 is more configurable.

> Can someone explain the difference and where one is more appropriate
than
> the other.

Syscalls are appropriate whenever you have something global to audit.
Watches 
are more appropriate when you are interested in specific files.

-Steve

Re: Audit config for NISPOM req's

[Steve Grubb]

On Friday 22 December 2006 10:08, Curtas, Anthony R. wrote:
> One thing that still confuses me is how "possible" is implemented.

Possible means to collect the information at entry in case its needed later. 
Rules with possible will never trigger an event, they simply tell it to 
collect the information. A watch or SE Linux AVC would actually use the 
information collected.

> From what I've read in the documentation, it looks like if you set a rule
> for entry,possible -- the audit system waits until a file watch is thrown,
> then it writes the event.  Do I have this right?  

Yes.

> If I always want to see when /etc/shadow is opened:
>
> -w /etc/shadow -rwxa
> -a entry,possible -S open

That would be opened for write or execute.

> Will that work?  And if I understand the mechanism correctly, that would
> log an open of ANY file that has a watch on it?

Not quite. It will collect the information for any open, but only emit an 
event when shadow is opened for write or execute.

> One last thing, if I only want unsuccessful open attempts on the watch
> files, would this work?
> -a entry,possible -S open -F success!=1

It should collect the information for later use. If you wanted all 
unsuccessful opens, I'd rewrite as:

-a exit,always -S open -F success!=1

-Steve

RE: Audit config for NISPOM req's

[Wieprecht, Karen M.]

So you still need a watch on the file in order to collect get audit events to be generated in the event of file access failures, is that correct?

Karen Wieprecht 

-----Original Message-----
From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb
Sent: Friday, December 22, 2006 10:33 AM
To: Curtas, Anthony R.
Cc: linux-audit@redhat.com
Subject: Re: Audit config for NISPOM req's

On Friday 22 December 2006 10:08, Curtas, Anthony R. wrote:
> One thing that still confuses me is how "possible" is implemented.

Possible means to collect the information at entry in case its needed later. 
Rules with possible will never trigger an event, they simply tell it to collect the information. A watch or SE Linux AVC would actually use the information collected.

> From what I've read in the documentation, it looks like if you set a 
> rule for entry,possible -- the audit system waits until a file watch 
> is thrown, then it writes the event.  Do I have this right?

Yes.

> If I always want to see when /etc/shadow is opened:
>
> -w /etc/shadow -rwxa
> -a entry,possible -S open

That would be opened for write or execute.

> Will that work?  And if I understand the mechanism correctly, that 
> would log an open of ANY file that has a watch on it?

Not quite. It will collect the information for any open, but only emit an event when shadow is opened for write or execute.

> One last thing, if I only want unsuccessful open attempts on the watch 
> files, would this work?
> -a entry,possible -S open -F success!=1

It should collect the information for later use. If you wanted all unsuccessful opens, I'd rewrite as:

-a exit,always -S open -F success!=1

-Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Audit config for NISPOM req's

[Steve Grubb]

On Friday 22 December 2006 11:22, Wieprecht, Karen M. wrote:
> So you still need a watch on the file in order to collect get audit events
> to be generated in the event of file access failures, is that correct?

That entirely depends on the rule. If you are using possible, yes. If your 
rules are always/never or a watch then you should be ok.

-Steve

RE: Audit config for NISPOM req's

[Wieprecht, Karen M.]

The auditctl man page for audit-1.0.14-1EL4 says the following (which
appears to be incorrect):
	To see unsuccessful open calls's:
	auditctl -a exit,always -S open -F success!=0

but an email you sent out a bit ago says this: 

>> If you wanted all unsuccessful opens, I'd rewrite as:
>>
>> -a exit,always -S open -F success!=1

This makes a lot more sense, and I assume that this is the correct
syntax.     You might want to check to see if this has already been
corrected in the man pages for upcoming releases. 

I was hoping that this setting by itself (-a exit,always -S open -F
success!=1) would show me any failed file opens on the whole machine,
so I don't understand why I don't get any audit events  with this
configuration.  I thought that maybe I also  have to have a watch set on
a file, then tell auditd  which events I want to collect with the "-a
exit,always -S open -F success!=1" setting, but that didn't do it
either.      Here's what I was testing 

/etc/audit.rules :

-D
-w /etc/nsswitch.conf -rwxa
-a exit,always -S open -F success!=1


Then 
	service auditd reload
	service auditd rotate
	autail -f /var/log/audit/audit.log 

Then in another window, as a non-prived user
	rm /etc/nsswitch.conf
	cat /dev/null > /etc/nsswitch.conf
	chown karen /etc/nsswitch.conf
	chmod 777 /etc/nsswitch.conf
	cat somefile >> /etc/nsswitch.conf

I get lots of permission denied messages at the command line, but
nothing in the audit log relating to karen messing around with
/etc/nsswitch.conf.  

I must still be missing some basic understanding of how this all works.
Any helpful suggestions would be greatly appreciated.

Karen Wieprecht
	



Thanks,

Karen Wieprecht

Re: Audit config for NISPOM req's

[Steve Grubb]

On Thursday 11 January 2007 14:18, Wieprecht, Karen M. wrote:
> This makes a lot more sense, and I assume that this is the correct
> syntax. 

And its easy to determine empirically.  :)

> You might want to check to see if this has already been 
> corrected in the man pages for upcoming releases.

hmm...I'll check, thanks.

> I was hoping that this setting by itself (-a exit,always -S open -F
> success!=1) would show me any failed file opens on the whole machine,

It does for me.

> so I don't understand why I don't get any audit events  with this
> configuration.

What arch are you on?

> /etc/audit.rules :
>
> -D
> -w /etc/nsswitch.conf -rwxa
> -a exit,always -S open -F success!=1

You do not need both. The last rule by itself should do it.

> 	service auditd reload
> 	service auditd rotate
> 	autail -f /var/log/audit/audit.log

I don't use autail. I run ausearch to check results.

> Then in another window, as a non-prived user
> 	rm /etc/nsswitch.conf
> 	cat /dev/null > /etc/nsswitch.conf
> 	chown karen /etc/nsswitch.conf
> 	chmod 777 /etc/nsswitch.conf
> 	cat somefile >> /etc/nsswitch.conf
>
> I get lots of permission denied messages at the command line, but
> nothing in the audit log relating to karen messing around with
> /etc/nsswitch.conf.

Are your using ausearch or autail?

-Steve

RE: Audit config for NISPOM req's

[Kirkwood, David A.]

I'm using RHEL4U4 and do not have autail. Where'd it come from? Also,
the doc I have does not metion the -rwxa option for watches. Am I
missing some 
Updates, or do I need to upgrade or is the documentation lagging? 

Separate question. With the watches I have enabled, I never am able to
tie a user to an access violation. How do I do that?

Sorry if I am a little behind. I can only look at this group's mail
messages intermittently do to other responsibilities. I thought I was
near submitting 
A system for government approval, but now I am not so sure.

Thanks,

David 
-----Original Message-----
From: linux-audit-bounces@redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Wieprecht, Karen M.
Sent: Thursday, January 11, 2007 2:19 PM
To: Steve Grubb; Curtas, Anthony R.
Cc: linux-audit@redhat.com; Thomas, Daniel J.
Subject: RE: Audit config for NISPOM req's

The auditctl man page for audit-1.0.14-1EL4 says the following (which
appears to be incorrect):
	To see unsuccessful open calls's:
	auditctl -a exit,always -S open -F success!=0

but an email you sent out a bit ago says this: 

>> If you wanted all unsuccessful opens, I'd rewrite as:
>>
>> -a exit,always -S open -F success!=1

This makes a lot more sense, and I assume that this is the correct
syntax.     You might want to check to see if this has already been
corrected in the man pages for upcoming releases. 

I was hoping that this setting by itself (-a exit,always -S open -F
success!=1) would show me any failed file opens on the whole machine,
so I don't understand why I don't get any audit events  with this
configuration.  I thought that maybe I also  have to have a watch set on
a file, then tell auditd  which events I want to collect with the "-a
exit,always -S open -F success!=1" setting, but that didn't do it
either.      Here's what I was testing 

/etc/audit.rules :

-D
-w /etc/nsswitch.conf -rwxa
-a exit,always -S open -F success!=1


Then 
	service auditd reload
	service auditd rotate
	autail -f /var/log/audit/audit.log 

Then in another window, as a non-prived user
	rm /etc/nsswitch.conf
	cat /dev/null > /etc/nsswitch.conf
	chown karen /etc/nsswitch.conf
	chmod 777 /etc/nsswitch.conf
	cat somefile >> /etc/nsswitch.conf

I get lots of permission denied messages at the command line, but
nothing in the audit log relating to karen messing around with
/etc/nsswitch.conf.  

I must still be missing some basic understanding of how this all works.
Any helpful suggestions would be greatly appreciated.

Karen Wieprecht
	



Thanks,

Karen Wieprecht

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Audit config for NISPOM req's

[Steve Grubb]

On Friday 12 January 2007 11:09, Kirkwood, David A. wrote:
> I'm using RHEL4U4 and do not have autail. Where'd it come from? 

http://www.redhat.com/archives/linux-audit/2006-October/msg00035.html

> Also, the doc I have does not metion the -rwxa option for watches. 

That was a typo. It should have been -p rwxa. It should be in auditctl man 
page.

> Separate question. With the watches I have enabled, I never am able to
> tie a user to an access violation. How do I do that?

It should be done automatically. The auid is the field that you would look at. 
We've configured the pam settings for sshd,login,gdm, cron,vsftpd,remote to 
include the pam_loginuid.so module. This is needed for it to work. Unless you 
changed them, it should be setup at installation.

-Steve

RE: Audit config for NISPOM req's

[Kirkwood, David A.]

I have reset the watch line to be

	=w /etc/passwd -p rwxa

Then, as a normal user I execute cat > /etc/passwd

And get a permission denied

Then when I execute aureport -w --failed, the auid field shows up as -1
as it does for every watch list. Am I missing something?

Thanks,

David A. Kirkwood
SAIC

david.a.kirkwood@saic.com
kirkwoodd@saic.com

Phone: (727) 502-8310
Fax:   (727) 822-7776

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Friday, January 12, 2007 11:39 AM
To: linux-audit@redhat.com
Cc: Kirkwood, David A.
Subject: Re: Audit config for NISPOM req's

On Friday 12 January 2007 11:09, Kirkwood, David A. wrote:
> I'm using RHEL4U4 and do not have autail. Where'd it come from? 

http://www.redhat.com/archives/linux-audit/2006-October/msg00035.html

> Also, the doc I have does not metion the -rwxa option for watches. 

That was a typo. It should have been -p rwxa. It should be in auditctl
man 
page.

> Separate question. With the watches I have enabled, I never am able to
> tie a user to an access violation. How do I do that?

It should be done automatically. The auid is the field that you would
look at. 
We've configured the pam settings for sshd,login,gdm, cron,vsftpd,remote
to 
include the pam_loginuid.so module. This is needed for it to work.
Unless you 
changed them, it should be setup at installation.

-Steve

Re: Audit config for NISPOM req's

[Steve Grubb]

On Friday 12 January 2007 13:45, Kirkwood, David A. wrote:
> Then when I execute aureport -w --failed, the auid field shows up as -1
> as it does for every watch list. Am I missing something?

Yes. 

#cd /etc/pam.d
#grep loginuid *

See if you have that in your pam stack. You should see something like this:

atd:session     required        pam_loginuid.so
crond:session    required   pam_loginuid.so
gdm:session    required    pam_loginuid.so
gdm-autologin:session    required    pam_loginuid.so
kcheckpass:session    required    pam_loginuid.so
kdm:session    required    pam_loginuid.so
kdm-np:session    required     pam_loginuid.so
kscreensaver:session    required    pam_loginuid.so
login:session    required     pam_loginuid.so
remote:session    required     pam_loginuid.so
sshd:session    required     pam_loginuid.so
vsftpd:session    required     pam_loginuid.so
xdm:session    required pam_loginuid.so

-Steve

RE: Audit config for NISPOM req's

[Kirkwood, David A.]

Steve,

My pam.d directory shows:

atd:session     required        pam_loginuid.so
crond:session    required   pam_loginuid.so
gdm:session    required    pam_loginuid.so
gdm-autologin:session    required    pam_loginuid.so
kcheckpass:session    required    pam_loginuid.so
kdm:session    required    pam_loginuid.so
kdm-np:session    required     pam_loginuid.so
login:session    required     pam_loginuid.so
remote:session    required     pam_loginuid.so
sshd:session    required     pam_loginuid.so
wbem:session    required     pam_loginuid.so
xdm:session    required pam_loginuid.so


I added
 xcreensaver session required pam_loginuid.so
but it had no effect.

Is there anything else I missed?

Thanks,

Dave



-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Friday, January 12, 2007 2:50 PM
To: Kirkwood, David A.
Cc: linux-audit@redhat.com
Subject: Re: Audit config for NISPOM req's

On Friday 12 January 2007 13:45, Kirkwood, David A. wrote:
> Then when I execute aureport -w --failed, the auid field shows up as
-1
> as it does for every watch list. Am I missing something?

Yes. 

#cd /etc/pam.d
#grep loginuid *

See if you have that in your pam stack. You should see something like
this:

atd:session     required        pam_loginuid.so
crond:session    required   pam_loginuid.so
gdm:session    required    pam_loginuid.so
gdm-autologin:session    required    pam_loginuid.so
kcheckpass:session    required    pam_loginuid.so
kdm:session    required    pam_loginuid.so
kdm-np:session    required     pam_loginuid.so
kscreensaver:session    required    pam_loginuid.so
login:session    required     pam_loginuid.so
remote:session    required     pam_loginuid.so
sshd:session    required     pam_loginuid.so
vsftpd:session    required     pam_loginuid.so
xdm:session    required pam_loginuid.so

-Steve

Re: Audit config for NISPOM req's

[Steve Grubb]

On Tuesday 16 January 2007 10:51, Kirkwood, David A. wrote:
> My pam.d directory shows:

This all looks correct now.

> I added
>  xcreensaver session required pam_loginuid.so
> but it had no effect.

I wouldn't. xscreensaver runs as a common user and does not have the 
capabilities needed to set the loginuid.

> Is there anything else I missed?

That should do it. The communication chain here is:

login->pam->kernel
kernel->auditd

You should get a kernel event when you do this as root:

echo 500 > /proc/self/loginuid
ausearch -ts today -m LOGIN

time->Tue Jan 16 11:11:43 2007
type=LOGIN msg=audit(1168963903.962:1310): login pid=19065 uid=0 old auid=500 
new auid=500

If that's not working, you have a kernel problem. If its working, I'd look at 
pam/login.

-Steve