On 2017-01-04 08:58, Tyler Hicks wrote:
On 01/04/2017 04:44 AM, Kees Cook wrote:
> On Tue, Jan 3, 2017 at 1:31 PM, Paul Moore <paul(a)paul-moore.com> wrote:
>> On Tue, Jan 3, 2017 at 4:21 PM, Kees Cook <keescook(a)chromium.org> wrote:
>>> On Tue, Jan 3, 2017 at 1:13 PM, Paul Moore <paul(a)paul-moore.com>
wrote:
>>>> On Tue, Jan 3, 2017 at 4:03 PM, Kees Cook <keescook(a)chromium.org>
wrote:
>>>>> On Tue, Jan 3, 2017 at 12:54 PM, Paul Moore
<paul(a)paul-moore.com> wrote:
>>>>>> On Tue, Jan 3, 2017 at 3:44 PM, Kees Cook
<keescook(a)chromium.org> wrote:
>>>>>>> I still wonder, though, isn't there a way to use
auditctl to get all
>>>>>>> the seccomp messages you need?
>>>>>>
>>>>>> Not all of the seccomp actions are currently logged, that's
one of the
>>>>>> problems (and the biggest at the moment).
>>>>>
>>>>> Well... sort of. It all gets passed around, but the logic isn't
very
>>>>> obvious (or at least I always have to go look it up).
>>>>
>>>> Last time I checked SECCOMP_RET_ALLOW wasn't logged (as well as at
>>>> least one other action, but I can't remember which off the top of
my
>>>> head)?
>>>
>>> Sure, but if you're using audit, you don't need RET_ALLOW to be
logged
>>> because you'll get a full syscall log entry. Logging RET_ALLOW is
>>> redundant and provides no new information, it seems to me.
>>
>> I only bring this up as it might be a way to help solve the
>> SECCOMP_RET_AUDIT problem that Tyler mentioned.
>
> So, I guess I want to understand why something like this doesn't work,
> with no changes at all to the kernel:
>
> Imaginary "seccomp-audit.c":
>
> ...
> pid = fork();
> if (pid) {
> char cmd[80];
>
> sprintf(cmd, "auditctl -a always,exit -S all -F pid=%d", pid);
> system(cmd);
> release...
> } else {
> wait for release...
> execv(argv[1], argv + 1);
> }
> ...
>
> This should dump all syscalls (both RET_ALLOW and RET_ERRNO), as well
> as all seccomp actions of any kind. (Down side is the need for root to
> launch auditctl...)
Hey Kees - Thanks for the suggestion!
Here are some of the reasons that it doesn't quite work:
1) We don't install/run auditd by default and would continue to prefer
not to in some situations where resources are tight.
2) We block a relatively small number of syscalls as compared to what
are allowed so auditing all syscalls is a really heavyweight solution.
That could be fixed with a better -S argument, though.
3) We sometimes only block certain arguments for a given syscall and
auditing all instances of the syscall could still be a heavyweight solution.
4) If the application spawns children processes, that rule doesn't audit
their syscalls. That can be fixed with ppid=%d but then grandchildren
pids are a problem.
This patch that wasn't accepted upstream might be useful:
https://www.redhat.com/archives/linux-audit/2015-August/msg00067.html
https://www.redhat.com/archives/linux-audit/2015-August/msg00068.html
5) Cleanup of the audit rule for an old pid, before the pid is
reused,
could be difficult.
Tyler
> Perhaps an improvement to this could be enabling audit when seccomp
> syscall is seen? I can't tell if auditctl already has something to do
> this ("start auditing this process and all children when syscall X is
> performed").
>
> -Kees
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635