Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Po Lu]

Philipp Stephani <p.stephani2@gmail.com> writes:

> branch: emacs-28
> commit 6d3608be88e1b30d2d10ee81f14dd485275c20ff
> Author: Philipp Stephani <phst@google.com>
> Commit: Philipp Stephani <phst@google.com>
>
>     Seccomp: improve support for newer versions of glibc (Bug#51073)
>     
>     * lib-src/seccomp-filter.c (main): Allow 'pread64' and 'faccessat2'
>     system calls.  Newer versions of glibc use these system call (starting
>     with commits 95c1056962a3f2297c94ce47f0eaf0c5b6563231 and
>     3d3ab573a5f3071992cbc4f57d50d1d29d55bde2, respectively).

This seems to break the build for many people running older glibc
versions.

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Philipp Stephani]

Am Mo., 24. Jan. 2022 um 01:09 Uhr schrieb Po Lu <luangruo@yahoo.com>:
>
> Philipp Stephani <p.stephani2@gmail.com> writes:
>
> > branch: emacs-28
> > commit 6d3608be88e1b30d2d10ee81f14dd485275c20ff
> > Author: Philipp Stephani <phst@google.com>
> > Commit: Philipp Stephani <phst@google.com>
> >
> >     Seccomp: improve support for newer versions of glibc (Bug#51073)
> >
> >     * lib-src/seccomp-filter.c (main): Allow 'pread64' and 'faccessat2'
> >     system calls.  Newer versions of glibc use these system call (starting
> >     with commits 95c1056962a3f2297c94ce47f0eaf0c5b6563231 and
> >     3d3ab573a5f3071992cbc4f57d50d1d29d55bde2, respectively).
>
> This seems to break the build for many people running older glibc
> versions.

I forgot to bump the minimum libseccomp version. I've done that now
(commit c34d06e3d75bfbea2605e3ae292850175ce5c235).

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Mon, 24 Jan 2022 11:44:34 +0100
> Cc: Philipp Stephani <phst@google.com>, Emacs developers <emacs-devel@gnu.org>
> 
> Am Mo., 24. Jan. 2022 um 01:09 Uhr schrieb Po Lu <luangruo@yahoo.com>:
> >
> > Philipp Stephani <p.stephani2@gmail.com> writes:
> >
> > > branch: emacs-28
> > > commit 6d3608be88e1b30d2d10ee81f14dd485275c20ff
> > > Author: Philipp Stephani <phst@google.com>
> > > Commit: Philipp Stephani <phst@google.com>
> > >
> > >     Seccomp: improve support for newer versions of glibc (Bug#51073)
> > >
> > >     * lib-src/seccomp-filter.c (main): Allow 'pread64' and 'faccessat2'
> > >     system calls.  Newer versions of glibc use these system call (starting
> > >     with commits 95c1056962a3f2297c94ce47f0eaf0c5b6563231 and
> > >     3d3ab573a5f3071992cbc4f57d50d1d29d55bde2, respectively).
> >
> > This seems to break the build for many people running older glibc
> > versions.
> 
> I forgot to bump the minimum libseccomp version. I've done that now
> (commit c34d06e3d75bfbea2605e3ae292850175ce5c235).

Why do we need this and the previous change on the release branch?
There were zero complaints until now about seccomp for Emacs 28.  Can
we revert the original change in the first place?

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Why do we need this and the previous change on the release branch?
> There were zero complaints until now about seccomp for Emacs 28.

> Can we revert the original change in the first place?

It apparently leads to crashes when Emacs is run under seccomp with a
recent glibc version.

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Philipp Stephani <p.stephani2@gmail.com>,  phst@google.com,
>   emacs-devel@gnu.org
> Date: Mon, 24 Jan 2022 21:33:01 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why do we need this and the previous change on the release branch?
> > There were zero complaints until now about seccomp for Emacs 28.
> 
> > Can we revert the original change in the first place?
> 
> It apparently leads to crashes when Emacs is run under seccomp with a
> recent glibc version.

That can happen any day, if glibc folks make some change we didn't
know about.  We cannot chase glibc development forever, we will never
succeed catching up with them, certainly not in the long run.

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> It apparently leads to crashes when Emacs is run under seccomp with a
>> recent glibc version.
>
> That can happen any day, if glibc folks make some change we didn't
> know about.  We cannot chase glibc development forever, we will never
> succeed catching up with them, certainly not in the long run.

But this is a known glibc issue, and crashes aren't fun, so I think the
seccomp change was warranted on the release branch.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 24 Jan 2022 15:38:24 +0100
> Cc: Po Lu <luangruo@yahoo.com>, phst@google.com, p.stephani2@gmail.com,
>  emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It apparently leads to crashes when Emacs is run under seccomp with a
> >> recent glibc version.
> >
> > That can happen any day, if glibc folks make some change we didn't
> > know about.  We cannot chase glibc development forever, we will never
> > succeed catching up with them, certainly not in the long run.
> 
> But this is a known glibc issue, and crashes aren't fun, so I think the
> seccomp change was warranted on the release branch.

It is very worrisome that a change in glibc can break Emacs like that.
I wonder what it means for the maintainability of Emacs in the long
run.  I have a bad feeling about this.

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Robert Pluim]

>>>>> On Mon, 24 Jan 2022 17:00:25 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Lars Ingebrigtsen <larsi@gnus.org>
    >> Date: Mon, 24 Jan 2022 15:38:24 +0100
    >> Cc: Po Lu <luangruo@yahoo.com>, phst@google.com, p.stephani2@gmail.com,
    >> emacs-devel@gnu.org
    >> 
    >> Eli Zaretskii <eliz@gnu.org> writes:
    >> 
    >> >> It apparently leads to crashes when Emacs is run under seccomp with a
    >> >> recent glibc version.
    >> >
    >> > That can happen any day, if glibc folks make some change we didn't
    >> > know about.  We cannot chase glibc development forever, we will never
    >> > succeed catching up with them, certainly not in the long run.
    >> 
    >> But this is a known glibc issue, and crashes aren't fun, so I think the
    >> seccomp change was warranted on the release branch.

    Eli> It is very worrisome that a change in glibc can break Emacs like that.
    Eli> I wonder what it means for the maintainability of Emacs in the long
    Eli> run.  I have a bad feeling about this.

We can always default the seccomp support to off.

Robert
-- 

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  luangruo@yahoo.com,
>   phst@google.com,  p.stephani2@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 24 Jan 2022 17:47:19 +0100
> 
>     Eli> It is very worrisome that a change in glibc can break Emacs like that.
>     Eli> I wonder what it means for the maintainability of Emacs in the long
>     Eli> run.  I have a bad feeling about this.
> 
> We can always default the seccomp support to off.

If it's so fragile, perhaps we should.

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > This seems to break the build for many people running older glibc
  > > versions.

  > I forgot to bump the minimum libseccomp version. I've done that now
  > (commit c34d06e3d75bfbea2605e3ae292850175ce5c235).

Concretely, what will the effect of this be on people who build with
an older Glibc version installed?

  > That can happen any day, if glibc folks make some change we didn't
  > know about.  We cannot chase glibc development forever, we will never
  > succeed catching up with them, certainly not in the long run.

It's true that problems like this can happen any day.  Not just with
Glibc but with lots of libraries that Emacs uses.  But that has been
the case for many years.  Are things getting worse in some way?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 24 Jan 2022 23:16:03 -0500
> Cc: luangruo@yahoo.com, phst@google.com, emacs-devel@gnu.org
> 
>   > That can happen any day, if glibc folks make some change we didn't
>   > know about.  We cannot chase glibc development forever, we will never
>   > succeed catching up with them, certainly not in the long run.
> 
> It's true that problems like this can happen any day.  Not just with
> Glibc but with lots of libraries that Emacs uses.  But that has been
> the case for many years.  Are things getting worse in some way?

If frequent changes to glibc cause Emacs to crash, that is bad.  Emacs
should not have such a critical dependency on changes in the library,
and it shouldn't be that fragile.

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Philipp Stephani]

