[systemd-devel] [PATCH 2/2] syscallfilter: port to libseccomp

[Ronny Chevalier]

2014-01-27 Lennart Poettering <lennart at poettering.net>:
> On Sat, 25.01.14 18:06, Ronny Chevalier (chevalier.ronny at gmail.com) wrote:
>
>> > Doesn't libseccomp provide a way to enumerate the contents of the
>> > defined filter again? I'd really prefer if we could find a way that
>> > specifiying a filter of "read write" and of "write read" would actually
>> > result in the same string exposed via the bus.
>> Unfortunately no, this is why I strdup the string from the .service,
>> but yes I see why this is not really a good idea...
>>
>> Maybe by adding each syscall, after being validated by the libseccomp
>> API, in an array and sorting them ? And if the first element is the ~
>> then it's a blacklist ?
>
> Yeah, so I would be fine with parsing the string and resolving the
> syscalls with seccomp_syscall_resolve_name(), then adding the returned
> integer to an array, then sort the array and regenerate a string out if
> it again with seccomp_syscall_resolve_num(), possibly prefixing it with
> "~"... That way, we'd expose a string, but a normalized and somewhat
> portable one.
>
I have an issue about a specific detail in the documentation of
SystemCallFilter :
"This option may be specified more than once in which case the filter
masks are merged"

There is no problem if someone do something like:
SystemCallFilter=write read execve
SystemCallFilter=ioperm
-- or --
SystemCallFilter=~write read execve
SystemCallFilter=~ioperm

But in a case like:
SystemCallFilter=~write read execve
SystemCallFilter=ioperm

What about ioperm ? Should it be considered like ~ioperm ? If yes what
happen if someone do something like this:
SystemCallFilter=write read execve
SystemCallFilter=~ioperm

Should we ignore the ~ioperm and generate an error ? or something else
? Since it doesn't mean anything.

I mention this because I was about to send the new patch but I noticed
that in the previous patch and the new one I forgot about this part in
the documentation.

> Lennart
>
> --
> Lennart Poettering, Red Hat