GNU bug report logs - #47828
seccomp test failures

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47828 in the body.
You can then email your comments to 47828 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: seccomp test failures
Date: Fri, 16 Apr 2021 12:53:39 -0400

Package: emacs
Version: 28.0.50

On CentOS 8.3 at fb9f5501:

Test emacs-tests/bwrap/allows-stdout condition:
    Info: Process output: 
    (ert-test-failed
     ((should
       (eql status 0))
      :form
      (eql 159 0)
      :value nil))

Test emacs-tests/seccomp/allows-stdout condition:
    Info: Process output: 
    (ert-test-failed
     ((should
       (eql status 0))
      :form
      (eql "Bad system call" 0)
      :value nil))

Message #6 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Sat, 17 Apr 2021 20:21:41 +0200

Am Fr., 16. Apr. 2021 um 19:59 Uhr schrieb Glenn Morris <rgm <at> gnu.org>:
>
> Package: emacs
> Version: 28.0.50
>
> On CentOS 8.3 at fb9f5501:
>
> Test emacs-tests/bwrap/allows-stdout condition:
>     Info: Process output:
>     (ert-test-failed
>      ((should
>        (eql status 0))
>       :form
>       (eql 159 0)
>       :value nil))
>
> Test emacs-tests/seccomp/allows-stdout condition:
>     Info: Process output:
>     (ert-test-failed
>      ((should
>        (eql status 0))
>       :form
>       (eql "Bad system call" 0)
>       :value nil))


Thanks for the report, could you check which syscall failed, e.g. by
checking the kernel audit logs or by posting a stacktrace for the
failure?

Message #9 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Sat, 17 Apr 2021 21:54:39 +0200

Am Sa., 17. Apr. 2021 um 20:21 Uhr schrieb Philipp Stephani
<p.stephani2 <at> gmail.com>:
>
> Am Fr., 16. Apr. 2021 um 19:59 Uhr schrieb Glenn Morris <rgm <at> gnu.org>:
> >
> > Package: emacs
> > Version: 28.0.50
> >
> > On CentOS 8.3 at fb9f5501:
> >
> > Test emacs-tests/bwrap/allows-stdout condition:
> >     Info: Process output:
> >     (ert-test-failed
> >      ((should
> >        (eql status 0))
> >       :form
> >       (eql 159 0)
> >       :value nil))
> >
> > Test emacs-tests/seccomp/allows-stdout condition:
> >     Info: Process output:
> >     (ert-test-failed
> >      ((should
> >        (eql status 0))
> >       :form
> >       (eql "Bad system call" 0)
> >       :value nil))
>
>
> Thanks for the report, could you check which syscall failed, e.g. by
> checking the kernel audit logs or by posting a stacktrace for the
> failure?

FYI, I've now pushed commit 568ce6826fa0aaa4d5dc95880cbdc0965dc07521
to master which attempts to automatically collect this information to
ease debugging such failures.

Message #12 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Sat, 17 Apr 2021 20:01:47 -0400

[Message part 1 (text/plain, inline)]

Philipp Stephani wrote:

> FYI, I've now pushed commit 568ce6826fa0aaa4d5dc95880cbdc0965dc07521
> to master which attempts to automatically collect this information to
> ease debugging such failures.

It doesn't report anything in this case since the user account does not
have permission, and I normally disable core dumps (ulimit -c 0):

    Test emacs-tests/seccomp/allows-stdout condition:
    Info: Process output:
          
          Potentially relevant Seccomp audit events:
          Error opening config file (Permission denied)
          NOTE - using built-in logs: /var/log/audit/audit.log
          Error opening /var/log/audit/audit.log (Permission denied)
          
          Potentially useful coredump information:
          [...]
          No coredumps found.
          -- Notice: 1 systemd-coredump@.service unit is running, output
          may be incomplete.

With my root hat on, the audit.log data is attached.

With core dumps enabled:
 #0  0x00007f7b661fb967 __mmap (libc.so.6)
 #1  0x00007f7b5ff8001e sss_nss_mc_get_ctx (libnss_sss.so.2)
 #2  0x00007f7b5ff80770 sss_nss_mc_getpwuid (libnss_sss.so.2)
 #3  0x00007f7b5ff7c61e _nss_sss_getpwuid_r (libnss_sss.so.2)
 #4  0x00007f7b661cc3cd getpwuid_r@@GLIBC_2.2.5 (libc.so.6)
 #5  0x00007f7b661cbb30 getpwuid (libc.so.6)
 #6  0x000000000060d1ee init_editfns (emacs)
 #7  0x0000000000566801 main (emacs)
 #8  0x00007f7b661277b3 __libc_start_main (libc.so.6)
 #9  0x0000000000418cde _start (emacs)