> Am 24.01.2022 um 16:00 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Mon, 24 Jan 2022 15:38:24 +0100
>> Cc: Po Lu <luangruo@yahoo.com>, phst@google.com, p.stephani2@gmail.com,
>> emacs-devel@gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>>> It apparently leads to crashes when Emacs is run under seccomp with a
>>>> recent glibc version.
>>> 
>>> That can happen any day, if glibc folks make some change we didn't
>>> know about.  We cannot chase glibc development forever, we will never
>>> succeed catching up with them, certainly not in the long run.
>> 
>> But this is a known glibc issue, and crashes aren't fun, so I think the
>> seccomp change was warranted on the release branch.
> 
> It is very worrisome that a change in glibc can break Emacs like that.
> I wonder what it means for the maintainability of Emacs in the long
> run.  I have a bad feeling about this.

Just to clarify this, nothing here has really broken Emacs.  Emacs itself doesn't depend on libseccomp or the specific seccomp filter at all.  It's just that newer versions of glibc will occasionally add new syscalls which will then need to get added to seccomp filters for sandboxing to continue working; the sandbox can only be secure if it fails-close (i.e. exits the process when encountering an unknown syscall).

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Philipp Stephani]

> Am 24.01.2022 um 18:19 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  luangruo@yahoo.com,
>>  phst@google.com,  p.stephani2@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 24 Jan 2022 17:47:19 +0100
>> 
>>    Eli> It is very worrisome that a change in glibc can break Emacs like that.
>>    Eli> I wonder what it means for the maintainability of Emacs in the long
>>    Eli> run.  I have a bad feeling about this.
>> 
>> We can always default the seccomp support to off.
> 
> If it's so fragile, perhaps we should.

