On 11/07/2017 09:35 PM, Michael Kerrisk (man-pages) wrote:
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,
Florian
Hi Florian,
On 8 November 2017 at 07:24, Florian Weimer [off-list ref] wrote:
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.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/