[audit.txt (text/plain, attachment)]

Message #15 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Sun, 18 Apr 2021 10:32:12 +0200

Am So., 18. Apr. 2021 um 02:01 Uhr schrieb Glenn Morris <rgm <at> gnu.org>:
>
> Philipp Stephani wrote:
>
> > FYI, I've now pushed commit 568ce6826fa0aaa4d5dc95880cbdc0965dc07521
> > to master which attempts to automatically collect this information to
> > ease debugging such failures.
>
> It doesn't report anything in this case since the user account does not
> have permission, and I normally disable core dumps (ulimit -c 0):
>
>     Test emacs-tests/seccomp/allows-stdout condition:
>     Info: Process output:
>
>           Potentially relevant Seccomp audit events:
>           Error opening config file (Permission denied)
>           NOTE - using built-in logs: /var/log/audit/audit.log
>           Error opening /var/log/audit/audit.log (Permission denied)
>
>           Potentially useful coredump information:
>           [...]
>           No coredumps found.
>           -- Notice: 1 systemd-coredump@.service unit is running, output
>           may be incomplete.
>
> With my root hat on, the audit.log data is attached.
>
> With core dumps enabled:
>  #0  0x00007f7b661fb967 __mmap (libc.so.6)
>  #1  0x00007f7b5ff8001e sss_nss_mc_get_ctx (libnss_sss.so.2)

Thanks! Looks like the problem is in
https://github.com/SSSD/sssd/blob/cd843dafe63589d0a77145445c454f6fc19dabae/src/sss_client/nss_mc_common.c#L171-L176,
where the code calls mmap with flags that we don't allow yet
(MAP_SHARED).
Does MAP_SHARED have any security implications? Otherwise we can allow
it right away.

Message #18 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Sun, 18 Apr 2021 10:36:53 +0200

Am So., 18. Apr. 2021 um 10:32 Uhr schrieb Philipp Stephani
<p.stephani2 <at> gmail.com>:
>
> Am So., 18. Apr. 2021 um 02:01 Uhr schrieb Glenn Morris <rgm <at> gnu.org>:
> >
> > Philipp Stephani wrote:
> >
> > > FYI, I've now pushed commit 568ce6826fa0aaa4d5dc95880cbdc0965dc07521
> > > to master which attempts to automatically collect this information to
> > > ease debugging such failures.
> >
> > It doesn't report anything in this case since the user account does not
> > have permission, and I normally disable core dumps (ulimit -c 0):
> >
> >     Test emacs-tests/seccomp/allows-stdout condition:
> >     Info: Process output:
> >
> >           Potentially relevant Seccomp audit events:
> >           Error opening config file (Permission denied)
> >           NOTE - using built-in logs: /var/log/audit/audit.log
> >           Error opening /var/log/audit/audit.log (Permission denied)
> >
> >           Potentially useful coredump information:
> >           [...]
> >           No coredumps found.
> >           -- Notice: 1 systemd-coredump@.service unit is running, output
> >           may be incomplete.
> >
> > With my root hat on, the audit.log data is attached.
> >
> > With core dumps enabled:
> >  #0  0x00007f7b661fb967 __mmap (libc.so.6)
> >  #1  0x00007f7b5ff8001e sss_nss_mc_get_ctx (libnss_sss.so.2)
>
> Thanks! Looks like the problem is in
> https://github.com/SSSD/sssd/blob/cd843dafe63589d0a77145445c454f6fc19dabae/src/sss_client/nss_mc_common.c#L171-L176,
> where the code calls mmap with flags that we don't allow yet
> (MAP_SHARED).
> Does MAP_SHARED have any security implications? Otherwise we can allow
> it right away.

Does commit 2822246b5d8154d0166e17ffd28a1d85b57d68aa fix the issue?

Message #21 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Sun, 18 Apr 2021 12:19:04 -0400

Philipp Stephani wrote:

> Does commit 2822246b5d8154d0166e17ffd28a1d85b57d68aa fix the issue?

emacs-tests/seccomp/allows-stdout now passes (thanks), but
emacs-tests/bwrap/allows-stdout still fails with status 159:

 #0  0x00007f683ca650f5 _dl_sysdep_start (/usr/lib64/ld-2.28.so)
 #1  0x00007f683ca4d136 _dl_start (/usr/lib64/ld-2.28.so)
 #2  0x00007f683ca4c088 _start (/usr/lib64/ld-2.28.so)

Message #24 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Sun, 18 Apr 2021 19:16:29 +0200