The seccomp support isn't fragile at all.  It only relies on the Linux kernel and a small number of syscalls that haven't changed for a long time.
What is "fragile" here (though I think this wording is incorrect) is the generation of the default filter that we ship for convenience reasons.  That one should be adapted (maybe a few times per year, so not very frequently) to newer libc versions.  There's no other way since unknown syscalls in the filter can't be allowed for security reasons.

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Philipp Stephani]

> Am 25.01.2022 um 13:08 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> From: Richard Stallman <rms@gnu.org>
>> Date: Mon, 24 Jan 2022 23:16:03 -0500
>> Cc: luangruo@yahoo.com, phst@google.com, emacs-devel@gnu.org
>> 
>>> That can happen any day, if glibc folks make some change we didn't
>>> know about.  We cannot chase glibc development forever, we will never
>>> succeed catching up with them, certainly not in the long run.
>> 
>> It's true that problems like this can happen any day.  Not just with
>> Glibc but with lots of libraries that Emacs uses.  But that has been
>> the case for many years.  Are things getting worse in some way?
> 
> If frequent changes to glibc cause Emacs to crash, that is bad.

These "crashes" are the whole point and purpose of seccomp filters.  If an Emacs process is sandboxed using a syscall filter, any unknown syscall has to exit the process ("crash"), otherwise the sandbox would be insecure.

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Stefan Monnier]

> Just to clarify this, nothing here has really broken Emacs.  Emacs itself
> doesn't depend on libseccomp or the specific seccomp filter at all.  It's
> just that newer versions of glibc will occasionally add new syscalls which
> will then need to get added to seccomp filters for sandboxing to continue
> working; the sandbox can only be secure if it fails-close (i.e. exits the
> process when encountering an unknown syscall).

Maybe you need to clarify what "makes Emacs crash" means, then.

To clarify, my understanding so far based on your description (and my
lack of understanding of how seccomp is currently used in Emacs) is that
an Emacs built with support for seccomp would be 100% unusable without
the recent adjustment, when run on a system using a new glibc.

