unsubscribe On Tue, Oct 21, 2014 at 7:30 PM, <[email protected]> wrote:
> Send Linux-audit mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/linux-audit > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Linux-audit digest..." > > > Today's Topics: > > 1. [PATCH] audit: add Paul Moore to the MAINTAINERS entry > (Paul Moore) > 2. Re: [PATCH V5 0/5] audit by executable name (Steve Grubb) > 3. Re: [PATCH V5 0/5] audit by executable name (Eric Paris) > 4. Re: [PATCH V5 0/5] audit by executable name (Paul Moore) > 5. Re: [PATCH V5 0/5] audit by executable name (Steve Grubb) > 6. Re: [PATCH V5 0/5] audit by executable name (Steve Grubb) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Oct 2014 12:23:28 -0400 > From: Paul Moore <[email protected]> > To: [email protected], [email protected], > [email protected] > Subject: [PATCH] audit: add Paul Moore to the MAINTAINERS entry > Message-ID: <20141020162328.1159.33576.stgit@localhost> > Content-Type: text/plain; charset="utf-8" > > After a long stint maintaining the audit tree, Eric asked me to step > in and handle the day-to-day management of the audit tree. We should > also update the linux-audit mailing list entry to better reflect > current usage. > > Signed-off-by: Paul Moore <[email protected]> > --- > MAINTAINERS | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index c2066f4..86c24fd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1689,10 +1689,11 @@ S: Supported > F: drivers/scsi/esas2r > > AUDIT SUBSYSTEM > +M: Paul Moore <[email protected]> > M: Eric Paris <[email protected]> > -L: [email protected] (subscribers-only) > +L: [email protected] (moderated for non-subscribers) > W: http://people.redhat.com/sgrubb/audit/ > -T: git git://git.infradead.org/users/eparis/audit.git > +T: git git://git.infradead.org/users/pcmoore/audit > S: Maintained > F: include/linux/audit.h > F: include/uapi/linux/audit.h > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Oct 2014 16:25:13 -0400 > From: Steve Grubb <[email protected]> > To: Richard Guy Briggs <[email protected]> > Cc: [email protected], [email protected] > Subject: Re: [PATCH V5 0/5] audit by executable name > Message-ID: <2527124.XNMpLdSfeq@x2> > Content-Type: text/plain; charset="us-ascii" > > On Thursday, October 02, 2014 11:06:51 PM Richard Guy Briggs wrote: > > This is a part of Peter Moody, my and Eric Paris' work to implement > > audit by executable name. > > Does this patch set define an AUDIT_VERSION_SOMETHING and then set > AUDIT_VERSION_LATEST to it? If not, I need one to tell if the kernel > supports > it when issuing commands. Also, if its conceivable that kernels may pick > and > choose what features could be backported to a curated kernel, should > AUDIT_VERSION_ be a number that is incremented or a bit mask? > > -Steve > > > > Please see the accompanying userspace patch: > > https://www.redhat.com/archives/linux-audit/2014-May/msg00019.html > > The userspace interface is not expected to change appreciably unless > > something important has been overlooked. Setting and deleting rules > works > > as expected. > > > > If the path does not exist at rule creation time, it will be re-evaluated > > every time there is a change to the parent directory at which point the > > change in device and inode will be noted. > > > > > > Here's a sample run: > > > > # /usr/local/sbin/auditctl -a always,exit -F dir=/tmp -F exe=/bin/touch > -F > > key=touch_tmp # /usr/local/sbin/ausearch --start recent -k touch_tmp > > time->Mon Jun 30 14:15:06 2014 > > type=CONFIG_CHANGE msg=audit(1404152106.683:149): auid=0 ses=1 > > subj=unconfined_u :unconfined_r:auditctl_t:s0-s0:c0.c1023 op="add_rule" > > key="touch_tmp" list=4 res =1 > > > > # /usr/local/sbin/auditctl -l > > -a always,exit -S all -F dir=/tmp -F exe=/bin/touch -F key=touch_tmp > > > > # touch /tmp/test > > > > # /usr/local/sbin/ausearch --start recent -k touch_tmp > > time->Wed Jul 2 12:18:47 2014 > > type=UNKNOWN[1327] msg=audit(1404317927.319:132): > > proctitle=746F756368002F746D702F74657374 type=PATH > > msg=audit(1404317927.319:132): item=1 name="/tmp/test" inode=25997 > > dev=00:20 mode=0100644 ouid=0 ogid=0 rdev=00:00 > > obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE type=PATH > > msg=audit(1404317927.319:132): item=0 name="/tmp/" inode=11144 dev=00:20 > > mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0 > > nametype=PARENT type=CWD msg=audit(1404317927.319:132): cwd="/root" > > type=SYSCALL msg=audit(1404317927.319:132): arch=c000003e syscall=2 > > success=yes exit=3 a0=7ffffa403dd5 a1=941 a2=1b6 a3=34b65b2c6c items=2 > > ppid=4321 pid=6436 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > > fsgid=0 tty=ttyS0 ses=1 comm="touch" exe="/usr/bin/touch" > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > key="touch_tmp" > > > > > > Revision history: > > v5: Revert patch "Let audit_free_rule() take care of calling > > audit_remove_mark()." since it caused a group mark deadlock. > > > > v4: Re-order and squash down fixups > > Fix audit_dup_exe() to copy pathname string before calling > > audit_alloc_mark(). > > > > v3: Rationalize and rename some function names and clean up get/put and > free > > code. Rename several "watch" references to "mark". > > Rename audit_remove_rule() to audit_remove_mark_rule(). > > Let audit_free_rule() take care of calling audit_remove_mark(). > > Put audit_alloc_mark() arguments in same order as watch, tree and > inode. > > Move the access to the entry for audit_match_signal() to the beginning of > > the function in case the entry found is the same one passed in. This will > > enable it to be used by audit_remove_mark_rule(). > > https://www.redhat.com/archives/linux-audit/2014-July/msg00000.html > > > > v2: Misguided attempt to add in audit_exe similar to watches > > https://www.redhat.com/archives/linux-audit/2014-June/msg00066.html > > > > v1.5: eparis' switch to fsnotify > > https://www.redhat.com/archives/linux-audit/2014-May/msg00046.html > > https://www.redhat.com/archives/linux-audit/2014-May/msg00066.html > > > > v1: Change to path interface instead of inode > > https://www.redhat.com/archives/linux-audit/2014-May/msg00017.html > > > > v0: Peter Moodie's original patches > > > https://www.redhat.com/archives/linux-audit/2012-August/msg00033.html > > > > > > Next step: > > Get full-path notify working. > > > > > > Eric Paris (3): > > audit: implement audit by executable > > audit: clean simple fsnotify implementation > > audit: convert audit_exe to audit_fsnotify > > > > Richard Guy Briggs (2): > > audit: avoid double copying the audit_exe path string > > Revert "fixup! audit: clean simple fsnotify implementation" > > > > include/linux/audit.h | 1 + > > include/uapi/linux/audit.h | 2 + > > kernel/Makefile | 2 +- > > kernel/audit.h | 39 +++++++ > > kernel/audit_exe.c | 49 +++++++++ > > kernel/audit_fsnotify.c | 237 > > ++++++++++++++++++++++++++++++++++++++++++++ kernel/auditfilter.c | > > 52 +++++++++- > > kernel/auditsc.c | 16 +++ > > 8 files changed, 395 insertions(+), 3 deletions(-) > > create mode 100644 kernel/audit_exe.c > > create mode 100644 kernel/audit_fsnotify.c > > > > ------------------------------ > > Message: 3 > Date: Mon, 20 Oct 2014 18:47:27 -0400 > From: Eric Paris <[email protected]> > To: Steve Grubb <[email protected]> > Cc: Richard Guy Briggs <[email protected]>, [email protected], > [email protected] > Subject: Re: [PATCH V5 0/5] audit by executable name > Message-ID: <1413845247.30946.49.camel@localhost> > Content-Type: text/plain; charset="UTF-8" > > On Mon, 2014-10-20 at 16:25 -0400, Steve Grubb wrote: > > On Thursday, October 02, 2014 11:06:51 PM Richard Guy Briggs wrote: > > > This is a part of Peter Moody, my and Eric Paris' work to implement > > > audit by executable name. > > > > Does this patch set define an AUDIT_VERSION_SOMETHING and then set > > AUDIT_VERSION_LATEST to it? If not, I need one to tell if the kernel > supports > > it when issuing commands. Also, if its conceivable that kernels may pick > and > > choose what features could be backported to a curated kernel, should > > AUDIT_VERSION_ be a number that is incremented or a bit mask? > > Right now the value is 2. So this is your last hope if you want to make > it a bitmask. I'll leave that up to paul/richard to (over) design. > > Support for by EXEC should probably be noted somehow. Especially since > audit_netlink_ok() sucks and return EINVAL for unknown message types. We > wouldn't need the bump to version if that returned EOPNOTSUP and > userspace could actually tell what was going on... > > > > > -Steve > > > > > > > Please see the accompanying userspace patch: > > > https://www.redhat.com/archives/linux-audit/2014-May/msg00019.html > > > The userspace interface is not expected to change appreciably unless > > > something important has been overlooked. Setting and deleting rules > works > > > as expected. > > > > > > If the path does not exist at rule creation time, it will be > re-evaluated > > > every time there is a change to the parent directory at which point the > > > change in device and inode will be noted. > > > > > > > > > Here's a sample run: > > > > > > # /usr/local/sbin/auditctl -a always,exit -F dir=/tmp -F > exe=/bin/touch -F > > > key=touch_tmp # /usr/local/sbin/ausearch --start recent -k touch_tmp > > > time->Mon Jun 30 14:15:06 2014 > > > type=CONFIG_CHANGE msg=audit(1404152106.683:149): auid=0 ses=1 > > > subj=unconfined_u :unconfined_r:auditctl_t:s0-s0:c0.c1023 op="add_rule" > > > key="touch_tmp" list=4 res =1 > > > > > > # /usr/local/sbin/auditctl -l > > > -a always,exit -S all -F dir=/tmp -F exe=/bin/touch -F key=touch_tmp > > > > > > # touch /tmp/test > > > > > > # /usr/local/sbin/ausearch --start recent -k touch_tmp > > > time->Wed Jul 2 12:18:47 2014 > > > type=UNKNOWN[1327] msg=audit(1404317927.319:132): > > > proctitle=746F756368002F746D702F74657374 type=PATH > > > msg=audit(1404317927.319:132): item=1 name="/tmp/test" inode=25997 > > > dev=00:20 mode=0100644 ouid=0 ogid=0 rdev=00:00 > > > obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE type=PATH > > > msg=audit(1404317927.319:132): item=0 name="/tmp/" inode=11144 > dev=00:20 > > > mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0 > > > nametype=PARENT type=CWD msg=audit(1404317927.319:132): cwd="/root" > > > type=SYSCALL msg=audit(1404317927.319:132): arch=c000003e syscall=2 > > > success=yes exit=3 a0=7ffffa403dd5 a1=941 a2=1b6 a3=34b65b2c6c items=2 > > > ppid=4321 pid=6436 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 > > > fsgid=0 tty=ttyS0 ses=1 comm="touch" exe="/usr/bin/touch" > > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > key="touch_tmp" > > > > > > > > > Revision history: > > > v5: Revert patch "Let audit_free_rule() take care of calling > > > audit_remove_mark()." since it caused a group mark deadlock. > > > > > > v4: Re-order and squash down fixups > > > Fix audit_dup_exe() to copy pathname string before calling > > > audit_alloc_mark(). > > > > > > v3: Rationalize and rename some function names and clean up get/put > and free > > > code. Rename several "watch" references to "mark". > > > Rename audit_remove_rule() to audit_remove_mark_rule(). > > > Let audit_free_rule() take care of calling audit_remove_mark(). > > > Put audit_alloc_mark() arguments in same order as watch, tree and > inode. > > > Move the access to the entry for audit_match_signal() to the beginning > of > > > the function in case the entry found is the same one passed in. This > will > > > enable it to be used by audit_remove_mark_rule(). > > > > https://www.redhat.com/archives/linux-audit/2014-July/msg00000.html > > > > > > v2: Misguided attempt to add in audit_exe similar to watches > > > > https://www.redhat.com/archives/linux-audit/2014-June/msg00066.html > > > > > > v1.5: eparis' switch to fsnotify > > > https://www.redhat.com/archives/linux-audit/2014-May/msg00046.html > > > https://www.redhat.com/archives/linux-audit/2014-May/msg00066.html > > > > > > v1: Change to path interface instead of inode > > > https://www.redhat.com/archives/linux-audit/2014-May/msg00017.html > > > > > > v0: Peter Moodie's original patches > > > > https://www.redhat.com/archives/linux-audit/2012-August/msg00033.html > > > > > > > > > Next step: > > > Get full-path notify working. > > > > > > > > > Eric Paris (3): > > > audit: implement audit by executable > > > audit: clean simple fsnotify implementation > > > audit: convert audit_exe to audit_fsnotify > > > > > > Richard Guy Briggs (2): > > > audit: avoid double copying the audit_exe path string > > > Revert "fixup! audit: clean simple fsnotify implementation" > > > > > > include/linux/audit.h | 1 + > > > include/uapi/linux/audit.h | 2 + > > > kernel/Makefile | 2 +- > > > kernel/audit.h | 39 +++++++ > > > kernel/audit_exe.c | 49 +++++++++ > > > kernel/audit_fsnotify.c | 237 > > > ++++++++++++++++++++++++++++++++++++++++++++ kernel/auditfilter.c > | > > > 52 +++++++++- > > > kernel/auditsc.c | 16 +++ > > > 8 files changed, 395 insertions(+), 3 deletions(-) > > > create mode 100644 kernel/audit_exe.c > > > create mode 100644 kernel/audit_fsnotify.c > > > > > > > ------------------------------ > > Message: 4 > Date: Mon, 20 Oct 2014 19:02:33 -0400 > From: Paul Moore <[email protected]> > To: Eric Paris <[email protected]>, Steve Grubb <[email protected]>, > Richard Guy Briggs <[email protected]> > Cc: [email protected], [email protected] > Subject: Re: [PATCH V5 0/5] audit by executable name > Message-ID: <2652562.S2IH3gqS0u@sifl> > Content-Type: text/plain; charset="us-ascii" > > On Monday, October 20, 2014 06:47:27 PM Eric Paris wrote: > > On Mon, 2014-10-20 at 16:25 -0400, Steve Grubb wrote: > > > On Thursday, October 02, 2014 11:06:51 PM Richard Guy Briggs wrote: > > > > This is a part of Peter Moody, my and Eric Paris' work to implement > > > > audit by executable name. > > > > > > Does this patch set define an AUDIT_VERSION_SOMETHING and then set > > > AUDIT_VERSION_LATEST to it? If not, I need one to tell if the kernel > > > supports it when issuing commands. Also, if its conceivable that > kernels > > > may pick and choose what features could be backported to a curated > > > kernel, should AUDIT_VERSION_ be a number that is incremented or a bit > > > mask? > > > > Right now the value is 2. So this is your last hope if you want to make > > it a bitmask. I'll leave that up to paul/richard to (over) design. > > Audit is nothing if not over-designed. I want to make sure we're > consistent > with the previous design methodologies ;) > > I've been thinking about this for about the past half-hour while I've been > going through some other mail and I'm not really enthused about using the > version number to encode capabilities. What sort of problems would we > have if > we introduced a new audit netlink command to query the kernel for audit > capabilities? > > -- > paul moore > security and virtualization @ redhat > > > > ------------------------------ > > Message: 5 > Date: Mon, 20 Oct 2014 19:33:39 -0400 > From: Steve Grubb <[email protected]> > To: Paul Moore <[email protected]> > Cc: Richard Guy Briggs <[email protected]>, [email protected], > [email protected] > Subject: Re: [PATCH V5 0/5] audit by executable name > Message-ID: <4185398.VpQETdPFDe@x2> > Content-Type: text/plain; charset="us-ascii" > > On Monday, October 20, 2014 07:02:33 PM Paul Moore wrote: > > On Monday, October 20, 2014 06:47:27 PM Eric Paris wrote: > > > On Mon, 2014-10-20 at 16:25 -0400, Steve Grubb wrote: > > > > On Thursday, October 02, 2014 11:06:51 PM Richard Guy Briggs wrote: > > > > > This is a part of Peter Moody, my and Eric Paris' work to implement > > > > > audit by executable name. > > > > > > > > Does this patch set define an AUDIT_VERSION_SOMETHING and then set > > > > AUDIT_VERSION_LATEST to it? If not, I need one to tell if the kernel > > > > supports it when issuing commands. Also, if its conceivable that > kernels > > > > may pick and choose what features could be backported to a curated > > > > kernel, should AUDIT_VERSION_ be a number that is incremented or a > bit > > > > mask? > > > > > > Right now the value is 2. So this is your last hope if you want to make > > > it a bitmask. I'll leave that up to paul/richard to (over) design. > > > > Audit is nothing if not over-designed. I want to make sure we're > consistent > > with the previous design methodologies ;) > > > > I've been thinking about this for about the past half-hour while I've > been > > going through some other mail and I'm not really enthused about using the > > version number to encode capabilities. What sort of problems would we > have > > if we introduced a new audit netlink command to query the kernel for > audit > > capabilities? > > I thought that is what we were getting in this patch: > https://www.redhat.com/archives/linux-audit/2014-January/msg00054.html > > As I understood it, I send an AUDIT_GET command on netlink and then look in > status.version to see what we have. I really think that in the mainline > kernel, there will be a steady increment of capabilities. However, for > distributions, they may want to pick and choose which capabilities to > backport > to their shipping kernel. Meaning in practice, a bitmap may be better to > allow > cherry picking capabilities and user space being able to make informed > decisions. > > I really don't mind if this is done by a new netlink command (but if we do, > what happens to status.version?) or if we just keep going with > status.version. > Just tell me which it is. > > -Steve > > > > ------------------------------ > > Message: 6 > Date: Mon, 20 Oct 2014 19:49:12 -0400 > From: Steve Grubb <[email protected]> > To: [email protected] > Cc: Richard Guy Briggs <[email protected]>, [email protected] > Subject: Re: [PATCH V5 0/5] audit by executable name > Message-ID: <13863680.WTabxyvHIP@x2> > Content-Type: text/plain; charset="us-ascii" > > On Monday, October 20, 2014 07:33:39 PM Steve Grubb wrote: > > On Monday, October 20, 2014 07:02:33 PM Paul Moore wrote: > > > On Monday, October 20, 2014 06:47:27 PM Eric Paris wrote: > > > > On Mon, 2014-10-20 at 16:25 -0400, Steve Grubb wrote: > > > > > On Thursday, October 02, 2014 11:06:51 PM Richard Guy Briggs wrote: > > > > > > This is a part of Peter Moody, my and Eric Paris' work to > implement > > > > > > audit by executable name. > > > > > > > > > > Does this patch set define an AUDIT_VERSION_SOMETHING and then set > > > > > AUDIT_VERSION_LATEST to it? If not, I need one to tell if the > kernel > > > > > supports it when issuing commands. Also, if its conceivable that > > > > > kernels > > > > > may pick and choose what features could be backported to a curated > > > > > kernel, should AUDIT_VERSION_ be a number that is incremented or a > bit > > > > > mask? > > > > > > > > Right now the value is 2. So this is your last hope if you want to > make > > > > it a bitmask. I'll leave that up to paul/richard to (over) design. > > > > > > Audit is nothing if not over-designed. I want to make sure we're > > > consistent with the previous design methodologies ;) > > > > > > I've been thinking about this for about the past half-hour while I've > been > > > going through some other mail and I'm not really enthused about using > the > > > version number to encode capabilities. What sort of problems would we > > > have > > > if we introduced a new audit netlink command to query the kernel for > audit > > > capabilities? > > > > I thought that is what we were getting in this patch: > > https://www.redhat.com/archives/linux-audit/2014-January/msg00054.html > > > > As I understood it, I send an AUDIT_GET command on netlink and then look > in > > status.version to see what we have. I really think that in the mainline > > kernel, there will be a steady increment of capabilities. However, for > > distributions, they may want to pick and choose which capabilities to > > backport to their shipping kernel. Meaning in practice, a bitmap may be > > better to allow cherry picking capabilities and user space being able to > > make informed decisions. > > > > I really don't mind if this is done by a new netlink command (but if we > do, > > what happens to status.version?) or if we just keep going with > > status.version. Just tell me which it is. > > Further to the point of status.version, its declared as a __u32. So if it > were > a bit map, we can have 32 different features userspace needs to make > support > decisions on. I have a feeling that will last many years because I really > can't see audit gaining too many more capabilities. > > -Steve > > > > ------------------------------ > > -- > Linux-audit mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/linux-audit > > End of Linux-audit Digest, Vol 121, Issue 17 > ******************************************** >
-- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
