[PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value

[PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value

[Corey Bryant]

Adds a new return value to seccomp filters that causes an
informational kernel message to be printed.  The message
includes the system call number.

This can be used to learn the system calls that a process
is using.

Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
---
 include/uapi/linux/seccomp.h | 1 +
 kernel/seccomp.c             | 4 ++++
 2 files changed, 5 insertions(+)

diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
index ac2dc9f..0086626 100644
--- a/include/uapi/linux/seccomp.h
+++ b/include/uapi/linux/seccomp.h
@@ -22,6 +22,7 @@
 #define SECCOMP_RET_TRAP	0x00030000U /* disallow and force a SIGSYS */
 #define SECCOMP_RET_ERRNO	0x00050000U /* returns an errno */
 #define SECCOMP_RET_TRACE	0x7ff00000U /* pass to a tracer or disallow */
+#define SECCOMP_RET_INFO	0x7ff70000U /* print info message and allow */
 #define SECCOMP_RET_ALLOW	0x7fff0000U /* allow */
 
 /* Masks for the return value sections. */
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 5af44b5..854f628 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -433,6 +433,10 @@ int __secure_computing(int this_syscall)
 				goto skip;  /* Explicit request to skip. */
 
 			return 0;
+		case SECCOMP_RET_INFO:
+			if (printk_ratelimit())
+				pr_info("seccomp: syscall=%d\n", this_syscall);
+			return 0;
 		case SECCOMP_RET_ALLOW:
 			return 0;
 		case SECCOMP_RET_KILL:
-- 
1.7.11.7

Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value

[Will Drewry]

Thanks for the patch!

On Tue, Dec 18, 2012 at 3:50 PM, Corey Bryant <coreyb@linux.vnet.ibm.com> wrote:
> Adds a new return value to seccomp filters that causes an
> informational kernel message to be printed.  The message
> includes the system call number.

I don't have strong opinions about this either way, but here are the
points that led me to drop a _LOG return value in the past:
- ptrace can cover this awkwardly (user)
- ftrace can cover this awkwardly (system/root)
- audit can cover this without an allow
- _TRAP can be used to implement this
- There's no good way to give back the log data.

I've been relying on SECCOMP_RET_TRAP:
- trap on failure, log, then die
- trap on failure, log, then jump to a whitelisted re-entry point to
resume the syscall
while others I've spoken with have been using the audit path to track
denied values -- not so great for soft-failures :)

[snip]
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 5af44b5..854f628 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -433,6 +433,10 @@ int __secure_computing(int this_syscall)
>                                 goto skip;  /* Explicit request to skip. */
>
>                         return 0;
> +               case SECCOMP_RET_INFO:
> +                       if (printk_ratelimit())
> +                               pr_info("seccomp: syscall=%d\n", this_syscall);

The arch value will also be needed to make this reliably meaningful
(how was the syscall called).

That aside, I worry that pr_info is the wrong place for a random user
on the machine to log to for this, but I may be wrong, rather than a
dedicated ringbufffer, etc.  So if this is for a user with privs, then
a SECCOMP_RET_AUDIT might make sense.  Feedback to a local user seems
tricky in general. I don't know :)  I just decided to deal with it in
userland even if it is slightly painful.

Thanks!
will

Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value

[Corey Bryant]

On 12/18/2012 05:22 PM, Will Drewry wrote:
> Thanks for the patch!

Thanks for the feedback!

>
> On Tue, Dec 18, 2012 at 3:50 PM, Corey Bryant <coreyb@linux.vnet.ibm.com> wrote:
>> Adds a new return value to seccomp filters that causes an
>> informational kernel message to be printed.  The message
>> includes the system call number.
>
> I don't have strong opinions about this either way, but here are the
> points that led me to drop a _LOG return value in the past:

I figured you had attempted a log mechanism before. :)  I've just found 
it too difficult to learn the syscalls a process uses and I think this 
would ease the pain.

> - ptrace can cover this awkwardly (user)
> - ftrace can cover this awkwardly (system/root)
> - audit can cover this without an allow
> - _TRAP can be used to implement this
> - There's no good way to give back the log data.
>
> I've been relying on SECCOMP_RET_TRAP:
> - trap on failure, log, then die
> - trap on failure, log, then jump to a whitelisted re-entry point to
> resume the syscall

We tried using SECCOMP_RET_TRAP with QEMU.  And while it was useful most 
of the time, we hit some scenarios where libraries used by QEMU were 
blocking SIGSYS.  So the signal would never get delivered to our signal 
handler.  If it was just QEMU blocking the syscalls then we could work 
around that, but I don't want to have to update other libraries.

> while others I've spoken with have been using the audit path to track
> denied values -- not so great for soft-failures :)

The audit path would work too but if I understand I think you can only 
learn one syscall per execution.  The nice thing about SECCOMP_RET_INFO 
is that you can easily learn all the syscalls in one execution.

>
> [snip]
>> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
>> index 5af44b5..854f628 100644
>> --- a/kernel/seccomp.c
>> +++ b/kernel/seccomp.c
>> @@ -433,6 +433,10 @@ int __secure_computing(int this_syscall)
>>                                  goto skip;  /* Explicit request to skip. */
>>
>>                          return 0;
>> +               case SECCOMP_RET_INFO:
>> +                       if (printk_ratelimit())
>> +                               pr_info("seccomp: syscall=%d\n", this_syscall);
>
> The arch value will also be needed to make this reliably meaningful
> (how was the syscall called).
>

Ah, yes.  Thanks.

> That aside, I worry that pr_info is the wrong place for a random user
> on the machine to log to for this, but I may be wrong, rather than a
> dedicated ringbufffer, etc.  So if this is for a user with privs, then
> a SECCOMP_RET_AUDIT might make sense.  Feedback to a local user seems
> tricky in general. I don't know :)  I just decided to deal with it in
> userland even if it is slightly painful.

That's a good point.  I don't know which option is better either so if 
anyone else could weigh in on the better approach I'd appreciate it.

-- 
Regards,
Corey Bryant

Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value

[Paul Moore]

On Wednesday, December 19, 2012 09:56:13 AM Corey Bryant wrote:
> On 12/18/2012 05:22 PM, Will Drewry wrote:
> > while others I've spoken with have been using the audit path to track
> > denied values -- not so great for soft-failures :)
> 
> The audit path would work too but if I understand I think you can only
> learn one syscall per execution.  The nice thing about SECCOMP_RET_INFO
> is that you can easily learn all the syscalls in one execution.

Another quick point about the audit log: on some systems, e.g. tightly secured 
SELinux systems, the audit log is only accessible via a very privileged user 
(Will hints at this below).  Normal users do not have access to, and therefore 
can't make use of, the seccomp related audit records.

> > That aside, I worry that pr_info is the wrong place for a random user
> > on the machine to log to for this, but I may be wrong, rather than a
> > dedicated ringbufffer, etc.  So if this is for a user with privs, then
> > a SECCOMP_RET_AUDIT might make sense.  Feedback to a local user seems
> > tricky in general. I don't know :)  I just decided to deal with it in
> > userland even if it is slightly painful.
> 
> That's a good point.  I don't know which option is better either so if
> anyone else could weigh in on the better approach I'd appreciate it.

I agree with Will's statement about better to deal with the problem in 
userspace when possible, but as Corey pointed out, our experiences with QEMU 
have demonstrated that dealing with the problem exclusively in userspace just 
isn't practical in every case.

Syslog might not be the answer, but RET_TRAP and the audit log aren't very 
good answers either.

-- 
paul moore
security and virtualization @ redhat