7:38 a.m.
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
8:19 a.m.
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
9:08 a.m.
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(a)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
9:33 a.m.
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
10:22 a.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(a)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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
10:25 a.m.
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
1:18 p.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
1:42 p.m.
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
10:09 a.m.
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(a)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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
10:38 a.m.
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
12:45 p.m.
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(a)saic.com
kirkwoodd(a)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(a)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
1:49 p.m.
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
9:51 a.m.
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(a)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
10:15 a.m.
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
6549
days inactive
6574
days old
linux-audit@lists.linux-audit.osci.io
13 comments
4 participants
participants (4)
-
Curtas, Anthony R. -
Kirkwood, David A. -
Steve Grubb -
Wieprecht, Karen M.