Possible regression
by 4javier
I'm noticing exactly the same problem mentioned into this old message
http://osdir.com/ml/linux.redhat.security.audit/2006-07/msg00036.html
Workaround consisting into watching the whole directory containing the file
works too. I've found that into 2006 a patch was submitted to solve the
issue
http://www.mail-archive.com/linux-audit@redhat.com/msg00476.html
Is this a recent regression, or is there something I don't know?
Arch Linux
audit 2.1.1
kernel 2.6.38.7
i686 architecture
Thanks in advance
13 years, 7 months
- 2
- 1
Re: excluding auditd events
by Mr Dash Four
> 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).
13 years, 7 months
- 3
- 11