5:17 p.m.
On Sat, Apr 9, 2016 at 10:41 PM, Andi Kleen <andi(a)firstfloor.org> wrote:
> What kernel version are you using? I believe we fixed that in
Linux
> 4.5 with the following:
This is 4.6-rc2.
>
> commit 96368701e1c89057bbf39222e965161c68a85b4b
> From: Paul Moore <pmoore(a)redhat.com>
> Date: Wed, 13 Jan 2016 10:18:55 -0400 (09:18 -0500)
>
> audit: force seccomp event logging to honor the audit_enabled flag
No you didn't fix it because audit_enabled is always enabled by systemd
for user space auditing, see the original description of my patch.
[NOTE: adding the audit list to the CC line]
Sorry, I read your email too quickly; you are correct, that commit
fixed a different problem.
Let me think on this a bit more. Technically I don't see this as a
bug with the kernel, userspace is enabling audit and you are getting
audit messages as a result; from my opinion this is the expected
behavior. However, we've talked in the past about providing better
control over seccomp's auditing/logging and that work would allow you
to quiet all seccomp messages if you desired.
If you are interested, I started tracking this issue at the link below:
* https://github.com/linux-audit/audit-kernel/issues/13
--
paul moore
www.paul-moore.com
5:31 p.m.
New subject: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Sun, Apr 10, 2016 at 06:17:53PM -0400, Paul Moore wrote:
On Sat, Apr 9, 2016 at 10:41 PM, Andi Kleen
<andi(a)firstfloor.org> wrote:
>> What kernel version are you using? I believe we fixed that in Linux
>> 4.5 with the following:
>
> This is 4.6-rc2.
>>
>> commit 96368701e1c89057bbf39222e965161c68a85b4b
>> From: Paul Moore <pmoore(a)redhat.com>
>> Date: Wed, 13 Jan 2016 10:18:55 -0400 (09:18 -0500)
>>
>> audit: force seccomp event logging to honor the audit_enabled flag
>
> No you didn't fix it because audit_enabled is always enabled by systemd
> for user space auditing, see the original description of my patch.
[NOTE: adding the audit list to the CC line]
This mailing list is marked subscriber only in MAINTAINERS so I
intentionally didn't add it. It's unlikely that my emails
will make it through.
Sorry, I read your email too quickly; you are correct, that commit
fixed a different problem.
Let me think on this a bit more. Technically I don't see this as a
bug with the kernel, userspace is enabling audit and you are getting
audit messages as a result; from my opinion this is the expected
It's a bug in the kernel because seccomp is different from everything else.
The kernel only produces audit messages when audit rules are set
for every other case.
The only exception is this seccomp message which is produced
unconditionally. Doesn't make sense to treat seccomp special
here. It should only be audited when some kind of rule is set.
behavior. However, we've talked in the past about providing
better
control over seccomp's auditing/logging and that work would allow you
to quiet all seccomp messages if you desired.
If you are interested, I started tracking this issue at the link below:
* https://github.com/linux-audit/audit-kernel/issues/13
Making it a sysctl is fine for me as long as it is disabled by default
so that user space doesn't need to be modified to make seccomp
stop spamming.
Audit should always be opt-in, not opt-out.
However I think making it conditional on syscall auditing like
in my patch is equivalent and much simpler.
If you really insist on the sysctl I can send patch.
-Andi
9:30 p.m.
New subject: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Sun, Apr 10, 2016 at 6:31 PM, Andi Kleen <ak(a)linux.intel.com> wrote:
On Sun, Apr 10, 2016 at 06:17:53PM -0400, Paul Moore wrote:
> On Sat, Apr 9, 2016 at 10:41 PM, Andi Kleen <andi(a)firstfloor.org> wrote:
> >> What kernel version are you using? I believe we fixed that in Linux
> >> 4.5 with the following:
> >
> > This is 4.6-rc2.
> >>
> >> commit 96368701e1c89057bbf39222e965161c68a85b4b
> >> From: Paul Moore <pmoore(a)redhat.com>
> >> Date: Wed, 13 Jan 2016 10:18:55 -0400 (09:18 -0500)
> >>
> >> audit: force seccomp event logging to honor the audit_enabled flag
> >
> > No you didn't fix it because audit_enabled is always enabled by systemd
> > for user space auditing, see the original description of my patch.
>
> [NOTE: adding the audit list to the CC line]
This mailing list is marked subscriber only in MAINTAINERS so I
intentionally didn't add it. It's unlikely that my emails
will make it through.
Steve Grubb checks it on a regular basis and approves anything
remotely audit related. Please make use of it in the future; it's
listed in MAINTAINERS for a reason.
> Sorry, I read your email too quickly; you are correct, that
commit
> fixed a different problem.
>
> Let me think on this a bit more. Technically I don't see this as a
> bug with the kernel, userspace is enabling audit and you are getting
> audit messages as a result; from my opinion this is the expected
It's a bug in the kernel because seccomp is different from everything else.
This behavior has existed since seccomp auditing was first introduced.
I disagree with your opinion that it is a bug, but I don't think it is
worth arguing over the distinction since we are talking about changing
it regardless.
> ... However, we've talked in the past about providing better
> control over seccomp's auditing/logging and that work would allow you
> to quiet all seccomp messages if you desired.
>
> If you are interested, I started tracking this issue at the link below:
>
> * https://github.com/linux-audit/audit-kernel/issues/13
Making it a sysctl is fine for me as long as it is disabled by default
so that user space doesn't need to be modified to make seccomp
stop spamming.
Audit should always be opt-in, not opt-out.
From my perspective, you, or rather systemd in your case, is opting in
by enabling audit.
However I think making it conditional on syscall auditing like
in my patch is equivalent and much simpler.
If you really insist on the sysctl I can send patch.
As I said earlier, I haven't given this a lot of thought as of yet,
but so far I like the sysctl approach much more than the patch you
sent earlier.
--
paul moore
www.paul-moore.com
3:34 p.m.
New subject: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On 16/04/10, Andi Kleen wrote:
On Sun, Apr 10, 2016 at 06:17:53PM -0400, Paul Moore wrote:
> On Sat, Apr 9, 2016 at 10:41 PM, Andi Kleen <andi(a)firstfloor.org> wrote:
> >> What kernel version are you using? I believe we fixed that in Linux
> >> 4.5 with the following:
> >
> > This is 4.6-rc2.
> >>
> >> commit 96368701e1c89057bbf39222e965161c68a85b4b
> >> From: Paul Moore <pmoore(a)redhat.com>
> >> Date: Wed, 13 Jan 2016 10:18:55 -0400 (09:18 -0500)
> >>
> >> audit: force seccomp event logging to honor the audit_enabled flag
> >
> > No you didn't fix it because audit_enabled is always enabled by systemd
> > for user space auditing, see the original description of my patch.
> Sorry, I read your email too quickly; you are correct, that
commit
> fixed a different problem.
>
> Let me think on this a bit more. Technically I don't see this as a
> bug with the kernel, userspace is enabling audit and you are getting
> audit messages as a result; from my opinion this is the expected
It's a bug in the kernel because seccomp is different from everything else.
The kernel only produces audit messages when audit rules are set
for every other case.
I can think of other examples, such as CONFIG_CHANGE, LOGIN,
NETFILTER_CFG, MAC_*, AVC and surely others, if I am understanding your
point.
The only exception is this seccomp message which is produced
unconditionally. Doesn't make sense to treat seccomp special
here. It should only be audited when some kind of rule is set.
We had the opposite problem with AUDIT_USER_AVC and maybe also with
AUDIT_USER_SELINUX_ERR.
> behavior. However, we've talked in the past about providing
better
> control over seccomp's auditing/logging and that work would allow you
> to quiet all seccomp messages if you desired.
>
> If you are interested, I started tracking this issue at the link below:
>
> * https://github.com/linux-audit/audit-kernel/issues/13
Making it a sysctl is fine for me as long as it is disabled by default
so that user space doesn't need to be modified to make seccomp
stop spamming.
Audit should always be opt-in, not opt-out.
Not for those who rely on it...
However I think making it conditional on syscall auditing like
in my patch is equivalent and much simpler.
If you really insist on the sysctl I can send patch.
-Andi
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
3124
days inactive
3126
days old
linux-audit@lists.linux-audit.osci.io
3 comments
3 participants
participants (3)
-
Andi Kleen -
Paul Moore -
Richard Guy Briggs