Re: Seccomp implications for glibc wrapper function changes

["Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>]

Hi Florian,

On 9 November 2017 at 13:02, Florian Weimer <fweimer@redhat.com> wrote:
> On 11/09/2017 12:58 PM, Michael Kerrisk (man-pages) wrote:
>>
>> [CC += Kees, in case he has some comments]
>>
>> On 9 November 2017 at 08:17, Michael Kerrisk (man-pages)
>> <mtk.manpages@gmail.com> wrote:
>>>
>>> Hi Florian,
>>>
>>> On 8 November 2017 at 07:24, Florian Weimer <fweimer@redhat.com> wrote:
>>>>
>>>> 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. 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.

Good point. I added the following text:

          (However,  there are cases where the vdso(7) implemen‐
          tations may fall back  to  invoking  the  true  system
          call, in which case seccomp filters would see the sys‐
          tem call.)

> Rest looks good to me.  Thanks for the writeup.

Thanks for the review!

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/