If that is not the case, then please clarify in which circumstances the
problem shows up.  If it is the case, then it means we may need a way
for users to update the seccomp filter without recompiling&reinstalling
Emacs, so they can keep using their Emacs-28.1 when glibc is changed
again two years from now.


        Stefan

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 25 Jan 2022 21:09:24 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>  Po Lu <luangruo@yahoo.com>,
>  Philipp Stephani <phst@google.com>,
>  emacs-devel@gnu.org
> 
> > It is very worrisome that a change in glibc can break Emacs like that.
> > I wonder what it means for the maintainability of Emacs in the long
> > run.  I have a bad feeling about this.
> 
> Just to clarify this, nothing here has really broken Emacs.  Emacs itself doesn't depend on libseccomp or the specific seccomp filter at all.  It's just that newer versions of glibc will occasionally add new syscalls which will then need to get added to seccomp filters for sandboxing to continue working; the sandbox can only be secure if it fails-close (i.e. exits the process when encountering an unknown syscall).

That is exactly my problem with these situations: sandboxed Emacs
stops working too frequently for that to be a reliable option.

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 25 Jan 2022 21:12:17 +0100
> Cc: Robert Pluim <rpluim@gmail.com>,
>  Lars Ingebrigtsen <larsi@gnus.org>,
>  Po Lu <luangruo@yahoo.com>,
>  Philipp Stephani <phst@google.com>,
>  emacs-devel@gnu.org
> 
> 
> 
> > Am 24.01.2022 um 18:19 schrieb Eli Zaretskii <eliz@gnu.org>:
> > 
> >> From: Robert Pluim <rpluim@gmail.com>
> >> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  luangruo@yahoo.com,
> >>  phst@google.com,  p.stephani2@gmail.com,  emacs-devel@gnu.org
> >> Date: Mon, 24 Jan 2022 17:47:19 +0100
> >> 
> >>    Eli> It is very worrisome that a change in glibc can break Emacs like that.
> >>    Eli> I wonder what it means for the maintainability of Emacs in the long
> >>    Eli> run.  I have a bad feeling about this.
> >> 
> >> We can always default the seccomp support to off.
> > 
> > If it's so fragile, perhaps we should.
> 
> The seccomp support isn't fragile at all.  It only relies on the Linux kernel and a small number of syscalls that haven't changed for a long time.
> What is "fragile" here (though I think this wording is incorrect) is the generation of the default filter that we ship for convenience reasons.  That one should be adapted (maybe a few times per year, so not very frequently) to newer libc versions.  There's no other way since unknown syscalls in the filter can't be allowed for security reasons.

IOW, this is unworkable in principle.  Exactly my point.

Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 25 Jan 2022 21:13:38 +0100
> Cc: rms@gnu.org,
>  Po Lu <luangruo@yahoo.com>,
>  Philipp Stephani <phst@google.com>,
>  emacs-devel@gnu.org
> 
> 
> 
> > Am 25.01.2022 um 13:08 schrieb Eli Zaretskii <eliz@gnu.org>:
> > 
> >> From: Richard Stallman <rms@gnu.org>
> >> Date: Mon, 24 Jan 2022 23:16:03 -0500
> >> Cc: luangruo@yahoo.com, phst@google.com, emacs-devel@gnu.org
> >> 
> >>> That can happen any day, if glibc folks make some change we didn't
> >>> know about.  We cannot chase glibc development forever, we will never
> >>> succeed catching up with them, certainly not in the long run.
> >> 
> >> It's true that problems like this can happen any day.  Not just with
> >> Glibc but with lots of libraries that Emacs uses.  But that has been
> >> the case for many years.  Are things getting worse in some way?
> > 
> > If frequent changes to glibc cause Emacs to crash, that is bad.
> 
> These "crashes" are the whole point and purpose of seccomp filters.  If an Emacs process is sandboxed using a syscall filter, any unknown syscall has to exit the process ("crash"), otherwise the sandbox would be insecure.

The important point is that it makes Emacs unusable in this mode.
Perhaps security-wise this is what you want, but I very much doubt
that users will be pleased.