This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Seccomp implications for glibc wrapper function changes


On 9 November 2017 at 13:14, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
>
>
> On 09/11/2017 10:02, Florian Weimer 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.
>>
>> 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/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]