GPF in keyring_destroy

[Dmitry Vyukov]

Hello,

The following program crashes kernel:

// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include 
#include 
#include 

int main()
{
long r0 = syscall(SYS_mmap, 0x20001000ul, 0x1000ul, 0x3ul,
0x32ul, 0xul, 0x0ul);
long r1 = syscall(SYS_mmap, 0x2000ul, 0x1000ul, 0x3ul,
0x32ul, 0xul, 0x0ul);
*(uint64_t*)0x2131 = 0x947;
*(uint64_t*)0x2139 = 0xa9be;
*(uint64_t*)0x2141 = 0x4;
*(uint64_t*)0x2149 = 0xfff8;
*(uint64_t*)0x2151 = 0x3;
*(uint64_t*)0x2159 = 0x1;
*(uint64_t*)0x2161 = 0x7;
*(uint64_t*)0x2169 = 0x3b;
long r11 = syscall(SYS_mmap, 0x20002000ul, 0x1000ul, 0x3ul,
0x32ul, 0xul, 0x0ul);
memcpy((void*)0x20002000,
"\x5d\x27\x7b\x65\x63\x72\x79\x70\x74\x66\x73\x5c\x73\x65\x6c\x69\x6e\x75\x78\x6e\x66\x73\x00",
23);
memcpy((void*)0x20001ff4,
"\x23\x73\x65\x6c\x69\x6e\x75\x78\x2c\x62\x64\x65\x76\x72\x61\x6d\x66\x73\xe6\x68\x66\x73\x70\x6c\x75\x73\x7b\x2c\x28\x72\x6f\x6f\x74\x66\x73\x00",
36);
memcpy((void*)0x20002000, "\x6b\x65\x79\x72\x69\x6e\x67\x00", 8);
long r16 = syscall(SYS_request_key, 0x20002000ul,
0x20001ff4ul, 0x20002000ul, 0xfffbul, 0, 0);
memcpy((void*)0x20002000,
"\x5d\x27\x7b\x65\x63\x72\x79\x70\x74\x66\x73\x5c\x73\x65\x6c\x69\x6e\x75\x78\x6e\x66\x73\x00",
23);
memcpy((void*)0x20001ff4,
"\x23\x73\x65\x6c\x69\x6e\x75\x78\x2c\x62\x64\x65\x76\x72\x61\x6d\x66\x73\xe6\x68\x66\x73\x70\x6c\x75\x73\x7b\x2c\x28\x72\x6f\x6f\x74\x66\x73\x00",
36);
memcpy((void*)0x20002000, "\x6b\x65\x79\x72\x69\x6e\x67\x00", 8);
long r20 = syscall(SYS_request_key, 0x20002000ul,
0x20001ff4ul, 0x20002000ul, 0xfffbul, 0, 0);
memcpy((void*)0x20002000,
"\x5d\x27\x7b\x65\x63\x72\x79\x70\x74\x66\x73\x5c\x73\x65\x6c\x69\x6e\x75\x78\x6e\x66\x73\x00",
23);
memcpy((void*)0x20001ff4,
"\x23\x73\x65\x6c\x69\x6e\x75\x78\x2c\x62\x64\x65\x76\x72\x61\x6d\x66\x73\xe6\x68\x66\x73\x70\x6c\x75\x73\x7b\x2c\x28\x72\x6f\x6f\x74\x66\x73\x00",
36);
memcpy((void*)0x20002000, "\x6b\x65\x79\x72\x69\x6e\x67\x00", 8);
long r24 = syscall(SYS_request_key, 0x20002000ul,
0x20001ff4ul, 0x20002000ul, 0xfffbul, 0, 0);
return 0;
}

To reproduce run the program several times, then wait a minute, run
again, repeat until crashes (the crash happens in a background thread
during deferred garbage collection).

Found with syzkaller fuzzer.

On commit c6fa8e6de3dc420cba092bf155b2ed25bcd537f7
(git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)


