6:02 p.m.
Hello,
The next version of the audit daemon has been released. You can get it from:
http://people.redhat.com/sgrubb/audit/ or in rawhide tomorrow morning. This
release fixes a bug in setting the loginuid and adds a new feature.
There is now a configuration option num_files for auditd.conf. This lets you
specify how many logs you want the program to allow when it rotates them due
to their size. If you set it to 5, you will get audit.log to audit.log.4 in
the /var/logs directory.
The new release should be in rawhide tomorrow morning. Let me know if there
are any problems.
-Steve Grubb
12:22 p.m.
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
linux-audit-bounces(a)redhat.com wrote on 03/09/2005 06:02:53 PM:
Hello,
The next version of the audit daemon has been released. You can get it
from:
http://people.redhat.com/sgrubb/audit/ or in rawhide tomorrow
morning.
This
release fixes a bug in setting the loginuid and adds a new feature.
There is now a configuration option num_files for auditd.conf. This lets
you
specify how many logs you want the program to allow when it rotates
them
due
to their size. If you set it to 5, you will get audit.log to
audit.log.4
in
the /var/logs directory.
Steve,
Can you please tell us how this option works with the xxx_space_left
options.
What happens when the last audit.log.x is full do you start on audit.log
again.
Thanks,
Mounir
The new release should be in rawhide tomorrow morning. Let me know if
there
are any problems.
-Steve Grubb
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
12:29 p.m.
On Thursday 10 March 2005 13:22, Mounir Bsaibes wrote:
Can you please tell us how this option works with the xxx_space_left
options.
They are separate checks. One check is for the size of the file, the other
check is for the amount of space left. They do not interfere with each other.
What happens when the last audit.log.x is full do you start on
audit.log
again.
I always write to whatever the name was given by the admin. I follow the same
algorithm as logrotate so that its familiar.
Log rotation is critical for the casual user so that they can set aside a
certain amount of diskspace and know audit isn't going to fill their drive.
-Steve Grubb
12:49 p.m.
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
linux-audit-bounces(a)redhat.com wrote on 03/10/2005 12:29:53 PM:
On Thursday 10 March 2005 13:22, Mounir Bsaibes wrote:
> Can you please tell us how this option works with the xxx_space_left
> options.
They are separate checks. One check is for the size of the file, the
other
check is for the amount of space left. They do not interfere with
each
other.
> What happens when the last audit.log.x is full do you start on
audit.log
> again.
I always write to whatever the name was given by the admin. I followthe
same
algorithm as logrotate so that its familiar.
Log rotation is critical for the casual user so that they can set aside
a
certain amount of diskspace and know audit isn't going to fill
their
drive.
Thanks Steve,
Now, the question: Is there any additional requirement to satisfy CAPP
in this situation? Or, this is totally acceptable; since the file
size can be set large enough.
Mounir
-Steve Grubb
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
12:57 p.m.
On Thursday 10 March 2005 13:49, Mounir Bsaibes wrote:
Now, the question: Is there any additional requirement to satisfy
CAPP
in this situation?
I can't answer this.
Or, this is totally acceptable; since the file size can be set large
enough.
Or, maybe they do not need to put ROTATE in the max_log_file_action parameter.
IGNORE should let the file grow until another limit/action prevents it.
-Steve
1:05 p.m.
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
linux-audit-bounces(a)redhat.com wrote on 03/10/2005 12:57:07 PM:
On Thursday 10 March 2005 13:49, Mounir Bsaibes wrote:
> Now, the question: Is there any additional requirement to satisfy CAPP
> in this situation?
I can't answer this.
> Or, this is totally acceptable; since the file size can be set large
enough.
Or, maybe they do not need to put ROTATE in the max_log_file_action
parameter.
IGNORE should let the file grow until another limit/action prevents it.
I believe this is acceptable if we can prove it works correctly.
It would be nice if this is spelled out in the man page. So, the
admin would know how/what to configure.
Mounir
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
2:55 p.m.
Hi Steve,
On this version of audit-0.6.7, I noticed when you first start auditd, if
you do
"service auditd start"
"auditctl -s"
It returns: "AUDIT_STATUS: enabled=1 flag=1 pid=6695 rate_limit=0
backlog_limit=64 lost=0 backlog=0"
But I'm not sure that enabled really is 1. Because if you start adding
rules and executing syscalls, the audit records go to /var/log/messages
instead of /var/log/audit.log.
But if you do:
"service auditd start"
"auditctl -s" (returns "AUDIT_STATUS: enabled=1 flag=1 pid=6723
rate_limit=0 backlog_limit=64 lost=0 backlog=0"
"auditctl -e 1" (returns "AUDIT_STATUS: enabled=1 flag=1 pid=6723
rate_limit=0 backlog_limit=64 lost=0 backlog=0")
Add rules and execute syscalls. Then the audit records will go to
/var/log/audit.log.
This also occurs on audit-0.6.6 but not on audit-0.6.4. With audit-0.6.4,
audit records will go to /var/log/audit.log without having to set "auditctl
-e 1" after doing the restart.
Note, I observed this behavior with most , but not all of the syscalls I
tried. 'chmod' is one example. But 'open' seems to always go to
/var/log/audit.log, regardless of whether or not I did the 'auditctl -e 1'.
-debbie
Steve Grubb
<sgrubb(a)redhat.co
m> To
Sent by: Linux Audit Discussion
linux-audit-bounc <linux-audit(a)redhat.com>
es(a)redhat.com cc
Subject
03/09/2005 06:02 audit-0.6.7 released
PM
Please respond to
Linux Audit
Discussion
Hello,
The next version of the audit daemon has been released. You can get it
from:
http://people.redhat.com/sgrubb/audit/ or in rawhide tomorrow morning.
This
release fixes a bug in setting the loginuid and adds a new feature.
There is now a configuration option num_files for auditd.conf. This lets
you
specify how many logs you want the program to allow when it rotates them
due
to their size. If you set it to 5, you will get audit.log to audit.log.4 in
the /var/logs directory.
The new release should be in rawhide tomorrow morning. Let me know if there
are any problems.
-Steve Grubb
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
4:02 p.m.
On Thursday 10 March 2005 15:55, Debora Velarde wrote:
But I'm not sure that enabled really is 1. Because if you start
adding
rules and executing syscalls, the audit records go to /var/log/messages
instead of /var/log/audit.log.
This sounds like the kernel bug that I was chasing over the weekend. What
kernel are you using? I'm using the latest from the yum repo (I think .11)
and don't see this problem.
If enabled is 1 & the pid matches the audit daemon's, the audit daemon had
better get the packets or there's a kernel problem. The kernel decides the
packet disposition between auditd & syslog.
-Steve
4:12 p.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
On Thursday 10 March 2005 15:55, Debora Velarde wrote:
> But I'm not sure that enabled really is 1. Because if you start adding
> rules and executing syscalls, the audit records go to /var/log/messages
> instead of /var/log/audit.log.
This sounds like the kernel bug that I was chasing over the weekend. What
kernel are you using? I'm using the latest from the yum repo (I think .11)
and don't see this problem.
I think I missed that one, but it's fixed?
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
4:26 p.m.
On Thursday 10 March 2005 17:12, Chris Wright wrote:
I think I missed that one, but it's fixed?
That depends on the kernel you're using, your platform, and how you compile
auditd. As of audit-0.6.6, it uses the glibc-kernheaders which has a
sanitized copy of audit.h. The filesystem logging patch inserted a flag for
fs_enable in the middle of the audit_status structure instead of the end. The
user space tools & kernel, therefore, had a different idea about the layout
of any received status packets. Status packets change any of the attributes
listed in the auditctl -s command.
We should probably add a warning comment at the top of the kernel's
audit_status struct to only add data elements to the end of the structure or
you risk breaking user space.
It should be fixed in the .11 kernel David posted to the yum repo Tuesday.
However, there may be another kernel bug she's found that I haven't seen if
she's running David's latest kernel.
Hope this helps...
-Steve
4:52 p.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
On Thursday 10 March 2005 17:12, Chris Wright wrote:
> I think I missed that one, but it's fixed?
That depends on the kernel you're using, your platform, and how you compile
auditd. As of audit-0.6.6, it uses the glibc-kernheaders which has a
sanitized copy of audit.h. The filesystem logging patch inserted a flag for
fs_enable in the middle of the audit_status structure instead of the end. The
user space tools & kernel, therefore, had a different idea about the layout
of any received status packets. Status packets change any of the attributes
listed in the auditctl -s command.
OK, I did see that, thanks.
We should probably add a warning comment at the top of the
kernel's
audit_status struct to only add data elements to the end of the structure or
you risk breaking user space.
Yeah, the headers need some general santitation.
It should be fixed in the .11 kernel David posted to the yum repo
Tuesday.
However, there may be another kernel bug she's found that I haven't seen if
she's running David's latest kernel.
Hope this helps...
Yes it does.
cheers,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
5:57 p.m.
I am using kernel: 2.6.11-1.1176_FC4.
Steve Grubb
<sgrubb(a)redhat.co
m> To
Sent by: Linux Audit Discussion
linux-audit-bounc <linux-audit(a)redhat.com>
es(a)redhat.com cc
Subject
03/10/2005 04:02 Re: audit-0.6.7 released
PM
Please respond to
Linux Audit
Discussion
On Thursday 10 March 2005 15:55, Debora Velarde wrote:
But I'm not sure that enabled really is 1. Because if you start
adding
rules and executing syscalls, the audit records go to /var/log/messages
instead of /var/log/audit.log.
This sounds like the kernel bug that I was chasing over the weekend. What
kernel are you using? I'm using the latest from the yum repo (I think .11)
and don't see this problem.
If enabled is 1 & the pid matches the audit daemon's, the audit daemon had
better get the packets or there's a kernel problem. The kernel decides the
packet disposition between auditd & syslog.
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
8:24 a.m.
On Thursday 10 March 2005 18:57, Debora Velarde wrote:
I am using kernel: 2.6.11-1.1176_FC4.
That kernel is compiled with gcc4 which is *very* experimental. I stopped
updating from rawhide around March 1 because of all the gcc4 rebuilding. That
kernel is also missing a few audit patches that David has in the .11 kernel.
So, unless you are adding the patches yourself and building the kernel, you
aren't testing to what we are.
Please try the .11 kernel from David' yum repo and see if that makes a
difference: ftp://ftp.uk.linux.org/pub/people/dwmw2/audit/ If your whole
machine is full of rawhide packages after March 1, lots of luck. :)
-Steve
3:15 p.m.
Please try the .11 kernel from David' yum repo and see if that
makes a
difference: ftp://ftp.uk.linux.org/pub/people/dwmw2/audit/ If your whole
machine is full of rawhide packages after March 1, lots of luck. :)
I installed kernel-2.6.9-5.0.3.EL.audit.11 on my system. Now it looks like
the records are showing up in /var/log/audit.log.
Thanks!
debbie
9:42 a.m.
On Thu, 2005-03-10 at 17:57 -0600, Debora Velarde wrote:
<html><body><p>I am using kernel:
2.6.11-1.1176_FC4.<br><img
width=3D"16" height=3D"16"
src=3D"cid:1__=3D08BBE553DF101C8F8f9e8a=
93df938(a)us.ibm.com" border=3D"0" alt=3D"Inactive hide details for
Steve= Grubb &lt;sgrubb(a)redhat.com&gt;">Steve Grubb
&lt;sgrubb(a)redhat.com&gt;=<br><br><br>
As Steve said, please try to test the same RHEL4-based kernel which
includes all the patches. There is now an audit.12 kernel in the yum
repository which contains Tim's auditfs #6 patch.
Please avoid sending HTML mail, and try to include only what is
absolutely necessary when you need to quote parts of the mail to which
you're replying -- thanks.
--
dwmw2
11:50 a.m.
David are you going to also place audit-0.6.8 and pam-.... in the ym
repository as well?
Mounir
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
linux-audit-bounces(a)redhat.com wrote on 03/16/2005 09:42:21 AM:
On Thu, 2005-03-10 at 17:57 -0600, Debora Velarde wrote:
> <html><body><p>I am using kernel:
2.6.11-1.1176_FC4.<br><img
> width=3D"16" height=3D"16"
src=3D"cid:1__=3D08BBE553DF101C8F8f9e8a=
> 93df938(a)us.ibm.com" border=3D"0" alt=3D"Inactive hide details
for
> Steve= Grubb &lt;sgrubb(a)redhat.com&gt;">Steve Grubb
> &lt;sgrubb(a)redhat.com&gt;=<br><br><br>
As Steve said, please try to test the same RHEL4-based kernel which
includes all the patches. There is now an audit.12 kernel in the yum
repository which contains Tim's auditfs #6 patch.
Please avoid sending HTML mail, and try to include only what is
absolutely necessary when you need to quote parts of the mail to which
you're replying -- thanks.
--
dwmw2
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
7221
days inactive
7227
days old
linux-audit@lists.linux-audit.osci.io
17 comments
5 participants
participants (5)
-
Chris Wright -
David Woodhouse -
Debora Velarde -
Mounir Bsaibes -
Steve Grubb