Re: print capability for audit-viewer?
by Miloslav Trmac
----- "LC Bruzenak" <lenny(a)magitekltd.com> wrote:
> Is there any plan to add printing capability to the audit-viewer?
Not currently; you can export any tab to HTML[1] and use a web browser (or perhaps (lynx -dump | lpr)) to print it. Is that an acceptable solution for you?
Mirek
[1] I have just noticed that "list" exports don't work, and a fix will be available in the next release.
Mirek
14 years, 9 months
audit-viewer performance
by LC Bruzenak
I don't know how much the audit-viewer tool is used by folks with
substantial amounts of data, but my experience is that it is nearly
unusable for our system. I appreciate that it does a lot really well,
however it takes minutes to load our data on startup. It seems more
filter tabs hurt the performance as well.
The only purpose of this particular machine is to collect/process
audit/prelude data.
Only prelude and audit-related processes are being run on this one.
It is an HP DL380 with 2 quad-core processors, 12GB RAM and an
internal RAID running on F10.
As it is now, I daily move the audit data from the /var/log/audit
directory or there is no chance that the audit-viewer will complete
its load. Sometimes it will never recover and we have to kill and
restart it. The amount of data is around 1.5GB on the directory we are
currently loading and it appears to take about 5 minutes (give or
take) for the viewer to load the data and be usable.
Once loaded, a big filter effort will take maybe a minute or so to
yield results.
While the data is loading, there is no feedback and of course
uncertainty about whether it is going to return with any data always
sets in after a minute or two.
What is the plan for this tool? As I said, I think it is very nice
feature-wise in general but in practice it isn't living up to
expectations.
I can try to help but will take a while to get python-proficient. Or
is the trouble in the parse library?
I do not have scientific data yet, but recently I loaded one 100MB
audit file from the store. It took around 3 minute to load. Then I
changed the source and that one took longer. When it was finally
loaded it, the process size was over 2GB.
I can run some better tests and try to get some data if it is helpful.
Are there ways I can try to exercise the parse library outside the GUI
on these same files which might help me know what to look for? Or any
other ideas I can try?
Thanks,
LCB.
--
LC (Lenny) Bruzenak
14 years, 9 months
Compile Error
by 陈洁丹
Hello ,Everyone
I changed to use audit-1.7.17
while compiling ,I have some problem , Here is the error message
zos-remote-plugin.c:39:18: error: lber.h: No such file or directory
In file included from zos-remote-log.h:27,
from zos-remote-plugin.c:42:
zos-remote-ldap.h:283: error: expected specifier-qualifier-list before
'LDAP'
zos-remote-ldap.h:309: error: expected declaration specifiers or '...'
before 'BerElement'
Do I need to install ldap-devel.
when I tried to install , I have other problem such as dependency and
confict.
It's really messy....
Do I really need to install ldap-devel to continue compiling?
Thanks again
Jeedan
-----------------------------
陈洁丹 北京邮电大学软件学院
地 址： 北京邮电大学学二D12寝室
邮 编： 100876
Email: jeedan.chen(a)gmail.com
---------------------------------
14 years, 9 months
Compile Error
by 陈洁丹
Hello, everyboby.
while I'm compiling the soucecode of audit-2.0.1 under opensuse 11.0
I come across some error.
Here it's the message
In file included from gen_tables.c:76:
msg_typetab.h:103: error: 'AUDIT_BPRM_FCAPS' undeclared here (not in a
function)
msg_typetab.h:104: error: 'AUDIT_CAPSET' undeclared here (not in a function)
I search the Internet , but there is no solution.
Do I need to add other library? which one?
Hoping for your help.Thanks
14 years, 9 months
Interface between the plugin and auditdispacher
by 陈洁丹
Hello,everyone.
I want to write some plugin to do something , but I still do not have a
clear view of the interface between the plugin and dispacher.
Can anyone tell me how the event is passed to the specific plugin.
For example, if anyone read the /ect/passwd file, the plugin will record the
event in another file.
Maybe the problem is that I do not konw how the event is passed.
I hope someone could show me the flow of how the the event is dealed since
it's happened.
I'm now working it alone.Hoping for your help.
Thanks very much.
Jeedan
-----------------------------
陈洁丹 北京邮电大学软件学院
地 址： 北京邮电大学学二D12寝室
邮 编： 100876
Email: jeedan.chen(a)gmail.com
---------------------------------
14 years, 9 months
Limiting Audit Logs For Specific Directories & Specific Error Codes
by Wyllie, Aaron
Hi. I have a few basic questions.
First, we have a particular piece of software that generates a lot of log entries for file deletes (successful & unsuccessful). I'd like to limit what is actually captured by excluding that directory.
I'm thinking that I could add: -F dir!=/var/opt/xxx/xxx
Would that prevent logging from anything recursively from that directory and below or do I need to set rules to specifically exclude for each file (which I may do anyways)? Is there a different/better means for doing this?
The second question is events resulting from running 'ls -al' as a normal user 'su -' to root. This is generating a failed syscall error for getxattr with an error code of 61 (no data available). I'm assuming that this is because no extended attributes were set but, regardless, I'd like to avoid this.
I have the following rules that I think may be logging this but I'm not sure:
-a entry,always -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -k SYS_attribute
-a entry,always -F arch=b32 -S creat -S open -S openat -S truncate -S ftruncate
Would adding the following prevent these events from being logged or do I need to create a new rule(?): -F exit!=-61
Lastly, is there any benefit associated with ordering the rules in audit.rules, i.e., are they applied in the order they are read?
Thanks and let me know if need to provide additional information.
Aaron
________________________________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
14 years, 9 months
Re: Auditing TCP connections
by Steve Grubb
On Tuesday 08 December 2009 11:21:14 pm Data Lineage wrote:
> Is my understanding correct that the Linux Audit framework currently
> only logs the remote endpoint of TCP connections?
It records what is passed to the connect syscall or what accept is seeing.
> That is, when a connect() call occurs, only the remote IP and port are
> logged, not the local ones?
That is probably correct. I don't recall seeing duplicate network records
> If so, would it be possible to add the local end point into the audit
> trail?
I'm pretty sure it could be patched to provide that if its not. I think we
might want a new record type or some way of distinguishing which record is
local and remote.
I have been reading through the new OSPP from NIAP and it calls out for
selective audit based on network address, too. So, it would kind of fit with
what will be required going forward.
So...were you planning to send a patch or is this a request for us to write
one?
-Steve
14 years, 9 months
audit-1.7.17 released
by Steve Grubb
Hi,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit. It will also be in F-11 testing
soon. The ChangeLog is:
- Add tcp_max_per_addr option in auditd.conf to limit concurrent connections
- Make alpha processor support optional
- Rearrange shutdown of auditd to allow DAEMON_END event more time
These fixes are backported from the 2.x source code. Please refer to the 2.0.4
release notes for explanations.
Please let me know if you run across any problems with this release.
-Steve
14 years, 9 months
audit-2.0.4 released
by Steve Grubb
Hi,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
soon. The ChangeLog is:
- Make alpha processor support optional
- Add support for the arm eabi processor
- add a compatible regexp processing capability to auparse (Miloslav Trmač)
- Fix regression in parsing user space originating records in aureport
- Add tcp_max_per_addr option in auditd.conf to limit concurrent connections
- Rearrange shutdown of auditd to allow DAEMON_END event more time
This release drops support for the alpha processor unless you re-add "--with-
alpha" to the ./configure line. This release also adds support for the arm eabi
processor when you add "--with-armeb" to the ./configure line. Please note that
the 2.6.32 kernel does not actually work for auditing on ARM systems.
Hopefully someone will write the 4-5 lines of code to make it work.
A new regexp processing capability was added to libauparse. And there were
several bug fixes. The first was that I noticed on 2.0.x systems that use of
authentication mechanisms was not showing up in aureport even though they were
in the logs. The problem was traced to not applying a patch that corrected
parsing with the slight format change in the 2.0.x series. A new config option
was added to auditd.conf to set the maximum number of concurrent system
connections. The default is 1 which should work for most installations. And
lastly, the shutdown sequence was altered slightly to give remote logged audit
events a little more time to get sent before the audit daemon starts
terminating child processes.
Please let me know if you run across any problems with this release.
-Steve
14 years, 9 months