Am So., 18. Apr. 2021 um 18:19 Uhr schrieb Glenn Morris <rgm <at> gnu.org>:
>
> Philipp Stephani wrote:
>
> > Does commit 2822246b5d8154d0166e17ffd28a1d85b57d68aa fix the issue?
>
> emacs-tests/seccomp/allows-stdout now passes (thanks), but
> emacs-tests/bwrap/allows-stdout still fails with status 159:
>
>  #0  0x00007f683ca650f5 _dl_sysdep_start (/usr/lib64/ld-2.28.so)
>  #1  0x00007f683ca4d136 _dl_start (/usr/lib64/ld-2.28.so)
>  #2  0x00007f683ca4c088 _start (/usr/lib64/ld-2.28.so)

What's the failing syscall in this case?

Message #27 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Sun, 18 Apr 2021 17:58:46 -0400

Philipp Stephani wrote:

> What's the failing syscall in this case?

IIUC, it's arch_prctl.

Message #30 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Mon, 19 Apr 2021 10:36:12 +0200

Am So., 18. Apr. 2021 um 23:58 Uhr schrieb Glenn Morris <rgm <at> gnu.org>:
>
> Philipp Stephani wrote:
>
> > What's the failing syscall in this case?
>
> IIUC, it's arch_prctl.

What's the subfunction (first argument)? From looking at the glibc
sources it could be ARCH_CET_STATUS (0x3001).

Message #33 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Mon, 19 Apr 2021 11:49:08 -0400

Philipp Stephani wrote:

>> IIUC, it's arch_prctl.
>
> What's the subfunction (first argument)? From looking at the glibc
> sources it could be ARCH_CET_STATUS (0x3001).

How do I find that out?

(If it helps, the start of the posted audit log corresponds to this case:
https://debbugs.gnu.org/cgi/bugreport.cgi?filename=audit.txt;att=1;bug=47828;msg=12
)

Message #36 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Mon, 19 Apr 2021 18:00:07 +0200

Am Mo., 19. Apr. 2021 um 17:49 Uhr schrieb Glenn Morris <rgm <at> gnu.org>:
>
> Philipp Stephani wrote:
>
> >> IIUC, it's arch_prctl.
> >
> > What's the subfunction (first argument)? From looking at the glibc
> > sources it could be ARCH_CET_STATUS (0x3001).
>
> How do I find that out?

I've often had success with installing the debug symbols for the
libraries in question (often they are in a separate package) and then
using coredumpctl debug to drop into GDB.

Message #39 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Mon, 19 Apr 2021 18:03:10 +0200

Am Mo., 19. Apr. 2021 um 18:00 Uhr schrieb Philipp Stephani
<p.stephani2 <at> gmail.com>:
>
> Am Mo., 19. Apr. 2021 um 17:49 Uhr schrieb Glenn Morris <rgm <at> gnu.org>:
> >
> > Philipp Stephani wrote:
> >
> > >> IIUC, it's arch_prctl.
> > >
> > > What's the subfunction (first argument)? From looking at the glibc
> > > sources it could be ARCH_CET_STATUS (0x3001).
> >
> > How do I find that out?
>
> I've often had success with installing the debug symbols for the
> libraries in question (often they are in a separate package) and then
> using coredumpctl debug to drop into GDB.

Or alternatively, add a rule like

  RULE (SCMP_ACT_ALLOW, SCMP_SYS (arch_prctl),
        SCMP_A0_32 (SCMP_CMP_EQ, 0x3001));

to line 350 of lib-src/seccomp-filter.c and check whether it fixes the problem.

Message #42 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Mon, 19 Apr 2021 12:39:35 -0400

Philipp Stephani wrote:

> Or alternatively, add a rule like
>
>   RULE (SCMP_ACT_ALLOW, SCMP_SYS (arch_prctl),
>         SCMP_A0_32 (SCMP_CMP_EQ, 0x3001));
>
> to line 350 of lib-src/seccomp-filter.c and check whether it fixes the
> problem.

Yes, that fixes it, thank you.

Message #45 received at 47828 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Philipp Stephani <phst <at> google.com>, 47828 <at> debbugs.gnu.org
Subject: Re: bug#47828: seccomp test failures
Date: Mon, 19 Apr 2021 21:31:58 +0200

Am Mo., 19. Apr. 2021 um 18:39 Uhr schrieb Glenn Morris <rgm <at> gnu.org>:
>
> Philipp Stephani wrote:
>
> > Or alternatively, add a rule like
> >
> >   RULE (SCMP_ACT_ALLOW, SCMP_SYS (arch_prctl),
> >         SCMP_A0_32 (SCMP_CMP_EQ, 0x3001));
> >
> > to line 350 of lib-src/seccomp-filter.c and check whether it fixes the
> > problem.
>
> Yes, that fixes it, thank you.

OK, I've pushed commit 27af0a3dc8b6b45879904bbc5d54b0677f84a5ff.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.