* RE: Linux audit performance impact
From: Viswanath, Logeswari P (MCOU OSTL) @ 2015-02-23 13:28 UTC (permalink / raw)
To: Paul Moore, Casey Schaufler; +Cc: Richard Guy Briggs, linux-audit@redhat.com
In-Reply-To: <CAHC9VhSjO9pRp9RQ7e0ub+8mosso+acTHVj7geiitxW0pFgVvg@mail.gmail.com>
> -----Original Message-----
> From: linux-audit-bounces@redhat.com [mailto:linux-audit-
> bounces@redhat.com] On Behalf Of Paul Moore
> Sent: Saturday, February 21, 2015 2:52 AM
> To: Casey Schaufler
> Cc: Richard Guy Briggs; linux-audit@redhat.com
> Subject: Re: Linux audit performance impact
>
> Yep. However, just so we're clear, what I'm proposing is just a change in the
> kernel API and record format, ultimately the on disk format will be
> dependent on the audit userspace. The good news is that if we can move
> away from this fixed string format it opens the door for different log formats;
> you could stick with the existing goofy strings or switch to any other format
> you like, you just have to write the daemon/tools.
>
> I may end up writing some dummy tools just as part of the kernel
> development process, and I might even maintain them as a simple example
> of an audit userspace. However, my hope is that Steve will update his audit
> userspace to take advantage of the new API when it is ready.
>
>
> My main goal is to try and create a sane API/record-format for the kernel
> that is maintainable over time and feature creep. My secondary goal is to
> push as much processing out of the kernel as possible, both for performance
> and flexibility reasons (see my main goal). A binary record format based
> around netlink attributes is likely the path of least resistance for these goals.
>
> Well, good news, you're in the right place. My patches will be posted here
> and all are welcome, and encouraged, to provide their comments and/or
> patches.
We believe this idea of "handing over the unformatted/binary audit record to audit user space"
gives flexibility to the audit user space to decide on how to handle it and brings
down the overhead that it causes to the system services.
We are also thinking to contribute to this change of linux audit implementation
with the experience of handling auditing on HP-UX.
Regards,
Logeswari.
^ permalink raw reply
* Re: multipart messages & delivery guarantees
From: Steve Grubb @ 2015-02-23 18:48 UTC (permalink / raw)
To: Hassan Sultan; +Cc: linux-audit
In-Reply-To: <op.xuhpzho21jp0b1@win8mac>
On Sun, 22 Feb 2015 19:15:07 -0800
"Hassan Sultan" <hsultan@thefroid.net> wrote:
> Some events, such as execve or socket-related syscalls generate more
> than one message, which I'll separate as the "main" message, and then
> the 'sub' messages.
>
> Does the audit system guarantee in any way that user-mode will
> receive either no message, or all messages for a given event ?
If a syscall cannot be audited, the syscall has to fail.
> I'm curious to know if for example I could get an execve syscall
> message, but no cwd message, for example in case of low-memory
> condition.
I suppose it depends on where in the processing an error occurs. Some
failure modes if selected cause a system panic. You'll probably want to
look through the kernel source code to be sure.
-Steve
^ permalink raw reply
* Re: [PATCH v2 1/3] kernel/audit: consolidate handling of mm->exe_file
From: Paul Moore @ 2015-02-23 21:59 UTC (permalink / raw)
To: Davidlohr Bueso; +Cc: akpm, linux-mm, linux-kernel, eparis, linux-audit
In-Reply-To: <1424658000.6539.14.camel@stgolabs.net>
On Sunday, February 22, 2015 06:20:00 PM Davidlohr Bueso wrote:
> This patch adds a audit_log_d_path_exe() helper function
> to share how we handle auditing of the exe_file's path.
> Used by both audit and auditsc. No functionality is changed.
>
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
> ---
>
> changes from v1: created normal function for helper.
>
> kernel/audit.c | 23 +++++++++++++++--------
> kernel/audit.h | 3 +++
> kernel/auditsc.c | 9 +--------
> 3 files changed, 19 insertions(+), 16 deletions(-)
Merged into audit#next.
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 72ab759..a71cbfe 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1838,11 +1838,24 @@ error_path:
> }
> EXPORT_SYMBOL(audit_log_task_context);
>
> +void audit_log_d_path_exe(struct audit_buffer *ab,
> + struct mm_struct *mm)
> +{
> + if (!mm) {
> + audit_log_format(ab, " exe=(null)");
> + return;
> + }
> +
> + down_read(&mm->mmap_sem);
> + if (mm->exe_file)
> + audit_log_d_path(ab, " exe=", &mm->exe_file->f_path);
> + up_read(&mm->mmap_sem);
> +}
> +
> void audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk)
> {
> const struct cred *cred;
> char comm[sizeof(tsk->comm)];
> - struct mm_struct *mm = tsk->mm;
> char *tty;
>
> if (!ab)
> @@ -1878,13 +1891,7 @@ void audit_log_task_info(struct audit_buffer *ab,
> struct task_struct *tsk) audit_log_format(ab, " comm=");
> audit_log_untrustedstring(ab, get_task_comm(comm, tsk));
>
> - if (mm) {
> - down_read(&mm->mmap_sem);
> - if (mm->exe_file)
> - audit_log_d_path(ab, " exe=", &mm->exe_file->f_path);
> - up_read(&mm->mmap_sem);
> - } else
> - audit_log_format(ab, " exe=(null)");
> + audit_log_d_path_exe(ab, tsk->mm);
> audit_log_task_context(ab);
> }
> EXPORT_SYMBOL(audit_log_task_info);
> diff --git a/kernel/audit.h b/kernel/audit.h
> index 1caa0d3..d641f9b 100644
> --- a/kernel/audit.h
> +++ b/kernel/audit.h
> @@ -257,6 +257,9 @@ extern struct list_head audit_filter_list[];
>
> extern struct audit_entry *audit_dupe_rule(struct audit_krule *old);
>
> +extern void audit_log_d_path_exe(struct audit_buffer *ab,
> + struct mm_struct *mm);
> +
> /* audit watch functions */
> #ifdef CONFIG_AUDIT_WATCH
> extern void audit_put_watch(struct audit_watch *watch);
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index dc4ae70..84c74d0 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2361,7 +2361,6 @@ static void audit_log_task(struct audit_buffer *ab)
> kuid_t auid, uid;
> kgid_t gid;
> unsigned int sessionid;
> - struct mm_struct *mm = current->mm;
> char comm[sizeof(current->comm)];
>
> auid = audit_get_loginuid(current);
> @@ -2376,13 +2375,7 @@ static void audit_log_task(struct audit_buffer *ab)
> audit_log_task_context(ab);
> audit_log_format(ab, " pid=%d comm=", task_pid_nr(current));
> audit_log_untrustedstring(ab, get_task_comm(comm, current));
> - if (mm) {
> - down_read(&mm->mmap_sem);
> - if (mm->exe_file)
> - audit_log_d_path(ab, " exe=", &mm->exe_file->f_path);
> - up_read(&mm->mmap_sem);
> - } else
> - audit_log_format(ab, " exe=(null)");
> + audit_log_d_path_exe(ab, current->mm);
> }
>
> /**
--
paul moore
www.paul-moore.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 2/3] kernel/audit: reduce mmap_sem hold for mm->exe_file
From: Paul Moore @ 2015-02-23 21:59 UTC (permalink / raw)
To: Davidlohr Bueso; +Cc: akpm, linux-mm, linux-kernel, eparis, linux-audit
In-Reply-To: <1424658009.6539.15.camel@stgolabs.net>
On Sunday, February 22, 2015 06:20:09 PM Davidlohr Bueso wrote:
> The mm->exe_file is currently serialized with mmap_sem (shared)
> in order to both safely (1) read the file and (2) audit it via
> audit_log_d_path(). Good users will, on the other hand, make use
> of the more standard get_mm_exe_file(), requiring only holding
> the mmap_sem to read the value, and relying on reference counting
> to make sure that the exe file won't dissapear underneath us.
>
> Additionally, upon NULL return of get_mm_exe_file, we also call
> audit_log_format(ab, " exe=(null)").
>
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
> ---
>
> changes from v1: rebased on top of 1/1.
>
> kernel/audit.c | 22 ++++++++++++++--------
> 1 file changed, 14 insertions(+), 8 deletions(-)
Merged into audit#next.
> diff --git a/kernel/audit.c b/kernel/audit.c
> index a71cbfe..b446d54 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -43,6 +43,7 @@
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +#include <linux/file.h>
> #include <linux/init.h>
> #include <linux/types.h>
> #include <linux/atomic.h>
> @@ -1841,15 +1842,20 @@ EXPORT_SYMBOL(audit_log_task_context);
> void audit_log_d_path_exe(struct audit_buffer *ab,
> struct mm_struct *mm)
> {
> - if (!mm) {
> - audit_log_format(ab, " exe=(null)");
> - return;
> - }
> + struct file *exe_file;
> +
> + if (!mm)
> + goto out_null;
>
> - down_read(&mm->mmap_sem);
> - if (mm->exe_file)
> - audit_log_d_path(ab, " exe=", &mm->exe_file->f_path);
> - up_read(&mm->mmap_sem);
> + exe_file = get_mm_exe_file(mm);
> + if (!exe_file)
> + goto out_null;
> +
> + audit_log_d_path(ab, " exe=", &exe_file->f_path);
> + fput(exe_file);
> + return;
> +out_null:
> + audit_log_format(ab, " exe=(null)");
> }
>
> void audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk)
--
paul moore
www.paul-moore.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 1/3] kernel/audit: consolidate handling of mm->exe_file
From: Davidlohr Bueso @ 2015-02-23 22:02 UTC (permalink / raw)
To: Paul Moore; +Cc: akpm, linux-mm, linux-kernel, eparis, linux-audit
In-Reply-To: <1579072.xrgTk0Bmz6@sifl>
On Mon, 2015-02-23 at 16:59 -0500, Paul Moore wrote:
> Merged into audit#next.
hmm Andrew I was hoping you could take these patches. That way we can
easily build on top. Let me know if you think otherwise, as I've got
more ready to send out with a similar email scheme.
Thanks,
Davidlohr
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 1/3] kernel/audit: consolidate handling of mm->exe_file
From: Paul Moore @ 2015-02-23 22:24 UTC (permalink / raw)
To: Davidlohr Bueso; +Cc: akpm, linux-mm, linux-kernel, Eric Paris, linux-audit
In-Reply-To: <1424728954.6539.49.camel@stgolabs.net>
On Mon, Feb 23, 2015 at 5:02 PM, Davidlohr Bueso <dave@stgolabs.net> wrote:
> On Mon, 2015-02-23 at 16:59 -0500, Paul Moore wrote:
>> Merged into audit#next.
>
> hmm Andrew I was hoping you could take these patches. That way we can
> easily build on top. Let me know if you think otherwise, as I've got
> more ready to send out with a similar email scheme.
FWIW, I merged these two patches into the audit#next branch because
they are contained to audit and have value regardless of what else
happens during this development cycle. It is just linux-next after
all, not Linus tree so if I need to drop the patches later I can do
that easily enough. I'd rather get more exposure to the patches than
less, and getting into linux-next now helps that.
--
paul moore
www.paul-moore.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* log rendering in real time in audit-viewer
From: Xeniya Muratova @ 2015-03-04 13:42 UTC (permalink / raw)
To: mitr, linux-audit
Hello Miloslav, and all the guys!
We use audit-viewer for events monitoring.
Unfortunately, if some log is rather big it takes to much time for audit-viewer to parse and render it.
Besides, we need to render log updates in real time, i.e. when a new line appears in a log, it should appear in a viewer too.
Can you suggest the better way to extend audit-viewer to meet these requirements?
Thanks in advance.
Kseniya Muratova,
^ permalink raw reply
* Re: log rendering in real time in audit-viewer
From: Miloslav Trmač @ 2015-03-04 17:50 UTC (permalink / raw)
To: Xeniya Muratova; +Cc: linux-audit
In-Reply-To: <694048276.195188.1425476554552.JavaMail.zimbra@itsirius.su>
Hello,
> Hello Miloslav, and all the guys!
>
> We use audit-viewer for events monitoring.
> Unfortunately, if some log is rather big it takes to much time for
> audit-viewer to parse and render it.
> Besides, we need to render log updates in real time, i.e. when a new line
> appears in a log, it should appear in a viewer too.
> Can you suggest the better way to extend audit-viewer to meet these
> requirements?
Well, write the code? Something like inotify could be useful. There isn’t any hidden switch to enable these features, if that is what you are asking.
As for performance, I may have missed something but I think I have squeezed as much as can be done with Python; improving performance further would very likely require a C extension.
(audit-viewer is a PyGtk2 application, and at I’m afraid I don’t currently have plans to port it to GTK+3/gobject-introspection or do any other non-trivial work on the project, at least in the near term.)
Mirek
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* RE: log rendering in real time in audit-viewer
From: Pittigher, Raymond - Exelis @ 2015-03-05 12:45 UTC (permalink / raw)
To: Xeniya Muratova, mitr@redhat.com, linux-audit@redhat.com
In-Reply-To: <694048276.195188.1425476554552.JavaMail.zimbra@itsirius.su>
Free or pay for solutions? You have products like splunk and greybar that do a good job. Managengine also has a log viewer that works OK. You will just need to pass audit logs to syslog to use most products.
-
Ray Pittigher
--Exelis Inc, Clifton NJ
--phone 973-284-2275
--email raymond.pittigher@exelisinc.com
________________________________________
From: linux-audit-bounces@redhat.com [linux-audit-bounces@redhat.com] on behalf of Xeniya Muratova [muratova@itsirius.su]
Sent: Wednesday, March 04, 2015 8:42 AM
To: mitr@redhat.com; linux-audit@redhat.com
Subject: log rendering in real time in audit-viewer
Hello Miloslav, and all the guys!
We use audit-viewer for events monitoring.
Unfortunately, if some log is rather big it takes to much time for audit-viewer to parse and render it.
Besides, we need to render log updates in real time, i.e. when a new line appears in a log, it should appear in a viewer too.
Can you suggest the better way to extend audit-viewer to meet these requirements?
Thanks in advance.
Kseniya Muratova,
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
________________________________
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail.
^ permalink raw reply
* Re: log rendering in real time in audit-viewer
From: Steve Grubb @ 2015-03-05 14:36 UTC (permalink / raw)
To: linux-audit; +Cc: Miloslav Trmač
In-Reply-To: <1521044842.29926652.1425491453509.JavaMail.zimbra@redhat.com>
On Wednesday, March 04, 2015 12:50:53 PM Miloslav Trmač wrote:
> Hello,
>
> > Hello Miloslav, and all the guys!
> >
> > We use audit-viewer for events monitoring.
> > Unfortunately, if some log is rather big it takes to much time for
> > audit-viewer to parse and render it.
> > Besides, we need to render log updates in real time, i.e. when a new line
> > appears in a log, it should appear in a viewer too.
> > Can you suggest the better way to extend audit-viewer to meet these
> > requirements?
>
> Well, write the code? Something like inotify could be useful. There isn’t
> any hidden switch to enable these features, if that is what you are asking.
>
> As for performance, I may have missed something but I think I have squeezed
> as much as can be done with Python; improving performance further would
> very likely require a C extension.
And it also uses the auparse library underneath which might could use some
speeding up. There were some performance improvements over the last year. But
I don't know if that is enough to be noticeable in a high level application.
But it would be another obvious place that could be a performance bottleneck.
-Steve
> (audit-viewer is a PyGtk2 application, and at I’m afraid I don’t currently
> have plans to port it to GTK+3/gobject-introspection or do any other
> non-trivial work on the project, at least in the near term.) Mirek
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* x32 + audit status?
From: David Drysdale @ 2015-03-05 18:32 UTC (permalink / raw)
To: Paul Moore, Eric Paris
Cc: Kees Cook, Andy Lutomirski, linux-kernel@vger.kernel.org,
linux-audit
Hi,
Do we currently expect the audit system to work with x32 syscalls?
I was playing with the audit system for the first time today (on
v4.0-rc2, due to [1]), and it didn't seem to work for me. (Tweaking
ptrace.c like the patch below seemed to help, but I may just have
configured something wrong.)
I know there was a bunch of activity around this area in mid-2014,
but I'm not sure what the final position was...
Thanks,
David
[1]: https://lkml.org/lkml/2015/3/4/879
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index e510618b2e91..443932afd9e8 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1445,7 +1445,7 @@ static void do_audit_syscall_entry(struct
pt_regs *regs, u32 arch)
{
#ifdef CONFIG_X86_64
if (arch == AUDIT_ARCH_X86_64) {
- audit_syscall_entry(regs->orig_ax, regs->di,
+ audit_syscall_entry(regs->orig_ax & __SYSCALL_MASK, regs->di,
regs->si, regs->dx, regs->r10);
} else
#endif
^ permalink raw reply related
* Re: x32 + audit status?
From: Andy Lutomirski @ 2015-03-05 23:07 UTC (permalink / raw)
To: David Drysdale
Cc: linux-kernel@vger.kernel.org, Paul Moore, linux-audit, Kees Cook,
Eric Paris
In-Reply-To: <CAHse=S8=2TZQVni3ervR1ai7gd0K6RFTU6D67CfLrpxn-h1-Vg@mail.gmail.com>
On Mar 5, 2015 10:32 AM, "David Drysdale" <drysdale@google.com> wrote:
>
> Hi,
>
> Do we currently expect the audit system to work with x32 syscalls?
>
> I was playing with the audit system for the first time today (on
> v4.0-rc2, due to [1]), and it didn't seem to work for me. (Tweaking
> ptrace.c like the patch below seemed to help, but I may just have
> configured something wrong.)
>
> I know there was a bunch of activity around this area in mid-2014,
> but I'm not sure what the final position was...
It's totally broken, and it needs ABI work. I think it should keep
the high syscall numbers, which means that both userspace and the
audit core need to learn how to deal with it.
--Andy
>
> Thanks,
> David
>
> [1]: https://lkml.org/lkml/2015/3/4/879
>
> diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
> index e510618b2e91..443932afd9e8 100644
> --- a/arch/x86/kernel/ptrace.c
> +++ b/arch/x86/kernel/ptrace.c
> @@ -1445,7 +1445,7 @@ static void do_audit_syscall_entry(struct
> pt_regs *regs, u32 arch)
> {
> #ifdef CONFIG_X86_64
> if (arch == AUDIT_ARCH_X86_64) {
> - audit_syscall_entry(regs->orig_ax, regs->di,
> + audit_syscall_entry(regs->orig_ax & __SYSCALL_MASK, regs->di,
> regs->si, regs->dx, regs->r10);
> } else
> #endif
^ permalink raw reply
* Re: x32 + audit status?
From: Paul Moore @ 2015-03-06 7:28 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David Drysdale, linux-kernel@vger.kernel.org, linux-audit,
Kees Cook, Eric Paris
In-Reply-To: <CALCETrUZpTB6g1HRkOn0iqBUio4j11WV3D2-u6RQVpW32Bh7Ew@mail.gmail.com>
On Thu, Mar 5, 2015 at 6:07 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mar 5, 2015 10:32 AM, "David Drysdale" <drysdale@google.com> wrote:
>>
>> Hi,
>>
>> Do we currently expect the audit system to work with x32 syscalls?
>>
>> I was playing with the audit system for the first time today (on
>> v4.0-rc2, due to [1]), and it didn't seem to work for me. (Tweaking
>> ptrace.c like the patch below seemed to help, but I may just have
>> configured something wrong.)
>>
>> I know there was a bunch of activity around this area in mid-2014,
>> but I'm not sure what the final position was...
>
> It's totally broken, and it needs ABI work. I think it should keep
> the high syscall numbers, which means that both userspace and the
> audit core need to learn how to deal with it.
What Andy said. It's on the list of things to fix, but to be brutally
honest, it's not very high on the list due to lack of interest from
people asking for audit/x32 support.
^ permalink raw reply
* Re: x32 + audit status?
From: David Drysdale @ 2015-03-06 9:52 UTC (permalink / raw)
To: Paul Moore
Cc: Andy Lutomirski, linux-kernel@vger.kernel.org, linux-audit,
Kees Cook, Eric Paris
In-Reply-To: <CAHC9VhTpb0srrPyZcByfi+JNwpih+VBXQXrzYGo0CG45zBRqLQ@mail.gmail.com>
On Fri, Mar 6, 2015 at 7:28 AM, Paul Moore <paul@paul-moore.com> wrote:
> On Thu, Mar 5, 2015 at 6:07 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Mar 5, 2015 10:32 AM, "David Drysdale" <drysdale@google.com> wrote:
>>>
>>> Hi,
>>>
>>> Do we currently expect the audit system to work with x32 syscalls?
>>>
>>> I was playing with the audit system for the first time today (on
>>> v4.0-rc2, due to [1]), and it didn't seem to work for me. (Tweaking
>>> ptrace.c like the patch below seemed to help, but I may just have
>>> configured something wrong.)
>>>
>>> I know there was a bunch of activity around this area in mid-2014,
>>> but I'm not sure what the final position was...
>>
>> It's totally broken, and it needs ABI work. I think it should keep
>> the high syscall numbers, which means that both userspace and the
>> audit core need to learn how to deal with it.
>
> What Andy said. It's on the list of things to fix, but to be brutally
> honest, it's not very high on the list due to lack of interest from
> people asking for audit/x32 support.
Fair enough -- thanks for letting me know.
^ permalink raw reply
* [PATCH 0/2] Update audit syscall classification for execve variants
From: David Drysdale @ 2015-03-06 15:40 UTC (permalink / raw)
To: Brian Gerst, Ingo Molnar
Cc: H. Peter Anvin, AKASHI Takahiro, Richard Guy Briggs, Eric Paris,
Paul Moore, stable, linux-audit, linux-kernel, David Drysdale
Add a couple of missing execve variants to the syscall
classification code in the audit system.
- Patch 1 is potentially suitable for 3.19 stable.
- Patch 2 need not be back-applied, as audit doesn't yet work
with x32 syscalls in general.
David Drysdale (2):
audit: add execveat to syscall classification
audit,x86: add x32_execve[at] to syscall classification
arch/x86/kernel/audit_64.c | 6 ++++++
lib/compat_audit.c | 3 +++
2 files changed, 9 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] audit: add execveat to syscall classification
From: David Drysdale @ 2015-03-06 15:40 UTC (permalink / raw)
To: Brian Gerst, Ingo Molnar
Cc: H. Peter Anvin, AKASHI Takahiro, Richard Guy Briggs, Eric Paris,
Paul Moore, stable, linux-audit, linux-kernel, David Drysdale
In-Reply-To: <1425656438-3884-1-git-send-email-drysdale@google.com>
New execveat syscall from v3.19 is missing from
audit_classify_compat_syscall().
Reported-by: Brian Gerst <brgerst@gmail.com>
Signed-off-by: David Drysdale <drysdale@google.com>
---
lib/compat_audit.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/compat_audit.c b/lib/compat_audit.c
index 873f75b640ab..a49469f0511d 100644
--- a/lib/compat_audit.c
+++ b/lib/compat_audit.c
@@ -42,6 +42,9 @@ int audit_classify_compat_syscall(int abi, unsigned syscall)
case __NR_socketcall:
return 4;
#endif
+#ifdef __NR_execveat
+ case __NR_execveat:
+#endif
case __NR_execve:
return 5;
default:
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] audit,x86: add x32_execve[at] to syscall classification
From: David Drysdale @ 2015-03-06 15:40 UTC (permalink / raw)
To: Brian Gerst, Ingo Molnar
Cc: H. Peter Anvin, AKASHI Takahiro, Richard Guy Briggs, Eric Paris,
Paul Moore, stable, linux-audit, linux-kernel, David Drysdale
In-Reply-To: <1425656438-3884-1-git-send-email-drysdale@google.com>
Treat x32 ABI variants of execve[at] the same as x86_64
variants.
Slightly speculative as the audit subsystem doesn't currently
work with x32 ABI syscalls. If and when audit+x32 does work,
this should correctly classify exec calls.
Signed-off-by: David Drysdale <drysdale@google.com>
---
arch/x86/kernel/audit_64.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/kernel/audit_64.c b/arch/x86/kernel/audit_64.c
index f3672508b249..0aec72d8d3c7 100644
--- a/arch/x86/kernel/audit_64.c
+++ b/arch/x86/kernel/audit_64.c
@@ -49,6 +49,12 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 2;
case __NR_openat:
return 3;
+#ifdef __NR_x32_execve
+ case __NR_x32_execve:
+#endif
+#ifdef __NR_x32_execveat
+ case __NR_x32_execveat:
+#endif
case __NR_execve:
case __NR_execveat:
return 5;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/2] audit: add execveat to syscall classification
From: Greg KH @ 2015-03-06 17:45 UTC (permalink / raw)
To: David Drysdale
Cc: Brian Gerst, Ingo Molnar, H. Peter Anvin, AKASHI Takahiro,
Richard Guy Briggs, Eric Paris, Paul Moore, stable, linux-audit,
linux-kernel
In-Reply-To: <1425656438-3884-2-git-send-email-drysdale@google.com>
On Fri, Mar 06, 2015 at 03:40:37PM +0000, David Drysdale wrote:
> New execveat syscall from v3.19 is missing from
> audit_classify_compat_syscall().
>
> Reported-by: Brian Gerst <brgerst@gmail.com>
> Signed-off-by: David Drysdale <drysdale@google.com>
> ---
> lib/compat_audit.c | 3 +++
> 1 file changed, 3 insertions(+)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* Re: [PATCH 2/2] audit,x86: add x32_execve[at] to syscall classification
From: Greg KH @ 2015-03-06 17:45 UTC (permalink / raw)
To: David Drysdale
Cc: Brian Gerst, Ingo Molnar, H. Peter Anvin, AKASHI Takahiro,
Richard Guy Briggs, Eric Paris, Paul Moore, stable, linux-audit,
linux-kernel
In-Reply-To: <1425656438-3884-3-git-send-email-drysdale@google.com>
On Fri, Mar 06, 2015 at 03:40:38PM +0000, David Drysdale wrote:
> Treat x32 ABI variants of execve[at] the same as x86_64
> variants.
>
> Slightly speculative as the audit subsystem doesn't currently
> work with x32 ABI syscalls. If and when audit+x32 does work,
> this should correctly classify exec calls.
>
> Signed-off-by: David Drysdale <drysdale@google.com>
> ---
> arch/x86/kernel/audit_64.c | 6 ++++++
> 1 file changed, 6 insertions(+)
<formletter>
Cc: stable <stable@vger.kernel.org>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* [PATCH] audit: Remove condition which always evaluates to false
From: Pranith Kumar @ 2015-03-11 18:08 UTC (permalink / raw)
To: Paul Moore, Eric Paris, moderated list:AUDIT SUBSYSTEM, open list
After commit 3e1d0bb6224f019893d1c498cc3327559d183674 ("audit: Convert int limit
uses to u32"), by converting an int to u32, few conditions will always evaluate
to false.
These warnings were emitted during compilation:
kernel/audit.c: In function ‘audit_set_enabled’:
kernel/audit.c:347:2: warning: comparison of unsigned expression < 0 is always
false [-Wtype-limits]
if (state < AUDIT_OFF || state > AUDIT_LOCKED)
^
kernel/audit.c: In function ‘audit_receive_msg’:
kernel/audit.c:880:9: warning: comparison of unsigned expression < 0 is
always false [-Wtype-limits]
if (s.backlog_wait_time < 0 ||
The following patch removes those unnecessary conditions.
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
---
kernel/audit.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 72ab759..b1006cb 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -344,7 +344,7 @@ static int audit_set_backlog_wait_time(u32 timeout)
static int audit_set_enabled(u32 state)
{
int rc;
- if (state < AUDIT_OFF || state > AUDIT_LOCKED)
+ if (state > AUDIT_LOCKED)
return -EINVAL;
rc = audit_do_config_change("audit_enabled", &audit_enabled, state);
@@ -877,8 +877,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
if (s.mask & AUDIT_STATUS_BACKLOG_WAIT_TIME) {
if (sizeof(s) > (size_t)nlh->nlmsg_len)
return -EINVAL;
- if (s.backlog_wait_time < 0 ||
- s.backlog_wait_time > 10*AUDIT_BACKLOG_WAIT_TIME)
+ if (s.backlog_wait_time > 10*AUDIT_BACKLOG_WAIT_TIME)
return -EINVAL;
err = audit_set_backlog_wait_time(s.backlog_wait_time);
if (err < 0)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] audit: Remove condition which always evaluates to false
From: Paul Moore @ 2015-03-13 21:35 UTC (permalink / raw)
To: Pranith Kumar; +Cc: Eric Paris, moderated list:AUDIT SUBSYSTEM, open list
In-Reply-To: <1426097299-30577-1-git-send-email-bobby.prani@gmail.com>
On Wed, Mar 11, 2015 at 2:08 PM, Pranith Kumar <bobby.prani@gmail.com> wrote:
> After commit 3e1d0bb6224f019893d1c498cc3327559d183674 ("audit: Convert int limit
> uses to u32"), by converting an int to u32, few conditions will always evaluate
> to false.
>
> These warnings were emitted during compilation:
>
> kernel/audit.c: In function ‘audit_set_enabled’:
> kernel/audit.c:347:2: warning: comparison of unsigned expression < 0 is always
> false [-Wtype-limits]
> if (state < AUDIT_OFF || state > AUDIT_LOCKED)
> ^
> kernel/audit.c: In function ‘audit_receive_msg’:
> kernel/audit.c:880:9: warning: comparison of unsigned expression < 0 is
> always false [-Wtype-limits]
> if (s.backlog_wait_time < 0 ||
>
> The following patch removes those unnecessary conditions.
>
> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
> ---
> kernel/audit.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Applied, thanks!
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 72ab759..b1006cb 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -344,7 +344,7 @@ static int audit_set_backlog_wait_time(u32 timeout)
> static int audit_set_enabled(u32 state)
> {
> int rc;
> - if (state < AUDIT_OFF || state > AUDIT_LOCKED)
> + if (state > AUDIT_LOCKED)
> return -EINVAL;
>
> rc = audit_do_config_change("audit_enabled", &audit_enabled, state);
> @@ -877,8 +877,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
> if (s.mask & AUDIT_STATUS_BACKLOG_WAIT_TIME) {
> if (sizeof(s) > (size_t)nlh->nlmsg_len)
> return -EINVAL;
> - if (s.backlog_wait_time < 0 ||
> - s.backlog_wait_time > 10*AUDIT_BACKLOG_WAIT_TIME)
> + if (s.backlog_wait_time > 10*AUDIT_BACKLOG_WAIT_TIME)
> return -EINVAL;
> err = audit_set_backlog_wait_time(s.backlog_wait_time);
> if (err < 0)
> --
> 1.9.1
>
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [PATCH] audit.h: remove the macro AUDIT_ARCH_ARMEB definition
From: roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w @ 2015-03-20 4:55 UTC (permalink / raw)
To: paul-r2n+y4ga6xFZroRs9YW3xA, eparis-H+wXaHxf7aLQT0dZR+AlfA,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
linux-api-u79uwXL29TY76Z2rM5mHXA
From: Li RongQing <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
After 2f9783669 [ARM: 7412/1: audit: use only AUDIT_ARCH_ARM regardless
of endianness], no kernel user uses this macro;
Keeping this macro, only makes the compiling old version audit [before
changeset 931 Improve ARM and AARCH64 support] success, but the audit
program can not work with the kernel after 2f9783669 still,
since no syscall entry is enabled for AUDIT_ARCH_ARMEB in kernel.
so remove it to force to use the latest audit program
Signed-off-by: Li RongQing <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
other workaround is to define AUDIT_ARCH_ARMEB as AUDIT_ARCH_ARM,
but it seems very strange
include/uapi/linux/audit.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index d3475e1..125aa49 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -351,7 +351,6 @@ enum {
#define AUDIT_ARCH_AARCH64 (EM_AARCH64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
#define AUDIT_ARCH_ALPHA (EM_ALPHA|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
#define AUDIT_ARCH_ARM (EM_ARM|__AUDIT_ARCH_LE)
-#define AUDIT_ARCH_ARMEB (EM_ARM)
#define AUDIT_ARCH_CRIS (EM_CRIS|__AUDIT_ARCH_LE)
#define AUDIT_ARCH_FRV (EM_FRV)
#define AUDIT_ARCH_I386 (EM_386|__AUDIT_ARCH_LE)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] audit.h: remove the macro AUDIT_ARCH_ARMEB definition
From: Paul Moore @ 2015-03-20 13:29 UTC (permalink / raw)
To: roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w
Cc: Eric Paris, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1426827329-27976-1-git-send-email-roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Mar 20, 2015 at 12:55 AM, <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Li RongQing <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> After 2f9783669 [ARM: 7412/1: audit: use only AUDIT_ARCH_ARM regardless
> of endianness], no kernel user uses this macro;
>
> Keeping this macro, only makes the compiling old version audit [before
> changeset 931 Improve ARM and AARCH64 support] success, but the audit
> program can not work with the kernel after 2f9783669 still,
> since no syscall entry is enabled for AUDIT_ARCH_ARMEB in kernel.
>
> so remove it to force to use the latest audit program
>
> Signed-off-by: Li RongQing <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> other workaround is to define AUDIT_ARCH_ARMEB as AUDIT_ARCH_ARM,
> but it seems very strange
>
> include/uapi/linux/audit.h | 1 -
> 1 file changed, 1 deletion(-)
Since this #define lives in the user visible headers I don't want to
remove it and risk causing a userspace breakage. Leaving the #define
in the header, even if it is unused by modern userspace, is harmless.
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index d3475e1..125aa49 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -351,7 +351,6 @@ enum {
> #define AUDIT_ARCH_AARCH64 (EM_AARCH64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
> #define AUDIT_ARCH_ALPHA (EM_ALPHA|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
> #define AUDIT_ARCH_ARM (EM_ARM|__AUDIT_ARCH_LE)
> -#define AUDIT_ARCH_ARMEB (EM_ARM)
> #define AUDIT_ARCH_CRIS (EM_CRIS|__AUDIT_ARCH_LE)
> #define AUDIT_ARCH_FRV (EM_FRV)
> #define AUDIT_ARCH_I386 (EM_386|__AUDIT_ARCH_LE)
> --
> 2.1.0
>
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] audit.h: remove the macro AUDIT_ARCH_ARMEB definition
From: Li RongQing @ 2015-03-23 0:51 UTC (permalink / raw)
To: Paul Moore
Cc: Eric Paris, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAHC9VhR5VcaCtLG9hdVS2gZRWxVmdnpbK+fJwm6wCA8qyLebUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Mar 20, 2015 at 9:29 PM, Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org> wrote:
> On Fri, Mar 20, 2015 at 12:55 AM, <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> From: Li RongQing <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>
>> After 2f9783669 [ARM: 7412/1: audit: use only AUDIT_ARCH_ARM regardless
>> of endianness], no kernel user uses this macro;
>>
>> Keeping this macro, only makes the compiling old version audit [before
>> changeset 931 Improve ARM and AARCH64 support] success, but the audit
>> program can not work with the kernel after 2f9783669 still,
>> since no syscall entry is enabled for AUDIT_ARCH_ARMEB in kernel.
>>
>> so remove it to force to use the latest audit program
>>
>> Signed-off-by: Li RongQing <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> other workaround is to define AUDIT_ARCH_ARMEB as AUDIT_ARCH_ARM,
>> but it seems very strange
>>
>> include/uapi/linux/audit.h | 1 -
>> 1 file changed, 1 deletion(-)
>
> Since this #define lives in the user visible headers I don't want to
> remove it and risk causing a userspace breakage. Leaving the #define
> in the header, even if it is unused by modern userspace, is harmless.
>
it is harm, when I compile the audit-2.3.2 for a arm machine, whose linux kernel
is 3.14; no compile error, but audit does not work; since the audit is
>
>
> --
> paul moore
> www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] audit.h: remove the macro AUDIT_ARCH_ARMEB definition
From: Li RongQing @ 2015-03-23 0:55 UTC (permalink / raw)
To: Paul Moore
Cc: Eric Paris, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAJFZqHxdPEhX+9z-FYUMvTF_6LVgK=gOetq0zT4UTZSgUGRqCQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Mar 23, 2015 at 8:51 AM, Li RongQing <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Mar 20, 2015 at 9:29 PM, Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org> wrote:
>> On Fri, Mar 20, 2015 at 12:55 AM, <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> From: Li RongQing <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>
>>> After 2f9783669 [ARM: 7412/1: audit: use only AUDIT_ARCH_ARM regardless
>>> of endianness], no kernel user uses this macro;
>>>
>>> Keeping this macro, only makes the compiling old version audit [before
>>> changeset 931 Improve ARM and AARCH64 support] success, but the audit
>>> program can not work with the kernel after 2f9783669 still,
>>> since no syscall entry is enabled for AUDIT_ARCH_ARMEB in kernel.
>>>
>>> so remove it to force to use the latest audit program
>>>
>>> Signed-off-by: Li RongQing <roy.qing.li-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>> other workaround is to define AUDIT_ARCH_ARMEB as AUDIT_ARCH_ARM,
>>> but it seems very strange
>>>
>>> include/uapi/linux/audit.h | 1 -
>>> 1 file changed, 1 deletion(-)
>>
>> Since this #define lives in the user visible headers I don't want to
>> remove it and risk causing a userspace breakage. Leaving the #define
>> in the header, even if it is
it is harm, when I compile the audit-2.3.2 for a arm machine, whose linux kernel
is 3.14; no compile error, but audit does not work; spend one day debug to find
the root cause is the audit used MACH_ARMEB, but kernel replaced MACH_ARMEB
with MACH_ARM
grep WITH_ARMEB ./lib/machinetab.h -A10
#ifdef WITH_ARMEB
_S(MACH_ARMEB, "armeb" )
_S(MACH_ARMEB, "armv5tejl")
_S(MACH_ARMEB, "armv5tel")
_S(MACH_ARMEB, "armv6l")
_S(MACH_ARMEB, "armv7l")
#endif
removal of MACH_ARMEB will let the user find this issue when compile, not
run.
-Roy
^ 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