10:50 p.m.
Hi.
What is the expected handling of AUDIT_SECCOMP if audit_enabled == 0? Opera browser
makes use of a sandbox and if audit_enabled == 0 (and no auditd is running) there is a lot
of messages dumped to the klog. The fix to __audit_seccomp() is trivial, similar to
c2412d91c and I can send a patch, I'm just not sure if seccomp is somehow special?
Thanks
Tony
10:29 a.m.
On Friday, October 09, 2015 08:50:01 PM Tony Jones wrote:
Hi.
What is the expected handling of AUDIT_SECCOMP if audit_enabled == 0?
Opera browser makes use of a sandbox and if audit_enabled == 0 (and no
auditd is running) there is a lot of messages dumped to the klog. The fix
to __audit_seccomp() is trivial, similar to c2412d91c and I can send a
patch, I'm just not sure if seccomp is somehow special?
I'm adding Kees to this since he looks after the seccomp kernel bits these
days. While there isn't anything special about seccomp from an audit
perspective, the seccomp audit record can be a really nice thing as it is the
only indication you may get that seccomp has stepped in and done "something"
other than allow the syscall to progress normally.
I would be a little more concerned that you are seeing a flood of seccomp
messages from Opera, that is something that most likely warrants some closer
inspection. Are all the records the same/similar? Can you paste some into
email?
--
paul moore
www.paul-moore.com
10:40 a.m.
My apologies for the resend, I had the wrong email for Kees.
On Monday, October 12, 2015 11:29:43 AM Paul Moore wrote:
On Friday, October 09, 2015 08:50:01 PM Tony Jones wrote:
> Hi.
>
> What is the expected handling of AUDIT_SECCOMP if audit_enabled == 0?
> Opera browser makes use of a sandbox and if audit_enabled == 0 (and no
> auditd is running) there is a lot of messages dumped to the klog. The fix
> to __audit_seccomp() is trivial, similar to c2412d91c and I can send a
> patch, I'm just not sure if seccomp is somehow special?
I'm adding Kees to this since he looks after the seccomp kernel bits these
days. While there isn't anything special about seccomp from an audit
perspective, the seccomp audit record can be a really nice thing as it is
the only indication you may get that seccomp has stepped in and done
"something" other than allow the syscall to progress normally.
I would be a little more concerned that you are seeing a flood of seccomp
messages from Opera, that is something that most likely warrants some closer
inspection. Are all the records the same/similar? Can you paste some into
email?
--
paul moore
www.paul-moore.com
12:53 p.m.
On 10/12/2015 08:40 AM, Paul Moore wrote:
My apologies for the resend, I had the wrong email for Kees.
On Monday, October 12, 2015 11:29:43 AM Paul Moore wrote:
> On Friday, October 09, 2015 08:50:01 PM Tony Jones wrote:
>> Hi.
>>
>> What is the expected handling of AUDIT_SECCOMP if audit_enabled == 0?
>> Opera browser makes use of a sandbox and if audit_enabled == 0 (and no
>> auditd is running) there is a lot of messages dumped to the klog. The fix
>> to __audit_seccomp() is trivial, similar to c2412d91c and I can send a
>> patch, I'm just not sure if seccomp is somehow special?
>
> I'm adding Kees to this since he looks after the seccomp kernel bits these
> days. While there isn't anything special about seccomp from an audit
> perspective, the seccomp audit record can be a really nice thing as it is
> the only indication you may get that seccomp has stepped in and done
> "something" other than allow the syscall to progress normally.
The issue is that (without auditd running) the messages are output to klog regardless
of whether audit_enabled is 0 or 1. As I said, other occurrences of this such as with
login events has been corrected (c2412d91c). Attached patch does same for seccomp.
> I would be a little more concerned that you are seeing a flood of
seccomp
> messages from Opera, that is something that most likely warrants some closer
> inspection. Are all the records the same/similar? Can you paste some into
> email?
Here is the logged messages per invocation of opera. the use of the sandbox may well
be the result of a local suse config/packaging decision but I'm not sure that's
relevant.
2015-10-10T19:35:23.237882-07:00 nohostname kernel: [ 152.100348] audit: type=1326
audit(1444530923.236:356): auid=1000 uid=1000 gid=100 ses=1 pid=2048
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=91 compat=0 ip=0x7ff926d94ab7 code=0x50000
2015-10-10T19:35:23.242867-07:00 nohostname kernel: [ 152.105690] audit: type=1326
audit(1444530923.241:357): auid=1000 uid=1000 gid=100 ses=1 pid=2087
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=273 compat=0 ip=0x7ff928325444 code=0x50000
2015-10-10T19:35:23.242873-07:00 nohostname kernel: [ 152.105938] audit: type=1326
audit(1444530923.241:358): auid=1000 uid=1000 gid=100 ses=1 pid=2089
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=273 compat=0 ip=0x7ff928325444 code=0x50000
2015-10-10T19:35:23.243890-07:00 nohostname kernel: [ 152.106845] audit: type=1326
audit(1444530923.242:359): auid=1000 uid=1000 gid=100 ses=1 pid=2048
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=2 compat=0 ip=0x7ff926d6daa1 code=0x30000
2015-10-10T19:35:23.275872-07:00 nohostname kernel: [ 152.138819] audit: type=1326
audit(1444530923.273:360): auid=1000 uid=1000 gid=100 ses=1 pid=2093
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=91 compat=0 ip=0x7f92e4bd7ab7 code=0x50000
2015-10-10T19:35:23.275885-07:00 nohostname kernel: [ 152.138937] audit: type=1326
audit(1444530923.274:361): auid=1000 uid=1000 gid=100 ses=1 pid=2093
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=91 compat=0 ip=0x7f92e4bd7ab7 code=0x50000
2015-10-10T19:35:23.280867-07:00 nohostname kernel: [ 152.143147] audit: type=1326
audit(1444530923.279:362): auid=1000 uid=1000 gid=100 ses=1 pid=2096
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=273 compat=0 ip=0x7f92e6168444 code=0x50000
2015-10-10T19:35:23.282055-07:00 nohostname kernel: [ 152.144762] audit: type=1326
audit(1444530923.280:363): auid=1000 uid=1000 gid=100 ses=1 pid=2093
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=2 compat=0 ip=0x7f92eb5f8587 code=0x50000
2015-10-10T19:35:23.282062-07:00 nohostname kernel: [ 152.144890] audit: type=1326
audit(1444530923.280:364): auid=1000 uid=1000 gid=100 ses=1 pid=2093
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=2 compat=0 ip=0x7f92e4b2ac8c code=0x50000
2015-10-10T19:35:23.282063-07:00 nohostname kernel: [ 152.144988] audit: type=1326
audit(1444530923.280:365): auid=1000 uid=1000 gid=100 ses=1 pid=2093
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=2 compat=0 ip=0x7f92e4b2ad70 code=0x50000
thanks
tony
From d6971ec9508244f7a1ab42f9ac4c59b7e1ca6145 Mon Sep 17 00:00:00 2001
From: Tony Jones <tonyj(a)suse.de>
Date: Sat, 10 Oct 2015 19:30:49 -0700
Subject: [PATCH] Don't log seccomp messages when audit is disabled
Don't log seccomp messages when audit is disabled.
Currently, each time the opera browser is executed 10 records similar to the
following are output to klog (when !audit_enabled).
2015-10-10T19:35:23.237882-07:00 nohostname kernel: [ 152.100348] audit: type=1326
audit(1444530923.236:356): auid=1000 uid=1000 gid=100 ses=1 pid=2048
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=91 compat=0 ip=0x7ff926d94ab7 code=0x50000
Signed-off-by: Tony Jones <tonyj(a)suse.de>
---
include/linux/audit.h | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index b2abc99..8f70f3f 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -113,6 +113,12 @@ struct filename;
extern void audit_log_session_info(struct audit_buffer *ab);
+#ifdef CONFIG_AUDIT
+extern u32 audit_enabled;
+#else
+#define audit_enabled 0
+#endif
+
#ifdef CONFIG_AUDIT_COMPAT_GENERIC
#define audit_is_compat(arch) (!((arch) & __AUDIT_ARCH_64BIT))
#else
@@ -213,7 +219,7 @@ void audit_core_dumps(long signr);
static inline void audit_seccomp(unsigned long syscall, long signr, int code)
{
/* Force a record to be reported if a signal was delivered. */
- if (signr || unlikely(!audit_dummy_context()))
+ if (audit_enabled && (signr || unlikely(!audit_dummy_context())))
__audit_seccomp(syscall, signr, code);
}
@@ -498,7 +504,6 @@ extern int audit_rule_change(int type, __u32 portid, int seq,
void *data, size_t datasz);
extern int audit_list_rules_send(struct sk_buff *request_skb, int seq);
-extern u32 audit_enabled;
#else /* CONFIG_AUDIT */
static inline __printf(4, 5)
void audit_log(struct audit_context *ctx, gfp_t gfp_mask, int type,
@@ -544,7 +549,6 @@ static inline int audit_log_task_context(struct audit_buffer *ab)
static inline void audit_log_task_info(struct audit_buffer *ab,
struct task_struct *tsk)
{ }
-#define audit_enabled 0
#endif /* CONFIG_AUDIT */
static inline void audit_log_string(struct audit_buffer *ab, const char *buf)
{
--
2.1.4
3:45 p.m.
On Mon, Oct 12, 2015 at 10:53 AM, Tony Jones <tonyj(a)suse.de> wrote:
On 10/12/2015 08:40 AM, Paul Moore wrote:
> My apologies for the resend, I had the wrong email for Kees.
(I keep asking for that alias, but no luck...)
> On Monday, October 12, 2015 11:29:43 AM Paul Moore wrote:
>> On Friday, October 09, 2015 08:50:01 PM Tony Jones wrote:
>>> Hi.
>>>
>>> What is the expected handling of AUDIT_SECCOMP if audit_enabled == 0?
>>> Opera browser makes use of a sandbox and if audit_enabled == 0 (and no
>>> auditd is running) there is a lot of messages dumped to the klog. The fix
>>> to __audit_seccomp() is trivial, similar to c2412d91c and I can send a
>>> patch, I'm just not sure if seccomp is somehow special?
>>
>> I'm adding Kees to this since he looks after the seccomp kernel bits these
>> days. While there isn't anything special about seccomp from an audit
>> perspective, the seccomp audit record can be a really nice thing as it is
>> the only indication you may get that seccomp has stepped in and done
>> "something" other than allow the syscall to progress normally.
The issue is that (without auditd running) the messages are output to klog regardless
of whether audit_enabled is 0 or 1. As I said, other occurrences of this such as with
login events has been corrected (c2412d91c). Attached patch does same for seccomp.
>> I would be a little more concerned that you are seeing a flood of seccomp
>> messages from Opera, that is something that most likely warrants some closer
>> inspection. Are all the records the same/similar? Can you paste some into
>> email?
Here is the logged messages per invocation of opera. the use of the sandbox may well
be the result of a local suse config/packaging decision but I'm not sure that's
relevant.
2015-10-10T19:35:23.237882-07:00 nohostname kernel: [ 152.100348] audit: type=1326
audit(1444530923.236:356): auid=1000 uid=1000 gid=100 ses=1 pid=2048
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=91 compat=0 ip=0x7ff926d94ab7 code=0x50000
2015-10-10T19:35:23.242867-07:00 nohostname kernel: [ 152.105690] audit: type=1326
audit(1444530923.241:357): auid=1000 uid=1000 gid=100 ses=1 pid=2087
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=273 compat=0 ip=0x7ff928325444 code=0x50000
2015-10-10T19:35:23.242873-07:00 nohostname kernel: [ 152.105938] audit: type=1326
audit(1444530923.241:358): auid=1000 uid=1000 gid=100 ses=1 pid=2089
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=273 compat=0 ip=0x7ff928325444 code=0x50000
2015-10-10T19:35:23.243890-07:00 nohostname kernel: [ 152.106845] audit: type=1326
audit(1444530923.242:359): auid=1000 uid=1000 gid=100 ses=1 pid=2048
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=2 compat=0 ip=0x7ff926d6daa1 code=0x30000
2015-10-10T19:35:23.275872-07:00 nohostname kernel: [ 152.138819] audit: type=1326
audit(1444530923.273:360): auid=1000 uid=1000 gid=100 ses=1 pid=2093
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=91 compat=0 ip=0x7f92e4bd7ab7 code=0x50000
2015-10-10T19:35:23.275885-07:00 nohostname kernel: [ 152.138937] audit: type=1326
audit(1444530923.274:361): auid=1000 uid=1000 gid=100 ses=1 pid=2093
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=91 compat=0 ip=0x7f92e4bd7ab7 code=0x50000
2015-10-10T19:35:23.280867-07:00 nohostname kernel: [ 152.143147] audit: type=1326
audit(1444530923.279:362): auid=1000 uid=1000 gid=100 ses=1 pid=2096
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=273 compat=0 ip=0x7f92e6168444 code=0x50000
2015-10-10T19:35:23.282055-07:00 nohostname kernel: [ 152.144762] audit: type=1326
audit(1444530923.280:363): auid=1000 uid=1000 gid=100 ses=1 pid=2093
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=2 compat=0 ip=0x7f92eb5f8587 code=0x50000
2015-10-10T19:35:23.282062-07:00 nohostname kernel: [ 152.144890] audit: type=1326
audit(1444530923.280:364): auid=1000 uid=1000 gid=100 ses=1 pid=2093
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=2 compat=0 ip=0x7f92e4b2ac8c code=0x50000
2015-10-10T19:35:23.282063-07:00 nohostname kernel: [ 152.144988] audit: type=1326
audit(1444530923.280:365): auid=1000 uid=1000 gid=100 ses=1 pid=2093
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=2 compat=0 ip=0x7f92e4b2ad70 code=0x50000
thanks
tony
From d6971ec9508244f7a1ab42f9ac4c59b7e1ca6145 Mon Sep 17 00:00:00 2001
From: Tony Jones <tonyj(a)suse.de>
Date: Sat, 10 Oct 2015 19:30:49 -0700
Subject: [PATCH] Don't log seccomp messages when audit is disabled
Don't log seccomp messages when audit is disabled.
This is intentional since violation of a seccomp policy ought to
indicate a misbehaving program, and we want these to always be
presented to the system log, regardless of audit being enabled. (I'd
like to even produce system log entries when there is no CONFIG_AUDIT
too, but that's for the future.)
Currently, each time the opera browser is executed 10 records similar
to the
following are output to klog (when !audit_enabled).
2015-10-10T19:35:23.237882-07:00 nohostname kernel: [ 152.100348] audit: type=1326
audit(1444530923.236:356): auid=1000 uid=1000 gid=100 ses=1 pid=2048
comm="opera" exe="/usr/lib64/opera/opera" sig=0 arch=c000003e
syscall=91 compat=0 ip=0x7ff926d94ab7 code=0x50000
However, these are all sig=0, which would indicate a skipped syscall,
which I wouldn't expect to get reported at all.
Signed-off-by: Tony Jones <tonyj(a)suse.de>
---
include/linux/audit.h | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index b2abc99..8f70f3f 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -113,6 +113,12 @@ struct filename;
extern void audit_log_session_info(struct audit_buffer *ab);
+#ifdef CONFIG_AUDIT
+extern u32 audit_enabled;
+#else
+#define audit_enabled 0
+#endif
+
#ifdef CONFIG_AUDIT_COMPAT_GENERIC
#define audit_is_compat(arch) (!((arch) & __AUDIT_ARCH_64BIT))
#else
@@ -213,7 +219,7 @@ void audit_core_dumps(long signr);
static inline void audit_seccomp(unsigned long syscall, long signr, int code)
{
/* Force a record to be reported if a signal was delivered. */
- if (signr || unlikely(!audit_dummy_context()))
What is dummy_context part of this actually do? I don't think reports
should be made when signr == 0.
-Kees
+ if (audit_enabled && (signr ||
unlikely(!audit_dummy_context())))
__audit_seccomp(syscall, signr, code);
}
@@ -498,7 +504,6 @@ extern int audit_rule_change(int type, __u32 portid, int seq,
void *data, size_t datasz);
extern int audit_list_rules_send(struct sk_buff *request_skb, int seq);
-extern u32 audit_enabled;
#else /* CONFIG_AUDIT */
static inline __printf(4, 5)
void audit_log(struct audit_context *ctx, gfp_t gfp_mask, int type,
@@ -544,7 +549,6 @@ static inline int audit_log_task_context(struct audit_buffer *ab)
static inline void audit_log_task_info(struct audit_buffer *ab,
struct task_struct *tsk)
{ }
-#define audit_enabled 0
#endif /* CONFIG_AUDIT */
static inline void audit_log_string(struct audit_buffer *ab, const char *buf)
{
--
2.1.4
--
Kees Cook
Chrome OS Security
11:11 a.m.
On Mon, Oct 12, 2015 at 4:45 PM, Kees Cook <keescook(a)chromium.org> wrote:
On Mon, Oct 12, 2015 at 10:53 AM, Tony Jones <tonyj(a)suse.de>
wrote:
> From d6971ec9508244f7a1ab42f9ac4c59b7e1ca6145 Mon Sep 17 00:00:00 2001
> From: Tony Jones <tonyj(a)suse.de>
> Date: Sat, 10 Oct 2015 19:30:49 -0700
> Subject: [PATCH] Don't log seccomp messages when audit is disabled
>
> Don't log seccomp messages when audit is disabled.
This is intentional since violation of a seccomp policy ought to
indicate a misbehaving program, and we want these to always be
presented to the system log, regardless of audit being enabled. (I'd
like to even produce system log entries when there is no CONFIG_AUDIT
too, but that's for the future.)
I agree. As I mentioned earlier these AUDIT_SECCOMP records are very handy.
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index b2abc99..8f70f3f 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -113,6 +113,12 @@ struct filename;
>
> extern void audit_log_session_info(struct audit_buffer *ab);
>
> +#ifdef CONFIG_AUDIT
> +extern u32 audit_enabled;
> +#else
> +#define audit_enabled 0
> +#endif
> +
> #ifdef CONFIG_AUDIT_COMPAT_GENERIC
> #define audit_is_compat(arch) (!((arch) & __AUDIT_ARCH_64BIT))
> #else
> @@ -213,7 +219,7 @@ void audit_core_dumps(long signr);
> static inline void audit_seccomp(unsigned long syscall, long signr, int code)
> {
> /* Force a record to be reported if a signal was delivered. */
> - if (signr || unlikely(!audit_dummy_context()))
What is dummy_context part of this actually do? I don't think reports
should be made when signr == 0.
The idea behind audit_dummy_context() is to skip auditing when there
are no audit rules configured, it's a performance tweak. My guess is
that Tony's system loads some audit configuration at boot which
enables audit (the kernel starts with audit_enabled=0 ...) and loads a
few syscall filter rules which are enough to make
audit_dummy_context() return false. Can you confirm that Tony?
As for logging seccomp actions when signr == 0, I personally think
that still might be useful as the normal behavior has been altered; I
tend to think any action != ALLOW is worth logging. However, I'm open
to discussion on this if others feel strongly.
> + if (audit_enabled && (signr ||
unlikely(!audit_dummy_context())))
> __audit_seccomp(syscall, signr, code);
> }
--
paul moore
www.paul-moore.com
12:18 p.m.
On 10/13/2015 09:11 AM, Paul Moore wrote:
On Mon, Oct 12, 2015 at 4:45 PM, Kees Cook
<keescook(a)chromium.org> wrote:
> On Mon, Oct 12, 2015 at 10:53 AM, Tony Jones <tonyj(a)suse.de> wrote:
>> From d6971ec9508244f7a1ab42f9ac4c59b7e1ca6145 Mon Sep 17 00:00:00 2001
>> From: Tony Jones <tonyj(a)suse.de>
>> Date: Sat, 10 Oct 2015 19:30:49 -0700
>> Subject: [PATCH] Don't log seccomp messages when audit is disabled
>>
>> Don't log seccomp messages when audit is disabled.
>
> This is intentional since violation of a seccomp policy ought to
> indicate a misbehaving program, and we want these to always be
> presented to the system log, regardless of audit being enabled. (I'd
> like to even produce system log entries when there is no CONFIG_AUDIT
> too, but that's for the future.)
I agree. As I mentioned earlier these AUDIT_SECCOMP records are very handy.
>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>> index b2abc99..8f70f3f 100644
>> --- a/include/linux/audit.h
>> +++ b/include/linux/audit.h
>> @@ -113,6 +113,12 @@ struct filename;
>>
>> extern void audit_log_session_info(struct audit_buffer *ab);
>>
>> +#ifdef CONFIG_AUDIT
>> +extern u32 audit_enabled;
>> +#else
>> +#define audit_enabled 0
>> +#endif
>> +
>> #ifdef CONFIG_AUDIT_COMPAT_GENERIC
>> #define audit_is_compat(arch) (!((arch) & __AUDIT_ARCH_64BIT))
>> #else
>> @@ -213,7 +219,7 @@ void audit_core_dumps(long signr);
>> static inline void audit_seccomp(unsigned long syscall, long signr, int code)
>> {
>> /* Force a record to be reported if a signal was delivered. */
>> - if (signr || unlikely(!audit_dummy_context()))
>
> What is dummy_context part of this actually do? I don't think reports
> should be made when signr == 0.
The idea behind audit_dummy_context() is to skip auditing when there
are no audit rules configured, it's a performance tweak. My guess is
that Tony's system loads some audit configuration at boot which
enables audit (the kernel starts with audit_enabled=0 ...) and loads a
few syscall filter rules which are enough to make
audit_dummy_context() return false. Can you confirm that Tony?
No, it's the default audit.rules (-D, -b320). No actual rules loaded.
Let me add some instrumentation and figure out what's going on. auditd
is masked (via systemd) but systemd-journal seems to set audit_enabled=1
during startup (at least on our systems).
As for logging seccomp actions when signr == 0, I personally think
that still might be useful as the normal behavior has been altered; I
tend to think any action != ALLOW is worth logging. However, I'm open
to discussion on this if others feel strongly.
>> + if (audit_enabled && (signr ||
unlikely(!audit_dummy_context())))
>> __audit_seccomp(syscall, signr, code);
>> }
I'm of the opinion that nothing should get output (through the audit system) if
audit_enabled == 0. What you advocate calls for more than 2 possible states for
audit_enabled or logging the information through another mechanism than audit.
Tony
2:19 p.m.
On Tue, Oct 13, 2015 at 1:18 PM, Tony Jones <tonyj(a)suse.de> wrote:
On 10/13/2015 09:11 AM, Paul Moore wrote:
> On Mon, Oct 12, 2015 at 4:45 PM, Kees Cook <keescook(a)chromium.org> wrote:
>> On Mon, Oct 12, 2015 at 10:53 AM, Tony Jones <tonyj(a)suse.de> wrote:
>>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>>> index b2abc99..8f70f3f 100644
>>> --- a/include/linux/audit.h
>>> +++ b/include/linux/audit.h
>>> @@ -113,6 +113,12 @@ struct filename;
>>>
>>> extern void audit_log_session_info(struct audit_buffer *ab);
>>>
>>> +#ifdef CONFIG_AUDIT
>>> +extern u32 audit_enabled;
>>> +#else
>>> +#define audit_enabled 0
>>> +#endif
>>> +
>>> #ifdef CONFIG_AUDIT_COMPAT_GENERIC
>>> #define audit_is_compat(arch) (!((arch) & __AUDIT_ARCH_64BIT))
>>> #else
>>> @@ -213,7 +219,7 @@ void audit_core_dumps(long signr);
>>> static inline void audit_seccomp(unsigned long syscall, long signr, int
code)
>>> {
>>> /* Force a record to be reported if a signal was delivered. */
>>> - if (signr || unlikely(!audit_dummy_context()))
>>
>> What is dummy_context part of this actually do? I don't think reports
>> should be made when signr == 0.
>
> The idea behind audit_dummy_context() is to skip auditing when there
> are no audit rules configured, it's a performance tweak. My guess is
> that Tony's system loads some audit configuration at boot which
> enables audit (the kernel starts with audit_enabled=0 ...) and loads a
> few syscall filter rules which are enough to make
> audit_dummy_context() return false. Can you confirm that Tony?
No, it's the default audit.rules (-D, -b320). No actual rules loaded.
Let me add some instrumentation and figure out what's going on. auditd
is masked (via systemd) but systemd-journal seems to set audit_enabled=1
during startup (at least on our systems).
Yes, if systemd is involved it enables audit; we've had some
discussions with the systemd folks about fixing that, but they haven't
gone very far. I'm still a little curious as to why
audit_dummy_context() is false in this case, but I haven't looked at
how systemd/auditctl start/config the system too closely.
> As for logging seccomp actions when signr == 0, I personally
think
> that still might be useful as the normal behavior has been altered; I
> tend to think any action != ALLOW is worth logging. However, I'm open
> to discussion on this if others feel strongly.
>
>>> + if (audit_enabled && (signr ||
unlikely(!audit_dummy_context())))
>>> __audit_seccomp(syscall, signr, code);
>>> }
I'm of the opinion that nothing should get output (through the audit system) if
audit_enabled == 0. What you advocate calls for more than 2 possible states for
audit_enabled or logging the information through another mechanism than audit.
I don't really care if it is audit or not (although we will need to
output something via audit if it is enabled to keep the CC crowd
happy); if you feel strongly that it isn't audit, we can just make it
a printk, that would work well with Kees' goals. To me the important
point here is that we send a message when seccomp alters the behavior
of the syscall (action != ALLOW).
--
paul moore
www.paul-moore.com
2:46 p.m.
On 10/13/2015 12:19 PM, Paul Moore wrote:
> No, it's the default audit.rules (-D, -b320). No actual
rules loaded.
> Let me add some instrumentation and figure out what's going on. auditd
> is masked (via systemd) but systemd-journal seems to set audit_enabled=1
> during startup (at least on our systems).
Yes, if systemd is involved it enables audit; we've had some
discussions with the systemd folks about fixing that, but they haven't
gone very far. I'm still a little curious as to why
audit_dummy_context() is false in this case, but I haven't looked at
how systemd/auditctl start/config the system too closely.
I'll debug what's going on (easy) on the test system and report back. I'm
curious
too. Have a bad cold today so I'm moving slower than normal.
I don't really care if it is audit or not (although we will need
to
output something via audit if it is enabled to keep the CC crowd
happy); if you feel strongly that it isn't audit, we can just make it
a printk, that would work well with Kees' goals. To me the important
point here is that we send a message when seccomp alters the behavior
of the syscall (action != ALLOW).
Yes, if audit is enabled, you should totally be able to use it. Rest sounds good also.
thanks!
Tony
3:03 p.m.
No, it's the default audit.rules (-D, -b320). No actual rules
loaded.
Let me add some instrumentation and figure out what's going on. auditd
is masked (via systemd) but systemd-journal seems to set audit_enabled=1
during startup (at least on our systems).
Tony,
We have bz 1227379
https://bugzilla.redhat.com/show_bug.cgi?id=1227379
There is a patch attached to disable systemd's propensity to turn on the audit
system. Are people complaining and opening bugs in your distribution? If so,
that might add more ammunition to get that fixed.
On Tuesday, October 13, 2015 03:19:20 PM Paul Moore wrote:
> I'm of the opinion that nothing should get output (through
the audit
> system) if audit_enabled == 0. What you advocate calls for more than 2
> possible states for audit_enabled or logging the information through
> another mechanism than audit.
I don't really care if it is audit or not (although we will need to
output something via audit if it is enabled to keep the CC crowd
happy);
The rules for CC are that any access decision must be auditable and selective.
That means that we need to be able to choose if we want to audit success,
and/or failure, and/or nothing.
The inability to turn off SE Linux AVCs in the audit logs is why the exclude
filter was created. Seccomp could be the same way.
-Steve
if you feel strongly that it isn't audit, we can just make it
a printk, that would work well with Kees' goals. To me the important
point here is that we send a message when seccomp alters the behavior
of the syscall (action != ALLOW).
3:45 p.m.
On 10/13/2015 01:03 PM, Steve Grubb wrote:
> No, it's the default audit.rules (-D, -b320). No actual
rules loaded.
> Let me add some instrumentation and figure out what's going on. auditd
> is masked (via systemd) but systemd-journal seems to set audit_enabled=1
> during startup (at least on our systems).
Tony,
We have bz 1227379
https://bugzilla.redhat.com/show_bug.cgi?id=1227379
There is a patch attached to disable systemd's propensity to turn on the audit
system. Are people complaining and opening bugs in your distribution? If so,
that might add more ammunition to get that fixed.
Hi Steve
we only have the one bug and it's related to:
1) noisy klog between when systemd enables audit and user manually disables it (rh
bz#1160046)
2) after user manually disables audit (audit_enabled=0) seccomp messages still are
output.
tony
3:36 p.m.
On 10/13/2015 12:19 PM, Paul Moore wrote:
Yes, if systemd is involved it enables audit; we've had some
discussions with the systemd folks about fixing that, but they haven't
gone very far. I'm still a little curious as to why
audit_dummy_context() is false in this case, but I haven't looked at
how systemd/auditctl start/config the system too closely.
Sorry for the delay here.
A context is allocated by audit_alloc() because there is no uid/gid filter for the task
but the dummy flag is left false. Because audit has been disabled (manually following
systemd enabling),
dummy never gets set in the syscall entry path (based on !audit_n_rules). So the
unlikely(!audit_dummy_context())
in audit_seccomp succeeds.
Tony
11:51 a.m.
On 11/06/2015 01:36 PM, Tony Jones wrote:
On 10/13/2015 12:19 PM, Paul Moore wrote:
> Yes, if systemd is involved it enables audit; we've had some
> discussions with the systemd folks about fixing that, but they haven't
> gone very far. I'm still a little curious as to why
> audit_dummy_context() is false in this case, but I haven't looked at
> how systemd/auditctl start/config the system too closely.
Sorry for the delay here.
A context is allocated by audit_alloc() because there is no uid/gid filter for the task
but the dummy flag is left false. Because audit has been disabled (manually following
systemd enabling),
dummy never gets set in the syscall entry path (based on !audit_n_rules). So the
unlikely(!audit_dummy_context())
in audit_seccomp succeeds.
Tony
Any comments on this? Current interaction between enabled_enabled and dummy flag seems
wrong to me. I can code up
a patch.
Tony
3:26 p.m.
On Fri, Nov 20, 2015 at 12:51 PM, Tony Jones <tonyj(a)suse.de> wrote:
Any comments on this? Current interaction between enabled_enabled
and dummy flag seems wrong to me. I can code up
a patch.
It's on my todo list for this development cycle, I've just been a
little busy lately with the merge window and now some -rc1 testing.
--
paul moore
www.paul-moore.com
3319
days inactive
3360
days old
linux-audit@lists.linux-audit.osci.io
13 comments
4 participants
participants (4)
-
Kees Cook -
Paul Moore -
Steve Grubb -
Tony Jones