BUG: unable to handle kernel paging request at ff8a
IP: [< inline >] list_del include/linux/list.h:107
IP: [] keyring_destroy+0x3d/0x80 security/keys/keyring.c:392
PGD 0
Oops: 0002 [#1] SMP KASAN
Modules linked in:
CPU: 2 PID: 505 Comm: kworker/2:1 Not tainted 4.3.0-rc4+ #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events key_garbage_collector
task: 88006dd93400 ti: 88006dd68000 task.ti: 88006dd68000
RIP: 0010:[]  [] keyring_destroy+0x3d/0x80
RSP: 0018:88006dd6fda8  EFLAGS: 00010213
RAX: ff82 RBX: 88006d73bc00 RCX: 
RDX:  RSI: 88006dd93400 RDI: 821077a0
RBP: 88006dd6fdb0 R08: 88006dd68000 R09: 88006dd93d40
R10: 072c R11: 0001 R12: 88006d73bc00
R13: 7fff R14: 88006dd7 R15: 
FS:  () GS:88006e80() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: ff8a CR3: 6cda6000 CR4: 06e0
Stack:
 88006d73bc08 88006dd6fdd0 81290131 
 56177c32 88006dd6fe18 81290391 88006e626d28
  81e812a0 88006e746080 88006e81d8c0
Call Trace:
 [] key_gc_unused_keys.constprop.1+0xa1/0xf0
security/keys/gc.c:139
 [] key_garbage_collector+0x1a1/0x360 security/keys/gc.c:294
 [] process_one_work+0x13e/0x3c0 kernel/workqueue.c:2030
 [] worker_thread+0x115/0x450 kernel/workqueue.c:2162
 [< inline >] ? context_switch kernel/sched/core.c:2651
 [] ? __schedule+0x311/0x7e0 kernel/sched/core.c:3115
 [] ? process_one_work+0x3c0/0x3c0
kernel/workqueue.c:1973 (discriminator 1)
 [] kthread+0xc4/0xe0 kernel/kthread.c:209
 [] ? kthread_park+0x50/0x50 kernel/kthread.c:448
 [] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:472
 [] ? kthread_park+0x50/0x50 kernel/kthread.c:448
Code: 48 c7 c7 a0 77 10 82 e8 f2 a8 5a 00 48 8b 83 98 00 00 00 48 85
c0 74 36 48 8d 93 98 00 00 00 48 39 d0 74 2a 48 8b 93 a0 00 00 00 <48>
89 50 08 48 89 02 48 b8 00 01 00 00 00 00 ad de 48 89 83 98
RIP  [< inline >] list_del include/linux/list.h:107
RIP  [] keyring_destroy+0x3d/0x80 security/keys/keyring.c:392
 RSP 
CR2: ff8a
---[ end 

[PATCH] Introduces generic __list_splice_init_rcu();

[Petko Manolov]

__list_splice_init_rcu() can be used to splice lists forming both stack and
queue structures, depending on its arguments.  It is based on the initial
list_splice_init_rcu() with a few minor modifications to help abstrancting it.

Signed-off-by: Petko Manolov 
---
 include/linux/rculist.h | 69 +++--
 1 file changed, 49 insertions(+), 20 deletions(-)

diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index 5ed5409..e99d834 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -179,32 +179,31 @@ static inline void list_replace_rcu(struct list_head *old,
 }
 
 /**
- * list_splice_init_rcu - splice an RCU-protected list into an existing list.
+ * __list_splice_init_rcu - join an RCU-protected list into an existing list.
  * @list:  the RCU-protected list to splice
- * @head:  the place in the list to splice the first list into
+ * @prev:  points to the last element of the existing list
+ * @next:  points to the first element of the existing list
  * @sync:  function to sync: synchronize_rcu(), synchronize_sched(), ...
  *
- * @head can be RCU-read traversed concurrently with this function.
+ * The list pointed to by @prev and @next can be RCU-read traversed
+ * concurrently with this function.
  *
  * Note that this function blocks.
  *
- * Important note: the caller must take whatever action is necessary to
- * prevent any other updates to @head.  In principle, it is possible
- * to modify the list as soon as sync() begins execution.
- * If this sort of thing becomes necessary, an alternative version
- * based on call_rcu() could be created.  But only if -really-
- * needed -- there is no shortage of RCU API members.
+ * Important note: the caller must take whatever action is necessary to prevent
+ * any other updates to the existing list.  In principle, it is possible to
+ * modify the list as soon as sync() begins execution. If this sort of thing
+ * becomes necessary, an alternative version based on call_rcu() could be
+ * created.  But only if -really- needed -- there is no shortage of RCU API
+ * members.
  */
-static inline void list_splice_init_rcu(struct list_head *list,
-   struct list_head *head,
-   void (*sync)(void))
+static inline void __list_splice_init_rcu(struct list_head *list,
+ struct list_head *prev,
+ struct list_head *next,
+ void (*sync)(void))
 {
struct list_head *first = list->next;
struct list_head *last = list->prev;
-   struct list_head *at = head->next;
-
-   if (list_empty(list))
-   return;
 
/*
 * "first" and "last" tracking list, so initialize it.  RCU readers
@@ -231,10 +230,40 @@ static inline void list_splice_init_rcu(struct list_head 
*list,
 * this function.
 */
 
-   last->next = at;
-   rcu_assign_pointer(list_next_rcu(head), first);
-   first->prev = head;
-   at->prev = last;
+   last->next = next;
+   rcu_assign_pointer(list_next_rcu(prev), first);
+   first->prev = prev;
+   next->prev = last;
+}
+
+/**
+ * list_splice_init_rcu - splice an RCU-protected list into an existing list,
+ *designed for stacks.
+ * @list:  the RCU-protected list to splice
+ * @head:  the place in the existing list to splice the first list into
+ * @sync:  function to sync: synchronize_rcu(), synchronize_sched(), ...
+ */
+static inline void list_splice_init_rcu(struct list_head *list,
+   struct list_head *head,
+   void (*sync)(void))
+{
+   if (!list_empty(list))
+   __list_splice_init_rcu(list, head, head->next, sync);
+}
+
+/**
+ * list_splice_tail_init_rcu - splice an RCU-protected list into an existing
+ * list, designed for queues.
+ * @list:  the RCU-protected list to splice
+ * @head:  the place in the existing list to splice the first list into
+ * @sync:  function to sync: synchronize_rcu(), synchronize_sched(), ...
+ */
+static inline void list_splice_tail_init_rcu(struct list_head *list,
+struct list_head *head,
+void (*sync)(void))
+{
+   if (!list_empty(list))
+   __list_splice_init_rcu(list, head->prev, head, sync);
 }
 
 /**
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: seccomp and audit_enabled

[Paul Moore]

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

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: seccomp and audit_enabled

[Paul Moore]

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

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Introduces generic __list_splice_init_rcu();

[Paul E. McKenney]

On Mon, Oct 12, 2015 at 06:23:51PM +0300, Petko Manolov wrote:
>  Content preview:  __list_splice_init_rcu() can be used to splice lists 
> forming
> both stack and queue structures, depending on its arguments. It is based
>on the initial list_splice_init_rcu() with a few minor modifications to 
> help
> abstrancting it. [...] 
> 
>  Content analysis details:   (-1.0 points, 5.0 required)
> 
>   pts rule name  description
>   -- 
> --
>  -1.0 ALL_TRUSTEDPassed through trusted hosts only via SMTP
>   0.0 TVD_RCVD_IPMessage was received from an IP address
> X-ZLA-Header: unknown; 0
> X-ZLA-DetailInfo: BA=6.3790; NDR=6.0001; ZLA=6.0003; 
> ZF=6.0009; ZB=6.00042595; ZH=6.; ZP=6.00081149; ZU=6.0002; 
> UDB=6.00264254; UTC=2015-10-12 15:24:07
> x-cbid: 15101215-0009---051B58C0
> X-IBM-ISS-SpamDetectors: Score=0.49; FLB=0; BY=0.040899; FL=0; FP=0; FZ=0;
>  HX=0; KW=0; PH=0; RB=0; SC=0.49; ST=0; TS=0; UL=0; ISC=
> X-IBM-ISS-DetailInfo:  BY=3.4492; HX=3.0236; KW=3.0007;
>  PH=3.0004; SC=3.0118; SDB=6.00601725; UDB=6.00264254; UTC=2015-10-12
>  15:24:16
> X-TM-AS-MML: disable
> 
> __list_splice_init_rcu() can be used to splice lists forming both stack and
> queue structures, depending on its arguments.  It is based on the initial
> list_splice_init_rcu() with a few minor modifications to help abstrancting it.
> 
> Signed-off-by: Petko Manolov 

Much better, thank you!  Queued for testing and review.  If things go
well, it will make it into v4.5.

Thanx, Paul

> ---
>  include/linux/rculist.h | 69 
> +++--
>  1 file changed, 49 insertions(+), 20 deletions(-)
> 
> diff --git a/include/linux/rculist.h b/include/linux/rculist.h
> index 5ed5409..e99d834 100644
> --- a/include/linux/rculist.h
> +++ b/include/linux/rculist.h
> @@ -179,32 +179,31 @@ static inline void list_replace_rcu(struct list_head 
> *old,
>  }
> 
>  /**
> - * list_splice_init_rcu - splice an RCU-protected list into an existing list.
> + * __list_splice_init_rcu - join an RCU-protected list into an existing list.
>   * @list:the RCU-protected list to splice
> - * @head:the place in the list to splice the first list into
> + * @prev:points to the last element of the existing list
> + * @next:points to the first element of the existing list
>   * @sync:function to sync: synchronize_rcu(), synchronize_sched(), ...
>   *
> - * @head can be RCU-read traversed concurrently with this function.
> + * The list pointed to by @prev and @next can be RCU-read traversed
> + * concurrently with this function.
>   *
>   * Note that this function blocks.
>   *
> - * Important note: the caller must take whatever action is necessary to
> - *   prevent any other updates to @head.  In principle, it is possible
> - *   to modify the list as soon as sync() begins execution.
> - *   If this sort of thing becomes necessary, an alternative version
> - *   based on call_rcu() could be created.  But only if -really-
> - *   needed -- there is no shortage of RCU API members.
> + * Important note: the caller must take whatever action is necessary to 
> prevent
> + * any other updates to the existing list.  In principle, it is possible to
> + * modify the list as soon as sync() begins execution. If this sort of thing
> + * becomes necessary, an alternative version based on call_rcu() could be
> + * created.  But only if -really- needed -- there is no shortage of RCU API
> + * members.
>   */
> -static inline void list_splice_init_rcu(struct list_head *list,
> - struct list_head *head,
> - void (*sync)(void))
> +static inline void __list_splice_init_rcu(struct list_head *list,
> +   struct list_head *prev,
> +   struct list_head *next,
> +   void (*sync)(void))
>  {
>   struct list_head *first = list->next;
>   struct list_head *last = list->prev;
> - struct list_head *at = head->next;
> -
> - if (list_empty(list))
> - return;
> 
>   /*
>* "first" and "last" tracking list, so initialize it.  RCU readers
> @@ -231,10 +230,40 @@ static inline void list_splice_init_rcu(struct 
> list_head *list,
>* this function.
>*/
> 
> - last->next = at;
> - rcu_assign_pointer(list_next_rcu(head), first);
> - first->prev = head;
> - at->prev = last;
> + last->next = next;
> + rcu_assign_pointer(list_next_rcu(prev), first);
> + first->prev = prev;
> + next->prev = last;
> +}
> +
> +/**
> + * list_splice_init_rcu - splice an RCU-protected list into an existing list,
> + *designed for stacks.
> + * 

Re: seccomp and audit_enabled

[Tony Jones]

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=c03e syscall=91 
compat=0 ip=0x7ff926d94ab7 code=0x5
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=c03e syscall=273 
compat=0 ip=0x7ff928325444 code=0x5
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=c03e syscall=273 
compat=0 ip=0x7ff928325444 code=0x5
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=c03e syscall=2 
compat=0 ip=0x7ff926d6daa1 code=0x3
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=c03e syscall=91 
compat=0 ip=0x7f92e4bd7ab7 code=0x5
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=c03e syscall=91 
compat=0 ip=0x7f92e4bd7ab7 code=0x5
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=c03e syscall=273 
compat=0 ip=0x7f92e6168444 code=0x5
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=c03e syscall=2 
compat=0 ip=0x7f92eb5f8587 code=0x5
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=c03e syscall=2 
compat=0 ip=0x7f92e4b2ac8c code=0x5
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=c03e syscall=2 
compat=0 ip=0x7f92e4b2ad70 code=0x5


thanks

tony


>From d6971ec9508244f7a1ab42f9ac4c59b7e1ca6145 Mon Sep 17 00:00:00 2001
From: Tony Jones 
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=c03e syscall=91 

Re: seccomp and audit_enabled

[Kees Cook]

On Mon, Oct 12, 2015 at 10:53 AM, Tony Jones  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=c03e 
> syscall=91 compat=0 ip=0x7ff926d94ab7 code=0x5
> 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=c03e 
> syscall=273 compat=0 ip=0x7ff928325444 code=0x5
> 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=c03e 
> syscall=273 compat=0 ip=0x7ff928325444 code=0x5
> 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=c03e 
> syscall=2 compat=0 ip=0x7ff926d6daa1 code=0x3
> 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=c03e 
> syscall=91 compat=0 ip=0x7f92e4bd7ab7 code=0x5
> 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=c03e 
> syscall=91 compat=0 ip=0x7f92e4bd7ab7 code=0x5
> 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=c03e 
> syscall=273 compat=0 ip=0x7f92e6168444 code=0x5
> 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=c03e 
> syscall=2 compat=0 ip=0x7f92eb5f8587 code=0x5
> 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=c03e 
> syscall=2 compat=0 ip=0x7f92e4b2ac8c code=0x5
> 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=c03e 
> syscall=2 compat=0 ip=0x7f92e4b2ad70 code=0x5
>
>
> thanks
>
> tony
>
>
> From d6971ec9508244f7a1ab42f9ac4c59b7e1ca6145 Mon Sep 17 00:00:00 2001
> From: Tony Jones 
> 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