All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mr Dash Four <mr.dash.four@googlemail.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: excluding auditd events
Date: Thu, 26 May 2011 14:16:59 +0100	[thread overview]
Message-ID: <4DDE52CB.70103@googlemail.com> (raw)
In-Reply-To: <201105260802.21606.sgrubb@redhat.com>


> 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).

  parent reply	other threads:[~2011-05-26 13:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-26  0:22 excluding auditd events Mr Dash Four
     [not found] ` <201105260802.21606.sgrubb@redhat.com>
2011-05-26 13:16   ` Mr Dash Four [this message]
2011-05-26 13:50     ` Steve Grubb
2011-05-26 14:07       ` Mr Dash Four
2011-05-26 14:16         ` Steve Grubb
2011-05-26 14:23           ` Mr Dash Four
2011-05-26 14:33             ` Steve Grubb
2011-05-26 15:22               ` Mr Dash Four
2011-05-26 15:51                 ` LC Bruzenak
2011-05-26 16:10                   ` Mr Dash Four
2011-06-01 12:54           ` Mr Dash Four
2011-06-01 14:08             ` LC Bruzenak
2011-06-01 14:47               ` Mr Dash Four

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DDE52CB.70103@googlemail.com \
    --to=mr.dash.four@googlemail.com \
    --cc=linux-audit@redhat.com \
    --cc=sgrubb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.