Message-ID: <50D1D58D.6060408@linux.vnet.ibm.com>
Date:	Wed, 19 Dec 2012 09:56:13 -0500
From:	Corey Bryant <coreyb@...ux.vnet.ibm.com>
To:	Will Drewry <wad@...omium.org>
CC:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, jmorris@...ei.org,
	pmoore@...hat.com, otubo@...ux.vnet.ibm.com,
	Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value



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@...ux.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists