* [PATCH 5/5] Fix header detection when cross compiling
From: Clayton Shotwell @ 2015-05-28 13:04 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1432818249-17692-1-git-send-email-clayton.shotwell@rockwellcollins.com>
During the build, there is a check to see if MS_DIRSYNC is defined in
mount.h. This check is used in gen_tables.c to see if linux/fs.h needs
to be included. When cross compiling on a system that does not have the
MS_DIRSYNC defined in mount.h, a compile failure is generated. To
prevent this issue, do not check for MS_DIRSYNC in the configure and
simply check to see if MS_DIRSYNC is defined before included linux/fs.h.
Signed-off-by: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
---
configure.ac | 1 -
lib/gen_tables.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index c14ec80..e63684b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -63,7 +63,6 @@ AC_C_INLINE
AC_CHECK_SIZEOF([unsigned int])
AC_CHECK_SIZEOF([unsigned long])
AM_PROG_CC_C_O
-AC_CHECK_DECLS([MS_DIRSYNC], [], [], [[#include <sys/mount.h>]])
AC_CHECK_DECLS([AUDIT_FEATURE_VERSION], [], [], [[#include <linux/audit.h>]])
AC_CHECK_DECLS([AUDIT_VERSION_BACKLOG_WAIT_TIME], [], [], [[#include <linux/audit.h>]])
AC_CHECK_DECLS([ADDR_NO_RANDOMIZE],,, [#include <sys/personality.h>])
diff --git a/lib/gen_tables.c b/lib/gen_tables.c
index 8606a39..9f25b50 100644
--- a/lib/gen_tables.c
+++ b/lib/gen_tables.c
@@ -33,7 +33,7 @@
#include <sys/stat.h>
#include <sys/personality.h>
#include <sys/mount.h>
-#if !HAVE_DECL_MS_DIRSYNC
+#ifndef MS_DIRSYNC
#include <linux/fs.h>
#endif
#include "gen_tables.h"
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] Make zos-remote plugin optional
From: Clayton Shotwell @ 2015-05-28 13:04 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1432818249-17692-1-git-send-email-clayton.shotwell@rockwellcollins.com>
The zos-remote plugin is meant to use LDAP authentication to verify a
remote audit user. Add the ability to disable the plugin if the feature
is not desired.
Signed-off-by: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
---
audisp/plugins/Makefile.am | 6 ++++--
configure.ac | 10 ++++++++++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/audisp/plugins/Makefile.am b/audisp/plugins/Makefile.am
index b0fa60a..2cba14b 100644
--- a/audisp/plugins/Makefile.am
+++ b/audisp/plugins/Makefile.am
@@ -22,8 +22,10 @@
CONFIG_CLEAN_FILES = *.loT *.rej *.orig
-SUBDIRS = builtins zos-remote remote
-#SUBDIRS = builtins zos-remote
+SUBDIRS = builtins remote
+if ENABLE_ZOS_REMOTE
+SUBDIRS += zos-remote
+endif
if HAVE_PRELUDE
SUBDIRS += prelude
endif
diff --git a/configure.ac b/configure.ac
index f29fa41..2e84b07 100644
--- a/configure.ac
+++ b/configure.ac
@@ -155,6 +155,16 @@ fi
AM_CONDITIONAL(ENABLE_LISTENER, test "x$enable_listener" != "xno")
AC_MSG_RESULT($enable_listener)
+#audisp zos-remote plugin
+AC_MSG_CHECKING(whether to include audisp ZOS remote plugin)
+AC_ARG_ENABLE(zos-remote,
+ [AS_HELP_STRING([--disable-zos-remote],
+ [Disable audisp ZOS remote plugin])],
+ enable_zos_remote=$enableval,
+ enable_zos_remote=yes)
+AM_CONDITIONAL(ENABLE_ZOS_REMOTE, test "x$enable_zos_remote" != "xno")
+AC_MSG_RESULT($enable_zos_remote)
+
#gssapi
AC_ARG_ENABLE(gssapi_krb5,
[AS_HELP_STRING([--enable-gssapi-krb5],[Enable GSSAPI Kerberos 5 support @<:@default=no@:>@])],
--
1.9.1
^ permalink raw reply related
* re: [PATCH V5 0/5] audit by executable name
From: Peter Moody @ 2015-05-29 16:14 UTC (permalink / raw)
To: linux-audit; +Cc: rgb
Did this [1] land? I'm guessing no because the next pull request from
Eric Paris didn't include it and I don't see it referenced in any of
Paul's pull requests. Finally (most tellingly), I don't see anything
in Linus' tree.
Cheers,
peter
[1] https://www.redhat.com/archives/linux-audit/2014-October/msg00024.html
^ permalink raw reply
* Re: [PATCH V5 0/5] audit by executable name
From: Paul Moore @ 2015-05-29 16:26 UTC (permalink / raw)
To: Peter Moody; +Cc: rgb, linux-audit
In-Reply-To: <CADbMJx=nTjhcj+FzTk=d=m4J5i1y_T6inMiRUgG0JoT3uB4Tzw@mail.gmail.com>
On Fri, May 29, 2015 at 12:14 PM, Peter Moody <peter@hda3.com> wrote:
> Did this [1] land? I'm guessing no because the next pull request from
> Eric Paris didn't include it and I don't see it referenced in any of
> Paul's pull requests. Finally (most tellingly), I don't see anything
> in Linus' tree.
>
> Cheers,
> peter
>
> [1] https://www.redhat.com/archives/linux-audit/2014-October/msg00024.html
Nope, but Richard is working on it.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH V5 0/5] audit by executable name
From: Richard Guy Briggs @ 2015-05-29 16:28 UTC (permalink / raw)
To: Peter Moody; +Cc: linux-audit
In-Reply-To: <CADbMJx=nTjhcj+FzTk=d=m4J5i1y_T6inMiRUgG0JoT3uB4Tzw@mail.gmail.com>
On 15/05/29, Peter Moody wrote:
> Did this [1] land? I'm guessing no because the next pull request from
> Eric Paris didn't include it and I don't see it referenced in any of
> Paul's pull requests. Finally (most tellingly), I don't see anything
> in Linus' tree.
Why? Were your ears burning? ;-)
> peter
>
> [1] https://www.redhat.com/archives/linux-audit/2014-October/msg00024.html
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: [PATCH V5 0/5] audit by executable name
From: Peter Moody @ 2015-05-29 17:15 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit
In-Reply-To: <20150529162827.GA18893@madcap2.tricolour.ca>
On Fri, May 29, 2015 at 9:28 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 15/05/29, Peter Moody wrote:
>> Did this [1] land? I'm guessing no because the next pull request from
>> Eric Paris didn't include it and I don't see it referenced in any of
>> Paul's pull requests. Finally (most tellingly), I don't see anything
>> in Linus' tree.
>
> Why? Were your ears burning? ;-)
Hah, nope. I just find myself in the situation where having this
functionality would be very useful.
Cheers
>> peter
>>
>> [1] https://www.redhat.com/archives/linux-audit/2014-October/msg00024.html
>
> - RGB
>
> --
> Richard Guy Briggs <rbriggs@redhat.com>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: [PATCH] lsm: rename duplicate labels in LSM_AUDIT_DATA_TASK audit message type
From: Paul Moore @ 2015-05-29 19:15 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-security-module, linux-kernel, linux-audit, sgrubb, eparis,
jmorris
In-Reply-To: <096df9441c4492ab31851eba63fee4408872d06f.1429121009.git.rgb@redhat.com>
On Wednesday, April 15, 2015 02:08:25 PM Richard Guy Briggs wrote:
> The LSM_AUDIT_DATA_TASK pid= and comm= labels are duplicates of those at the
> start of this function with different values. Rename them to their object
> counterparts opid= and ocomm= to disambiguate.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> security/lsm_audit.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied, thanks.
> diff --git a/security/lsm_audit.c b/security/lsm_audit.c
> index b526ddc..3323144 100644
> --- a/security/lsm_audit.c
> +++ b/security/lsm_audit.c
> @@ -282,7 +282,7 @@ static void dump_common_audit_data(struct audit_buffer
> *ab, pid_t pid = task_pid_nr(tsk);
> if (pid) {
> char comm[sizeof(tsk->comm)];
> - audit_log_format(ab, " pid=%d comm=", pid);
> + audit_log_format(ab, " opid=%d ocomm=", pid);
> audit_log_untrustedstring(ab,
> memcpy(comm, tsk->comm, sizeof(comm)));
> }
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH] kernel:audit - Fix for typo in comment to function audit_log_link_denied().
From: Paul Moore @ 2015-05-29 19:20 UTC (permalink / raw)
To: Shailendra Verma; +Cc: Eric Paris, linux-audit, linux-kernel
In-Reply-To: <1432357827-4401-1-git-send-email-shailendra.capricorn@gmail.com>
On Saturday, May 23, 2015 10:40:27 AM Shailendra Verma wrote:
> Signed-off-by: Shailendra Verma <shailendra.capricorn@gmail.com>
> ---
> kernel/audit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 1c13e42..f9e6065 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1904,7 +1904,7 @@ EXPORT_SYMBOL(audit_log_task_info);
>
> /**
> * audit_log_link_denied - report a link restriction denial
> - * @operation: specific link opreation
> + * @operation: specific link operation
> * @link: the path that triggered the restriction
> */
> void audit_log_link_denied(const char *operation, struct path *link)
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH 1/1] Obsolete check is now removed.
From: Paul Moore @ 2015-05-29 20:15 UTC (permalink / raw)
To: Mikhail Klementyev; +Cc: rgb, linux-audit
In-Reply-To: <5565C971.8020001@riseup.net>
On Wednesday, May 27, 2015 04:41:05 PM Mikhail Klementyev wrote:
> From a2e33ce7c9b5ceff2a8b570b570ddd0023ce077f Mon Sep 17 00:00:00 2001
> From: Mikhail Klementyev<jollheef@riseup.net>
> Date: Mon, 25 May 2015 23:20:38 +0300
> Subject: [PATCH 1/1] Obsolete check is now removed.
>
> Signed-off-by: Mikhail Klementyev<jollheef@riseup.net>
> ---
> kernel/auditsc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Applied, but you are lucky I happened to be in a good mood and your patch was
small, normally I reject patches that arrive as HTML mail because they are a
major headache to apply.
Contributions are always welcome, but please read the information in the
Documentation/SubmittingPatches before submitting another patch.
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 9fb9d1c..ee09794 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -599,9 +599,7 @@ static int audit_filter_rules(struct task_struct *tsk,
> result = match_tree_refs(ctx, rule->tree);
> break;
> case AUDIT_LOGINUID:
> - result = 0;
> - if (ctx)
> - result = audit_uid_comparator(tsk->loginuid, f->op, f->uid);
> + result = audit_uid_comparator(tsk->loginuid, f->op, f->uid);
> break;
> case AUDIT_LOGINUID_SET:
> result = audit_comparator(audit_loginuid_set(tsk), f->op, f-
>val);
> --
> 2.0.5
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [PATCH] audit: Fix check of return value of strnlen_user()
From: Jan Kara @ 2015-06-02 15:08 UTC (permalink / raw)
To: linux-audit; +Cc: Jan Kara
strnlen_user() returns 0 when it hits fault, not -1. Fix the test in
audit_log_single_execve_arg(). Luckily this shouldn't ever happen unless
there's a kernel bug so it's mostly a cosmetic fix.
CC: Paul Moore <pmoore@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
---
kernel/auditsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 9fb9d1cb83ce..bb947ceeee4d 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1023,7 +1023,7 @@ static int audit_log_single_execve_arg(struct audit_context *context,
* for strings that are too long, we should not have created
* any.
*/
- if (unlikely((len == -1) || len > MAX_ARG_STRLEN - 1)) {
+ if (unlikely((len == 0) || len > MAX_ARG_STRLEN - 1)) {
WARN_ON(1);
send_sig(SIGKILL, current, 0);
return -1;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] audit: Fix check of return value of strnlen_user()
From: Paul Moore @ 2015-06-03 18:56 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-audit
In-Reply-To: <1433257709-1530-1-git-send-email-jack@suse.cz>
On Tuesday, June 02, 2015 05:08:29 PM Jan Kara wrote:
> strnlen_user() returns 0 when it hits fault, not -1. Fix the test in
> audit_log_single_execve_arg(). Luckily this shouldn't ever happen unless
> there's a kernel bug so it's mostly a cosmetic fix.
>
> CC: Paul Moore <pmoore@redhat.com>
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
> kernel/auditsc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 9fb9d1cb83ce..bb947ceeee4d 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1023,7 +1023,7 @@ static int audit_log_single_execve_arg(struct
> audit_context *context, * for strings that are too long, we should not have
> created
> * any.
> */
> - if (unlikely((len == -1) || len > MAX_ARG_STRLEN - 1)) {
> + if (unlikely((len == 0) || len > MAX_ARG_STRLEN - 1)) {
While we're at it, should we make it just "len > MAX_ARG_STRLEN" as well?
Reading the comments in include/uapi/linux/binfmts.h as well as
valid_arg_len() that seems to be the correct logic.
> WARN_ON(1);
> send_sig(SIGKILL, current, 0);
> return -1;
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] audit: Fix check of return value of strnlen_user()
From: Jan Kara @ 2015-06-04 7:36 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, Jan Kara
In-Reply-To: <1616713.xG362InQ3V@sifl>
On Wed 03-06-15 14:56:18, Paul Moore wrote:
> On Tuesday, June 02, 2015 05:08:29 PM Jan Kara wrote:
> > strnlen_user() returns 0 when it hits fault, not -1. Fix the test in
> > audit_log_single_execve_arg(). Luckily this shouldn't ever happen unless
> > there's a kernel bug so it's mostly a cosmetic fix.
> >
> > CC: Paul Moore <pmoore@redhat.com>
> > Signed-off-by: Jan Kara <jack@suse.cz>
> > ---
> > kernel/auditsc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 9fb9d1cb83ce..bb947ceeee4d 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -1023,7 +1023,7 @@ static int audit_log_single_execve_arg(struct
> > audit_context *context, * for strings that are too long, we should not have
> > created
> > * any.
> > */
> > - if (unlikely((len == -1) || len > MAX_ARG_STRLEN - 1)) {
> > + if (unlikely((len == 0) || len > MAX_ARG_STRLEN - 1)) {
>
> While we're at it, should we make it just "len > MAX_ARG_STRLEN" as well?
> Reading the comments in include/uapi/linux/binfmts.h as well as
> valid_arg_len() that seems to be the correct logic.
Umm, but audit_log_single_execve_arg() does decrement 1 from
strnlen_user() result before doing the comparison. So the current test
seems to match the one in valid_arg_len() exactly...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH] audit: Fix check of return value of strnlen_user()
From: Paul Moore @ 2015-06-04 13:18 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-audit
In-Reply-To: <20150604073637.GA5923@quack.suse.cz>
On Thu, Jun 4, 2015 at 3:36 AM, Jan Kara <jack@suse.cz> wrote:
> On Wed 03-06-15 14:56:18, Paul Moore wrote:
>> On Tuesday, June 02, 2015 05:08:29 PM Jan Kara wrote:
>> > strnlen_user() returns 0 when it hits fault, not -1. Fix the test in
>> > audit_log_single_execve_arg(). Luckily this shouldn't ever happen unless
>> > there's a kernel bug so it's mostly a cosmetic fix.
>> >
>> > CC: Paul Moore <pmoore@redhat.com>
>> > Signed-off-by: Jan Kara <jack@suse.cz>
>> > ---
>> > kernel/auditsc.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
>> > index 9fb9d1cb83ce..bb947ceeee4d 100644
>> > --- a/kernel/auditsc.c
>> > +++ b/kernel/auditsc.c
>> > @@ -1023,7 +1023,7 @@ static int audit_log_single_execve_arg(struct
>> > audit_context *context, * for strings that are too long, we should not have
>> > created
>> > * any.
>> > */
>> > - if (unlikely((len == -1) || len > MAX_ARG_STRLEN - 1)) {
>> > + if (unlikely((len == 0) || len > MAX_ARG_STRLEN - 1)) {
>>
>> While we're at it, should we make it just "len > MAX_ARG_STRLEN" as well?
>> Reading the comments in include/uapi/linux/binfmts.h as well as
>> valid_arg_len() that seems to be the correct logic.
>
> Umm, but audit_log_single_execve_arg() does decrement 1 from
> strnlen_user() result before doing the comparison. So the current test
> seems to match the one in valid_arg_len() exactly...
For reference (taken from fs/exec.c in Linus' tree just now):
static bool valid_arg_len(struct linux_binprm *bprm, long len)
{
return len <= MAX_ARG_STRLEN;
}
The valid_arg_len() returns true when the length is less than or equal
to MAX_ARG_STRLEN, implying that lengths greater than MAX_ARG_STRLEN
are invalid. The existing test in audit_log_single_execve_arg()
treats lengths greater than (MAX_ARG_STRLEN-1) as invalid.
These two tests do not look the same to me.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] audit: Fix check of return value of strnlen_user()
From: Jan Kara @ 2015-06-04 21:32 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit, Jan Kara
In-Reply-To: <CAHC9VhS-hFQ+RpmJdwDhM1eei3--oXo0acxpSXtKXN9VHUWm=A@mail.gmail.com>
On Thu 04-06-15 09:18:49, Paul Moore wrote:
> On Thu, Jun 4, 2015 at 3:36 AM, Jan Kara <jack@suse.cz> wrote:
> > On Wed 03-06-15 14:56:18, Paul Moore wrote:
> >> On Tuesday, June 02, 2015 05:08:29 PM Jan Kara wrote:
> >> > strnlen_user() returns 0 when it hits fault, not -1. Fix the test in
> >> > audit_log_single_execve_arg(). Luckily this shouldn't ever happen unless
> >> > there's a kernel bug so it's mostly a cosmetic fix.
> >> >
> >> > CC: Paul Moore <pmoore@redhat.com>
> >> > Signed-off-by: Jan Kara <jack@suse.cz>
> >> > ---
> >> > kernel/auditsc.c | 2 +-
> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> >> > index 9fb9d1cb83ce..bb947ceeee4d 100644
> >> > --- a/kernel/auditsc.c
> >> > +++ b/kernel/auditsc.c
> >> > @@ -1023,7 +1023,7 @@ static int audit_log_single_execve_arg(struct
> >> > audit_context *context, * for strings that are too long, we should not have
> >> > created
> >> > * any.
> >> > */
> >> > - if (unlikely((len == -1) || len > MAX_ARG_STRLEN - 1)) {
> >> > + if (unlikely((len == 0) || len > MAX_ARG_STRLEN - 1)) {
> >>
> >> While we're at it, should we make it just "len > MAX_ARG_STRLEN" as well?
> >> Reading the comments in include/uapi/linux/binfmts.h as well as
> >> valid_arg_len() that seems to be the correct logic.
> >
> > Umm, but audit_log_single_execve_arg() does decrement 1 from
> > strnlen_user() result before doing the comparison. So the current test
> > seems to match the one in valid_arg_len() exactly...
>
> For reference (taken from fs/exec.c in Linus' tree just now):
>
> static bool valid_arg_len(struct linux_binprm *bprm, long len)
> {
> return len <= MAX_ARG_STRLEN;
> }
>
> The valid_arg_len() returns true when the length is less than or equal
> to MAX_ARG_STRLEN, implying that lengths greater than MAX_ARG_STRLEN
> are invalid. The existing test in audit_log_single_execve_arg()
> treats lengths greater than (MAX_ARG_STRLEN-1) as invalid.
But the 'len' passed to valid_arg_len() is the return value of
strnlen_user() and that one returns lenght *including* the terminating
'\0'. So in fact valid_arg_len() tests whether the argument length is <=
(MAX_ARG_STRLEN-1). Hmm?
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH] audit: Fix check of return value of strnlen_user()
From: Paul Moore @ 2015-06-04 21:48 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-audit
In-Reply-To: <20150604213204.GA24919@quack.suse.cz>
On Thu, Jun 4, 2015 at 5:32 PM, Jan Kara <jack@suse.cz> wrote:
> On Thu 04-06-15 09:18:49, Paul Moore wrote:
>> On Thu, Jun 4, 2015 at 3:36 AM, Jan Kara <jack@suse.cz> wrote:
>> > On Wed 03-06-15 14:56:18, Paul Moore wrote:
>> >> On Tuesday, June 02, 2015 05:08:29 PM Jan Kara wrote:
>> >> > strnlen_user() returns 0 when it hits fault, not -1. Fix the test in
>> >> > audit_log_single_execve_arg(). Luckily this shouldn't ever happen unless
>> >> > there's a kernel bug so it's mostly a cosmetic fix.
>> >> >
>> >> > CC: Paul Moore <pmoore@redhat.com>
>> >> > Signed-off-by: Jan Kara <jack@suse.cz>
>> >> > ---
>> >> > kernel/auditsc.c | 2 +-
>> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
>> >> > index 9fb9d1cb83ce..bb947ceeee4d 100644
>> >> > --- a/kernel/auditsc.c
>> >> > +++ b/kernel/auditsc.c
>> >> > @@ -1023,7 +1023,7 @@ static int audit_log_single_execve_arg(struct
>> >> > audit_context *context, * for strings that are too long, we should not have
>> >> > created
>> >> > * any.
>> >> > */
>> >> > - if (unlikely((len == -1) || len > MAX_ARG_STRLEN - 1)) {
>> >> > + if (unlikely((len == 0) || len > MAX_ARG_STRLEN - 1)) {
>> >>
>> >> While we're at it, should we make it just "len > MAX_ARG_STRLEN" as well?
>> >> Reading the comments in include/uapi/linux/binfmts.h as well as
>> >> valid_arg_len() that seems to be the correct logic.
>> >
>> > Umm, but audit_log_single_execve_arg() does decrement 1 from
>> > strnlen_user() result before doing the comparison. So the current test
>> > seems to match the one in valid_arg_len() exactly...
>>
>> For reference (taken from fs/exec.c in Linus' tree just now):
>>
>> static bool valid_arg_len(struct linux_binprm *bprm, long len)
>> {
>> return len <= MAX_ARG_STRLEN;
>> }
>>
>> The valid_arg_len() returns true when the length is less than or equal
>> to MAX_ARG_STRLEN, implying that lengths greater than MAX_ARG_STRLEN
>> are invalid. The existing test in audit_log_single_execve_arg()
>> treats lengths greater than (MAX_ARG_STRLEN-1) as invalid.
> But the 'len' passed to valid_arg_len() is the return value of
> strnlen_user() and that one returns lenght *including* the terminating
> '\0'. So in fact valid_arg_len() tests whether the argument length is <=
> (MAX_ARG_STRLEN-1). Hmm?
I must have spaced on the fact that audit subtracts the NULL from the
output of strnlen_user() when it calls it earlier in the function.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Audit rules and practices for docker on RHEL7
From: Maupertuis Philippe @ 2015-06-05 15:17 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 1576 bytes --]
Hi list,
Can somebody point me to resources for starting using docker with best auditing practices.
I am looking for guidance both on audit rules and on the exploitation of the log.
We run PCI DSS systems and need to use docker with the same level of trace.
Any help would be greatly appreciated.
Philippe
________________________________
Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
[-- Attachment #1.2: Type: text/html, Size: 3917 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH] Fix a typo in comment of parse_avc()
From: Masatake YAMATO @ 2015-06-11 13:16 UTC (permalink / raw)
To: linux-audit
Index: src/ausearch-parse.c
===================================================================
--- src/ausearch-parse.c (revision 1083)
+++ src/ausearch-parse.c (working copy)
@@ -1652,7 +1652,7 @@
/* FIXME: If they are in permissive mode or hit an auditallow, there can
- * be more that 1 avc in the same syscall. For now, we pickup just the first.
+ * be more than 1 avc in the same syscall. For now, we pickup just the first.
*/
static int parse_avc(const lnode *n, search_items *s)
{
^ permalink raw reply
* Re: [PATCH] audit: Fix check of return value of strnlen_user()
From: Paul Moore @ 2015-06-11 19:58 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-audit
In-Reply-To: <1433257709-1530-1-git-send-email-jack@suse.cz>
On Tuesday, June 02, 2015 05:08:29 PM Jan Kara wrote:
> strnlen_user() returns 0 when it hits fault, not -1. Fix the test in
> audit_log_single_execve_arg(). Luckily this shouldn't ever happen unless
> there's a kernel bug so it's mostly a cosmetic fix.
>
> CC: Paul Moore <pmoore@redhat.com>
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
> kernel/auditsc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Merged to audit#next, thanks for your patience.
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 9fb9d1cb83ce..bb947ceeee4d 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1023,7 +1023,7 @@ static int audit_log_single_execve_arg(struct
> audit_context *context, * for strings that are too long, we should not have
> created
> * any.
> */
> - if (unlikely((len == -1) || len > MAX_ARG_STRLEN - 1)) {
> + if (unlikely((len == 0) || len > MAX_ARG_STRLEN - 1)) {
> WARN_ON(1);
> send_sig(SIGKILL, current, 0);
> return -1;
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [GIT PULL] Audit patches for 4.2
From: Paul Moore @ 2015-06-26 20:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-audit, linux-kernel
Hi Linus,
Four small audit patches for v4.2, all bug fixes. Only 10 lines of change
this time so very unremarkable, the patch subject lines pretty much tell the
whole story. Please pull.
Thanks,
-Paul
---
The following changes since commit 39a8804455fb23f09157341d3ba7db6d7ae6ee76:
Linux 4.0 (2015-04-12 15:12:50 -0700)
are available in the git repository at:
git://git.infradead.org/users/pcmoore/audit upstream
for you to fetch changes up to 0b08c5e59441d08ab4b5e72afefd5cd98a4d83df:
audit: Fix check of return value of strnlen_user()
(2015-06-11 15:49:54 -0400)
----------------------------------------------------------------
Jan Kara (1):
audit: Fix check of return value of strnlen_user()
Mikhail Klementyev (1):
audit: obsolete audit_context check is removed in audit_filter_rules()
Richard Guy Briggs (1):
lsm: rename duplicate labels in LSM_AUDIT_DATA_TASK audit message type
Shailendra Verma (1):
audit: fix for typo in comment to function audit_log_link_denied()
kernel/audit.c | 2 +-
kernel/auditsc.c | 6 ++----
security/lsm_audit.c | 2 +-
3 files changed, 4 insertions(+), 6 deletions(-)
--
paul moore
security @ redhat
^ permalink raw reply
* ausearch with message types does not return what I think it would return. (0 matches when adding a user)
From: Alarie, Maxime @ 2015-06-30 15:12 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 592 bytes --]
Good day,
I am new with auditd, and got some issues..
For example, When I add or delete a user, I cannot see the entry with ausearch -m ADD_USER, it returns 0 match, BUT its logging it under USER_AUTH. If I do a ausearch -x adduser, ill thee se event audit.log with the EXECVE Type:
# ausearch -x useradd | grep titi
type=EXECVE msg=audit(1435677075.900:49410): argc=2 a0="useradd" a1="titi"
I also tried to find a full description of all message types returned by ausearch -m but could not find any.. Any help on this would be appreciated as well.
Many thanks.
[-- Attachment #1.2: Type: text/html, Size: 3205 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: ausearch with message types does not return what I think it would return. (0 matches when adding a user)
From: Steve Grubb @ 2015-06-30 15:22 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <23396023F719ED41888885C3B22D602F0123D1@WPEXCH2010MR21.bur.hydro.qc.ca>
On Tuesday, June 30, 2015 03:12:40 PM Alarie, Maxime wrote:
> I am new with auditd, and got some issues..
>
> For example, When I add or delete a user, I cannot see the entry with
> ausearch -m ADD_USER, it returns 0 match, BUT its logging it under
> USER_AUTH. If I do a ausearch -x adduser, ill thee se event audit.log with
> the EXECVE Type:
>
> # ausearch -x useradd | grep titi
> type=EXECVE msg=audit(1435677075.900:49410): argc=2 a0="useradd" a1="titi"
>
> I also tried to find a full description of all message types returned by
> ausearch -m but could not find any.. Any help on this would be
> appreciated as well.
I think we discovered that shadow-utils had messed up the auditing pretty
badly a few months ago. It caused me to write a document[1] that outlines how
its supposed to work so that we can check any and all implementations to make
sure they follow the standard. The shadow-utils in RHEL7.1 was patched to be
correct and I presume the patch should be upstream by now.
So, I believe that is what you are seeing. Shadow-utils is a horrible piece of
code for auditing because there are about 320 places that have audit events
generated. I think upstream made it a little better, but its a huge problem
because all those events have to be correct...and they weren't.
-Steve
[1] - http://people.redhat.com/sgrubb/audit/user-account-lifecycle.txt
^ permalink raw reply
* How to make sure a specific event is logged with thge proper message type?
From: Alarie, Maxime @ 2015-07-06 14:02 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 235 bytes --]
Hi,
I have this rule in audit.rules : -w /usr/sbin/useradd -p x -k user_modification
When I add a user, and do a ausearch -m ADD_USER I get 0 match. Am I doing something wrong here? I am using version 1.8.
Thanks
[-- Attachment #1.2: Type: text/html, Size: 2799 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* RE: How to make sure a specific event is logged with thge proper message type?
From: Boyce, Kevin P (AS) @ 2015-07-06 15:08 UTC (permalink / raw)
To: Alarie, Maxime, linux-audit@redhat.com
In-Reply-To: <23396023F719ED41888885C3B22D602F0154BB@WPEXCH2010MR11.bur.hydro.qc.ca>
[-- Attachment #1.1: Type: text/plain, Size: 618 bytes --]
OK this may be obvious but have you actually tried using useradd to create an account before running your ausearch?
From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Alarie, Maxime
Sent: Monday, July 06, 2015 10:03 AM
To: linux-audit@redhat.com
Subject: EXT :How to make sure a specific event is logged with thge proper message type?
Hi,
I have this rule in audit.rules : -w /usr/sbin/useradd -p x -k user_modification
When I add a user, and do a ausearch -m ADD_USER I get 0 match. Am I doing something wrong here? I am using version 1.8.
Thanks
[-- Attachment #1.2: Type: text/html, Size: 3834 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* RE: How to make sure a specific event is logged with thge proper message type?
From: Alarie, Maxime @ 2015-07-06 15:29 UTC (permalink / raw)
To: Boyce, Kevin P (AS), linux-audit@redhat.com
In-Reply-To: <4c840ecade994277bfdf313c6edcc6d3@XCGVAG30.northgrum.com>
[-- Attachment #1.1: Type: text/plain, Size: 1151 bytes --]
Thanks for the reply.
Of course :) I also tried DEL_USER on a deleted user, and nothing gets logged under that type, also I never get the hostname and addr fileds filled up.. Its always hostname=? And addr=?
Help is aprecited.
De : Boyce, Kevin P (AS) [mailto:Kevin.Boyce@ngc.com]
Envoyé : 6 juillet 2015 11:08
À : Alarie, Maxime; linux-audit@redhat.com
Objet : RE: How to make sure a specific event is logged with thge proper message type?
OK this may be obvious but have you actually tried using useradd to create an account before running your ausearch?
From: linux-audit-bounces@redhat.com<mailto:linux-audit-bounces@redhat.com> [mailto:linux-audit-bounces@redhat.com] On Behalf Of Alarie, Maxime
Sent: Monday, July 06, 2015 10:03 AM
To: linux-audit@redhat.com<mailto:linux-audit@redhat.com>
Subject: EXT :How to make sure a specific event is logged with thge proper message type?
Hi,
I have this rule in audit.rules : -w /usr/sbin/useradd -p x -k user_modification
When I add a user, and do a ausearch -m ADD_USER I get 0 match. Am I doing something wrong here? I am using version 1.8.
Thanks
[-- Attachment #1.2: Type: text/html, Size: 6792 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: How to make sure a specific event is logged with thge proper message type?
From: Steve Grubb @ 2015-07-06 16:01 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <23396023F719ED41888885C3B22D602F0154BB@WPEXCH2010MR11.bur.hydro.qc.ca>
On Monday, July 06, 2015 02:02:32 PM Alarie, Maxime wrote:
> Hi,
>
> I have this rule in audit.rules :
> -w /usr/sbin/useradd -p x -k user_modification
Note that this rule will create a SYSCALL event. To find it later, you would
run:
ausearch --start today -k user_modification
> When I add a user, and do a ausearch -m ADD_USER I get 0 match. Am I
> doing something wrong here? I am using version 1.8.
This event is a user space originating event and it depends on shadow-utils
being correctly patched to generate the events specified in:
http://people.redhat.com/sgrubb/audit/user-account-lifecycle.txt
If it doesn't, you should file a bug report against the shadow-utils package of
your distribution so that they know about the issue.
-Steve
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox