From: Eric Paris <eparis@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>, linux-audit@redhat.com
Subject: Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
Date: Wed, 22 Oct 2014 11:12:05 -0400 [thread overview]
Message-ID: <1413990725.30946.84.camel@localhost> (raw)
In-Reply-To: <1978142.LNMGsIevqD@x2>
On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
> 1) For the *at syscalls, can we get the path from the FD being passed to be
> able to reconstruct what is being accessed?
You might sometimes be able to get A path. But every time anyone ever
says THE path they've already lost. There is no THE path. There might
be NO path. Every single request with THE path is always doomed to
fail.
> 2) For the adjtimex syscall, how do we only get events where the time is set
> rather than the clock being status'ed?
Now you want to match on stuff from 3) it's certainly possible... Not
necessarily going to be super easy, especially the rule definitions...
> 3) How do we select events to record based on values in structures being
> passed? (This is related to #2)
Same way you get the fd in a mmap record. AUX records.
> 4) How do we select events when a setuid/setgid/setcapabilities file is
> executed when you do not have a file list? IOW, extend perms to allow
> selection.
> 5) Can tty be added to AUDIT_LOGIN event?
> 6) How do we handle user names that are not in /etc/passwd? IOW, someone
> logins in as root through some network protocol, like spice, and perform admin
> actions with no local account.
> 7) Does audit of /proc work? If not can it? (Security parameters can be set
> through it.)
watches do not work. watches can not work. watches are inode based.
all of /proc has one inode. I'm sure it's not completely unsolvable to
'watch' in proc, but it'll be a whole new thing JUST for proc...
> 8) Can we audit NFS based files? Samba?
Audit how? Audit changes made by THIS system? yes.
Audit changes made by the server or another client? no.
technologically impossible.
> 9) Can we get events for a watched file even when a user's permissions do not
> allow full path resolution?
No.
> 10) Can we optionally get events when a file is actually modified rather than
> when opened with intent to modify?
Possibly sometimes... It can't be completely reliable. Think about
mmap(). fsnotify_modify() tries to do something like this but it is
not reliable...
> 11) Why is the kernel dumping events into syslog instead of waiting until the
> queue is full when auditd shuts down for a restart?
Interesting thought...
> 13) Is audit by process name ready to go?
That's up to you/paul/richard.
> I really think some of these issues are more important than re-ordering event
> fields. There is also the issue of having some test suite for robustness.
I disagree completely :)
next prev parent reply other threads:[~2014-10-22 15:12 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 18:23 [RFC][PATCH] audit: log join and part events to the read-only multicast log socket Richard Guy Briggs
2014-10-07 19:03 ` Eric Paris
2014-10-07 19:39 ` Richard Guy Briggs
2014-10-07 22:06 ` Paul Moore
2014-10-11 15:42 ` Steve Grubb
2014-10-11 20:00 ` Paul Moore
2014-10-21 16:41 ` Richard Guy Briggs
2014-10-21 19:56 ` Steve Grubb
2014-10-21 21:08 ` Richard Guy Briggs
2014-10-21 21:40 ` Steve Grubb
2014-10-29 20:23 ` Richard Guy Briggs
2014-10-21 22:30 ` Eric Paris
2014-10-21 23:14 ` Paul Moore
2014-10-22 1:18 ` Richard Guy Briggs
2014-10-22 14:30 ` Steve Grubb
2014-10-21 22:30 ` Paul Moore
2014-10-22 1:24 ` Richard Guy Briggs
2014-10-22 13:34 ` Paul Moore
2014-10-29 21:09 ` Richard Guy Briggs
2014-10-22 14:34 ` Steve Grubb
2014-10-22 14:25 ` Steve Grubb
2014-10-22 14:30 ` Eric Paris
2014-10-22 14:36 ` Steve Grubb
2014-10-22 15:08 ` Eric Paris
2014-10-22 15:12 ` Eric Paris [this message]
2014-10-22 15:51 ` LC Bruzenak
2014-10-22 16:24 ` Steve Grubb
2014-10-22 18:18 ` Eric Paris
2014-10-22 19:36 ` LC Bruzenak
2014-10-22 20:00 ` Steve Grubb
2014-10-22 15:28 ` Paul Moore
2014-10-22 17:56 ` Steve Grubb
2014-10-22 20:06 ` Paul Moore
2014-10-22 20:34 ` LC Bruzenak
2014-10-22 20:44 ` Paul Moore
2014-10-22 21:11 ` LC Bruzenak
2014-10-22 21:29 ` Paul Moore
2014-10-23 14:19 ` LC Bruzenak
2014-10-23 19:08 ` Paul Moore
2014-10-22 20:39 ` Steve Grubb
2014-10-22 21:00 ` Paul Moore
2014-10-22 21:18 ` Steve Grubb
2014-10-23 19:15 ` Paul Moore
2014-10-30 14:55 ` Richard Guy Briggs
2014-10-30 14:48 ` Typo in AUDIT_FEATURE_CHANGE events [was: Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket] Richard Guy Briggs
2014-10-30 15:10 ` Steve Grubb
2014-10-30 15:23 ` Richard Guy Briggs
2014-10-29 21:38 ` [RFC][PATCH] audit: log join and part events to the read-only multicast log socket Richard Guy Briggs
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=1413990725.30946.84.camel@localhost \
--to=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=rgb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox