This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Seccomp implications for glibc wrapper function changes
On Thu, Nov 9, 2017 at 5:37 AM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> 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!
Agreed, this looks good. Thanks for clarifying it. :)
-Kees
--
Kees Cook
Pixel Security