seccomp: Add SECCOMP_RET_INFO return value
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.
--- include/uapi/linux/seccomp.h | 1 + kernel/seccomp.c | 4 ++++ 2 files changed, 5 insertions(+)
include/uapi/linux/seccomp.h +1 -0
@@ -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. */
kernel/seccomp.c +4 -0
@@ -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 :
Signature · 1 line
1.7.11.7
Will Drewry
reviewerThanks for the patch!
Quoted 3 lines · 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.
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]
kernel/seccomp.c int __secure_computing(int this_syscall) · line 438
Quoted 11 lines
kernel/seccomp.c +3
-0@@ -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
Quoted 1 line · Will Drewry
Thanks for the patch!
Thanks for the feedback!
Quoted 8 lines · Corey Bryant
Quoted 3 lines
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
_LOGreturn 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.
Quoted 10 lines
- ptrace can cover this awkwardly (user)
- ftrace can cover this awkwardly (system/root)
- audit can cover this without an allow
-_TRAPcan 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.
Quoted 2 lines
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.
Quoted 9 lines
[snip]
Quoted 7 lines
kernel/seccomp.c +0
-0@@ -433,6 +433,10 @@ int __secure_computing(int this_syscall) goto skip;/* Explicit request to skip. */
Quoted 8 lines
kernel/seccomp.c int __secure_computing(int this_syscall) · line 438
Quoted 4 lines
kernel/seccomp.c +3
-0return 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.
Quoted 6 lines
That aside, I worry that
pr_infois 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 aSECCOMP_RET_AUDITmight 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.
Signature · 2 lines
Regards, Corey Bryant
Quoted 7 lines · Corey Bryant
Quoted 2 lines · Will Drewry
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_INFOis 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.
Quoted 9 lines
Quoted 6 lines
That aside, I worry that
pr_infois 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 aSECCOMP_RET_AUDITmight 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.
Signature · 2 lines
paul moore security and virtualization @ redhat