That would be "user,never". The audit daemon does no filtering. Its in a race with the
kernel to put events to disk before the kernel's backlog overflows.
Yeah, that's it, sorry. Is this backlog configurable (maybe in the same
way tcp/udp buffers are via the sysctl daemon)?
The user filter can filter on: pid, uid, gid, auid, and any part of the subject's
selinux label. The only thing not being filtered on that is available is the event's
record type. There are no other attributes available that can be filtered on.
You mean the message type? If so, filtering by selinux label and message
type is sufficient, at least for my immediate needs.
It is protected by file permissions. You must be root to write to the file. If you want
to gpg armor your files when you archive them, its possible to script that.
Actually, I was thinking more of having a hash against each record
(horizontally) and, maybe a separate hash over the current tuple of
time:audit count (vertically).
It was just an idea and is similar to what I have implemented in my
database-based log system (using PostgreSQL) - a token (via smartcard)
is taken when the logging starts (at boot up using dracut - I have
designed a module for this too) and this token is then used to create a
hash when each log/record is inserted into the system and inserts that
has as part of the record itself - that prevents tampering with a single
record, while a separate hash is kept for a single column across the
entire table (timestamp and transaction id in my case) - that prevents
tampering entire logs (i.e. adding/deleting entries).
But we've
always taken the position that if someone obtains root privileges, tampering with the
logs is the last thing you need to worry about.
I am sure someone said the same thing before SELinux was invented and
implemented in Fedora. In SELinux even if you are root you are still
restricted by the domain you operate in and by the policies in existence
for that particular domain. My view has always been that you can never
be too careful and this adds another level of security - an additional
barrier for "hackers" to have to break, if you like.
Finally, another feature which I am badly missing - the ability to see
audit files loaded remotely by the audit-viewer (audit logs located on
network shares for example) - this is currently missing and the audit
viewer bluntly refuses to load audit file if this file is remotely based
and not on the local file system. Is something planned in that respect to
enable this?
No idea.
It is a restriction in audit-viewer - at least in the version I am using
(stock FC13).
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
