Linux-audit Digest, Vol 121, Issue 17
Ali Alavi
skmusavi at gmail.com
Thu Oct 23 06:54:17 UTC 2014
unsubscribe
On Tue, Oct 21, 2014 at 7:30 PM, <linux-audit-request at redhat.com> wrote:
> Send Linux-audit mailing list submissions to
> linux-audit at redhat.com
>
> 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
> linux-audit-request at redhat.com
>
> You can reach the person managing the list at
> linux-audit-owner at redhat.com
>
> 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 <pmoore at redhat.com>
> To: linux-audit at redhat.com, linux-kernel at vger.kernel.org,
> eparis at redhat.com
> Subject: [PATCH] audit: add Paul Moore to the MAINTAINERS entry
> Message-ID: <20141020162328.1159.33576.stgit at 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 <pmoore at redhat.com>
> ---
> 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 <paul at paul-moore.com>
> M: Eric Paris <eparis at redhat.com>
> -L: linux-audit at redhat.com (subscribers-only)
> +L: linux-audit at redhat.com (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 <sgrubb at redhat.com>
> To: Richard Guy Briggs <rgb at redhat.com>
> Cc: linux-audit at redhat.com, linux-kernel at vger.kernel.org
> Subject: Re: [PATCH V5 0/5] audit by executable name
> Message-ID: <2527124.XNMpLdSfeq at 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 <eparis at redhat.com>
> To: Steve Grubb <sgrubb at redhat.com>
> Cc: Richard Guy Briggs <rgb at redhat.com>, linux-audit at redhat.com,
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH V5 0/5] audit by executable name
> Message-ID: <1413845247.30946.49.camel at 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 <pmoore at redhat.com>
> To: Eric Paris <eparis at redhat.com>, Steve Grubb <sgrubb at redhat.com>,
> Richard Guy Briggs <rgb at redhat.com>
> Cc: linux-audit at redhat.com, linux-kernel at vger.kernel.org
> Subject: Re: [PATCH V5 0/5] audit by executable name
> Message-ID: <2652562.S2IH3gqS0u at 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 <sgrubb at redhat.com>
> To: Paul Moore <pmoore at redhat.com>
> Cc: Richard Guy Briggs <rgb at redhat.com>, linux-audit at redhat.com,
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH V5 0/5] audit by executable name
> Message-ID: <4185398.VpQETdPFDe at 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 <sgrubb at redhat.com>
> To: linux-audit at redhat.com
> Cc: Richard Guy Briggs <rgb at redhat.com>, linux-kernel at vger.kernel.org
> Subject: Re: [PATCH V5 0/5] audit by executable name
> Message-ID: <13863680.WTabxyvHIP at 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
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>
> End of Linux-audit Digest, Vol 121, Issue 17
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20141023/5de6d8db/attachment.htm>
More information about the Linux-audit
mailing list