Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 cor...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value
Thanks for the patch!
On Tue, Dec 18, 2012 at 3:50 PM, Corey Bryant 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value
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
---
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 0x0003U /* disallow and force a SIGSYS */
#define SECCOMP_RET_ERRNO 0x0005U /* returns an errno */
#define SECCOMP_RET_TRACE 0x7ff0U /* pass to a tracer or disallow */
+#define SECCOMP_RET_INFO 0x7ff7U /* print info message and allow */
#define SECCOMP_RET_ALLOW 0x7fffU /* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value
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 cor...@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 0x0003U /* disallow and force a SIGSYS */ #define SECCOMP_RET_ERRNO 0x0005U /* returns an errno */ #define SECCOMP_RET_TRACE 0x7ff0U /* pass to a tracer or disallow */ +#define SECCOMP_RET_INFO 0x7ff7U /* print info message and allow */ #define SECCOMP_RET_ALLOW 0x7fffU /* 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value
Thanks for the patch! On Tue, Dec 18, 2012 at 3:50 PM, Corey Bryant cor...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
