Send Linux-audit mailing list submissions to
linux-audit@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@redhat.com
You can reach the person managing the list at
linux-audit-owner@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@redhat.com>
To: linux-audit@redhat.com, linux-kernel@vger.kernel.org,
eparis@redhat.com
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 <pmoore@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@paul-moore.com>
M: Eric Paris <eparis@redhat.com>
-L: linux-audit@redhat.com (subscribers-only)
+L: linux-audit@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@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: linux-audit@redhat.com, linux-kernel@vger.kernel.org
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 <eparis@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>, linux-audit@redhat.com,
linux-kernel@vger.kernel.org
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 <pmoore@redhat.com>
To: Eric Paris <eparis@redhat.com>, Steve Grubb <sgrubb@redhat.com>,
Richard Guy Briggs <rgb@redhat.com>
Cc: linux-audit@redhat.com, linux-kernel@vger.kernel.org
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 <sgrubb@redhat.com>
To: Paul Moore <pmoore@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>, linux-audit@redhat.com,
linux-kernel@vger.kernel.org
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 <sgrubb@redhat.com>
To: linux-audit@redhat.com
Cc: Richard Guy Briggs <rgb@redhat.com>, linux-kernel@vger.kernel.org
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
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
End of Linux-audit Digest, Vol 121, Issue 17
********************************************