On 09/11/2017 10:02, Florian Weimer wrote:
On 11/09/2017 12:58 PM, Michael Kerrisk (man-pages) wrote:
quoted
[CC += Kees, in case he has some comments]
On 9 November 2017 at 08:17, Michael Kerrisk (man-pages)
[off-list ref] wrote:
quoted
Hi Florian,
On 8 November 2017 at 07:24, Florian Weimer [off-list ref] wrote:
quoted
On 11/07/2017 09:35 PM, Michael Kerrisk (man-pages) wrote:
quoted
This change broke my code that was doing seccomp filtering for the
open() system call number (__NR_open). The breakage in question is not
serious, since this was really just demonstration code. However, I
want to raise awareness that these sorts of changes have the potential
to possibly cause breakages for some code using seccomp, and note that
I think such changes should not be made lightly or gratuitously.
I have the opposite view: We should make such changes as often as possible,
to remind people that seccomp filters (and certain SELinux and AppArmor
policies) are incompatible with the GNU/Linux model, where everything is
developed separately and not maintained within a single source tree (unlike
say OpenBSD). This means that you really can't deviate from the upstream
Linux userspace ABI (in the broadest possible sense) and still expect things
to work.
I know that people like to slap seccomp filters on everything today, but
without careful examination, that is likely to introduce bugs (particularly
on rarely used code paths). It can also cause the process to switch to
legacy interfaces with known issues (e.g., reading from /dev/urandom instead
of getrandom, without waiting for the kernel to signal initialization of the
pool).
Thanks. The above is a good summary of the counterpoints to my initial argument.
Florian, taking your and Adhemerval's useful comments into account, I
added the following text to the seccomp(2) manual page:
[[
Caveats
There are various subtleties to consider when applying seccomp
filters to a program, including the following:
* Some traditional system calls have user-space implementations
in the vdso(7) on many architectures. Notable examples include
clock_gettime(2), gettimeofday(2), and time(2). On such archi‐
tectures, seccomp filtering for these system calls will have no
effect.
I think the situation is more complicated for many of those because they can still perform system calls on their fallback paths. So it's one more case where seccomp can give you unpredictable failures.
Rest looks good to me. Thanks for the writeup.
Florian
Looks good to me as well.
On 9 November 2017 at 13:14, Adhemerval Zanella <
adhemerval.zanella@linaro.org> wrote:
On 09/11/2017 10:02, Florian Weimer wrote:
quoted
On 11/09/2017 12:58 PM, Michael Kerrisk (man-pages) wrote:
quoted
[CC += Kees, in case he has some comments]
On 9 November 2017 at 08:17, Michael Kerrisk (man-pages)
[off-list ref] wrote:
quoted
Hi Florian,
On 8 November 2017 at 07:24, Florian Weimer [off-list ref] wrote:
quoted
On 11/07/2017 09:35 PM, Michael Kerrisk (man-pages) wrote:
quoted
This change broke my code that was doing seccomp filtering for the
open() system call number (__NR_open). The breakage in question is
not
quoted
quoted
quoted
quoted
quoted
serious, since this was really just demonstration code. However, I
want to raise awareness that these sorts of changes have the
potential
quoted
quoted
quoted
quoted
quoted
to possibly cause breakages for some code using seccomp, and note
that
quoted
quoted
quoted
quoted
quoted
I think such changes should not be made lightly or gratuitously.
I have the opposite view: We should make such changes as often as
possible,
quoted
quoted
quoted
quoted
to remind people that seccomp filters (and certain SELinux and
AppArmor
quoted
quoted
quoted
quoted
policies) are incompatible with the GNU/Linux model, where everything
is
quoted
quoted
quoted
quoted
developed separately and not maintained within a single source tree
(unlike
quoted
quoted
quoted
quoted
say OpenBSD). This means that you really can't deviate from the
upstream
quoted
quoted
quoted
quoted
Linux userspace ABI (in the broadest possible sense) and still expect
things
quoted
quoted
quoted
quoted
to work.
I know that people like to slap seccomp filters on everything today,
but
quoted
quoted
quoted
quoted
without careful examination, that is likely to introduce bugs
(particularly
quoted
quoted
quoted
quoted
on rarely used code paths). It can also cause the process to switch to
legacy interfaces with known issues (e.g., reading from /dev/urandom
instead
quoted
quoted
quoted
quoted
of getrandom, without waiting for the kernel to signal initialization
of the
quoted
quoted
quoted
quoted
pool).
Thanks. The above is a good summary of the counterpoints to my initial
argument.
quoted
quoted
Florian, taking your and Adhemerval's useful comments into account, I
added the following text to the seccomp(2) manual page:
[[
Caveats
There are various subtleties to consider when applying seccomp
filters to a program, including the following:
* Some traditional system calls have user-space implementations
in the vdso(7) on many architectures. Notable examples include
clock_gettime(2), gettimeofday(2), and time(2). On such archi‐
tectures, seccomp filtering for these system calls will have no
effect.
I think the situation is more complicated for many of those because they
can still perform system calls on their fallback paths. So it's one more
case where seccomp can give you unpredictable failures.
quoted
Rest looks good to me. Thanks for the writeup.
Florian
Looks good to me as well.
Thanks for the review, Adhemerval!
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/