From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Kerrisk (man-pages)" Subject: Re: Seccomp implications for glibc wrapper function changes Date: Thu, 9 Nov 2017 14:37:15 +0100 Message-ID: References: <0049d6a8-de25-ff02-31ef-38a7db05b878@redhat.com> Reply-To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Florian Weimer Cc: "libc-alpha-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org" , Linux API , Adhemerval Zanella , Kees Cook List-Id: linux-api@vger.kernel.org Hi Florian, On 9 November 2017 at 13:02, Florian Weimer wrote: > On 11/09/2017 12:58 PM, Michael Kerrisk (man-pages) wrote: >> >> [CC +=3D Kees, in case he has some comments] >> >> On 9 November 2017 at 08:17, Michael Kerrisk (man-pages) >> wrote: >>> >>> Hi Florian, >>> >>> On 8 November 2017 at 07:24, Florian Weimer 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 no= t >>>>> serious, since this was really just demonstration code. However, I >>>>> want to raise awareness that these sorts of changes have the potentia= l >>>>> to possibly cause breakages for some code using seccomp, and note tha= t >>>>> 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 AppArmo= r >>>> 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, b= ut >>>> without careful examination, that is likely to introduce bugs >>>> (particularly >>>> on rarely used code paths). It can also cause the process to switch t= o >>>> 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 secco= mp >> filters to a program, including the following: >> >> * Some traditional system calls have user-space implementatio= ns >> in the vdso(7) on many architectures. Notable examples inclu= de >> clock_gettime(2), gettimeofday(2), and time(2). On such arch= i=E2=80=90 >> 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 cas= e > where seccomp can give you unpredictable failures. Good point. I added the following text: (However, there are cases where the vdso(7) implemen=E2=80=90 tations may fall back to invoking the true system call, in which case seccomp filters would see the sys=E2=80=90 tem call.) > Rest looks good to me. Thanks for the writeup. Thanks for the review! Cheers, Michael --=20 Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/