Re: [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 Kleenwrote: > > >> 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 > > >> 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 Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635
Re: [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 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 > > >> 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 Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Mon, Apr 11, 2016 at 12:07 AM, Andi Kleenwrote: > On Sun, Apr 10, 2016 at 10:30:10PM -0400, Paul Moore wrote: >> On Sun, Apr 10, 2016 at 6:31 PM, 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 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 >> >> >> 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. > > Nothing has appeared by now. A mailing list that does not allow > real time discussion is fairly useless. > > Dropped again. Re-added. There is always value in having the conversation archived. -- paul moore www.paul-moore.com
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Mon, Apr 11, 2016 at 12:07 AM, Andi Kleen wrote: > On Sun, Apr 10, 2016 at 10:30:10PM -0400, Paul Moore wrote: >> On Sun, Apr 10, 2016 at 6:31 PM, 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 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 >> >> >> 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. > > Nothing has appeared by now. A mailing list that does not allow > real time discussion is fairly useless. > > Dropped again. Re-added. There is always value in having the conversation archived. -- paul moore www.paul-moore.com
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Sun, Apr 10, 2016 at 10:30:10PM -0400, Paul Moore wrote: > On Sun, Apr 10, 2016 at 6:31 PM, Andi Kleenwrote: > > On Sun, Apr 10, 2016 at 06:17:53PM -0400, Paul Moore wrote: > >> On Sat, Apr 9, 2016 at 10:41 PM, Andi Kleen 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 > >> >> 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. Nothing has appeared by now. A mailing list that does not allow real time discussion is fairly useless. Dropped again. > >> 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. It wants an audit channel, but not random kernel subsystems unconditionally spamming the logs. If it wanted the later it would set audit rules. > > > 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. Ok I'm sending an updated patch. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Sun, Apr 10, 2016 at 10:30:10PM -0400, Paul Moore wrote: > On Sun, Apr 10, 2016 at 6:31 PM, 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 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 > >> >> 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. Nothing has appeared by now. A mailing list that does not allow real time discussion is fairly useless. Dropped again. > >> 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. It wants an audit channel, but not random kernel subsystems unconditionally spamming the logs. If it wanted the later it would set audit rules. > > > 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. Ok I'm sending an updated patch. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Sun, Apr 10, 2016 at 6:31 PM, Andi Kleenwrote: > On Sun, Apr 10, 2016 at 06:17:53PM -0400, Paul Moore wrote: >> On Sat, Apr 9, 2016 at 10:41 PM, Andi Kleen 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 >> >> 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
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Sun, Apr 10, 2016 at 6:31 PM, 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 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 >> >> 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
Re: [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 Kleenwrote: > >> 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 > >> 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
Re: [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 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 > >> 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
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Sat, Apr 9, 2016 at 10:41 PM, Andi Kleenwrote: >> 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 >> 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
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Sat, Apr 9, 2016 at 10:41 PM, Andi Kleen 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 >> 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
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
> 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> 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. -Andi
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
> 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 > 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. -Andi
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Sat, Apr 9, 2016 at 11:07 AM, Andi Kleenwrote: > From: Andi Kleen > > When I run chrome on my opensuse system every time I open > a new tab the system log is spammed with: > > audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857 > comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c03e > syscall=273 compat=0 ip=0x7fe27c11a444 code=0x5 > > This happens because chrome uses SECCOMP for its sandbox, > and for some reason always reaches a SECCOMP_KILL or more likely > SECCOMP_RET_ERRNO in the rule set. > > The seccomp auditing was originally added ... Hi Andi, What kernel version are you using? I believe we fixed that in Linux 4.5 with the following: commit 96368701e1c89057bbf39222e965161c68a85b4b From: Paul Moore Date: Wed, 13 Jan 2016 10:18:55 -0400 (09:18 -0500) audit: force seccomp event logging to honor the audit_enabled flag Previously we were emitting seccomp audit records regardless of the audit_enabled setting, a deparature from the rest of audit. This patch makes seccomp auditing consistent with the rest of the audit record generation code in that when audit_enabled=0 nothing is logged by the audit subsystem. The bulk of this patch is moving the CONFIG_AUDIT block ahead of the CONFIG_AUDITSYSCALL block in include/linux/audit.h; the only real code change was in the audit_seccomp() definition. Signed-off-by: Tony Jones Signed-off-by: Paul Moore -- paul moore www.paul-moore.com
Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
On Sat, Apr 9, 2016 at 11:07 AM, Andi Kleen wrote: > From: Andi Kleen > > When I run chrome on my opensuse system every time I open > a new tab the system log is spammed with: > > audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857 > comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c03e > syscall=273 compat=0 ip=0x7fe27c11a444 code=0x5 > > This happens because chrome uses SECCOMP for its sandbox, > and for some reason always reaches a SECCOMP_KILL or more likely > SECCOMP_RET_ERRNO in the rule set. > > The seccomp auditing was originally added ... Hi Andi, What kernel version are you using? I believe we fixed that in Linux 4.5 with the following: commit 96368701e1c89057bbf39222e965161c68a85b4b From: Paul Moore Date: Wed, 13 Jan 2016 10:18:55 -0400 (09:18 -0500) audit: force seccomp event logging to honor the audit_enabled flag Previously we were emitting seccomp audit records regardless of the audit_enabled setting, a deparature from the rest of audit. This patch makes seccomp auditing consistent with the rest of the audit record generation code in that when audit_enabled=0 nothing is logged by the audit subsystem. The bulk of this patch is moving the CONFIG_AUDIT block ahead of the CONFIG_AUDITSYSCALL block in include/linux/audit.h; the only real code change was in the audit_seccomp() definition. Signed-off-by: Tony Jones Signed-off-by: Paul Moore -- paul moore www.paul-moore.com
[PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
From: Andi KleenWhen I run chrome on my opensuse system every time I open a new tab the system log is spammed with: audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c03e syscall=273 compat=0 ip=0x7fe27c11a444 code=0x5 This happens because chrome uses SECCOMP for its sandbox, and for some reason always reaches a SECCOMP_KILL or more likely SECCOMP_RET_ERRNO in the rule set. The seccomp auditing was originally added by Eric with commit 85e7bac33b8d5edafc4e219c7dfdb3d48e0b4e31 Author: Eric Paris Date: Tue Jan 3 14:23:05 2012 -0500 seccomp: audit abnormal end to a process due to seccomp The audit system likes to collect information about processes that end abnormally (SIGSEGV) as this may me useful intrusion detection information. This patch adds audit support to collect information when seccomp forces a task to exit because of misbehavior in a similar way. I don't have any other syscall auditing enabled, just the standard user space auditing used by the systemd and PAM userland. So basic auditing is alwas enabled, but no other kernel auditing. I don't think it makes much sense to only log seccomp events when nothing else is audited by the kernel. So make the seccomp auditing depend on syscall auditing being enabled. This stops the log spam on my system, and still gives the information on system with heavier auditing enabled. Cc: epa...@redhat.com Signed-off-by: Andi Kleen --- include/linux/audit.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/audit.h b/include/linux/audit.h index e38e3fc..379970f 100644 --- a/include/linux/audit.h +++ b/include/linux/audit.h @@ -317,7 +317,7 @@ void audit_core_dumps(long signr); static inline void audit_seccomp(unsigned long syscall, long signr, int code) { - if (!audit_enabled) + if (!audit_enabled || !test_thread_flag(TIF_SYSCALL_AUDIT)) return; /* Force a record to be reported if a signal was delivered. */ -- 2.7.4
[PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled
From: Andi Kleen When I run chrome on my opensuse system every time I open a new tab the system log is spammed with: audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c03e syscall=273 compat=0 ip=0x7fe27c11a444 code=0x5 This happens because chrome uses SECCOMP for its sandbox, and for some reason always reaches a SECCOMP_KILL or more likely SECCOMP_RET_ERRNO in the rule set. The seccomp auditing was originally added by Eric with commit 85e7bac33b8d5edafc4e219c7dfdb3d48e0b4e31 Author: Eric Paris Date: Tue Jan 3 14:23:05 2012 -0500 seccomp: audit abnormal end to a process due to seccomp The audit system likes to collect information about processes that end abnormally (SIGSEGV) as this may me useful intrusion detection information. This patch adds audit support to collect information when seccomp forces a task to exit because of misbehavior in a similar way. I don't have any other syscall auditing enabled, just the standard user space auditing used by the systemd and PAM userland. So basic auditing is alwas enabled, but no other kernel auditing. I don't think it makes much sense to only log seccomp events when nothing else is audited by the kernel. So make the seccomp auditing depend on syscall auditing being enabled. This stops the log spam on my system, and still gives the information on system with heavier auditing enabled. Cc: epa...@redhat.com Signed-off-by: Andi Kleen --- include/linux/audit.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/audit.h b/include/linux/audit.h index e38e3fc..379970f 100644 --- a/include/linux/audit.h +++ b/include/linux/audit.h @@ -317,7 +317,7 @@ void audit_core_dumps(long signr); static inline void audit_seccomp(unsigned long syscall, long signr, int code) { - if (!audit_enabled) + if (!audit_enabled || !test_thread_flag(TIF_SYSCALL_AUDIT)) return; /* Force a record to be reported if a signal was delivered. */ -- 2.7.4