bug#47828: seccomp test failures

bug#47828: seccomp test failures

[Glenn Morris]

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))

bug#47828: seccomp test failures

[Philipp Stephani]

Am Fr., 16. Apr. 2021 um 19:59 Uhr schrieb Glenn Morris <rgm@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?

bug#47828: seccomp test failures

[Philipp Stephani]

Am Sa., 17. Apr. 2021 um 20:21 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am Fr., 16. Apr. 2021 um 19:59 Uhr schrieb Glenn Morris <rgm@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.

bug#47828: seccomp test failures

[Glenn Morris]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

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)


[-- Attachment #2: audit.txt --]
[-- Type: text/plain, Size: 3614 bytes --]

type=SECCOMP msg=audit(1618703239.816:666338): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332316 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 arch=c000003e syscall=158 compat=0 ip=0x7f2bf88850f5 code=0x80000000\x1dAUID="someuser" UID="someuser" GID="somegroup" ARCH=x86_64 SYSCALL=arch_prctl
type=ANOM_ABEND msg=audit(1618703239.816:666339): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332316 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 res=1\x1dAUID="someuser" UID="someuser" GID="somegroup"
type=SERVICE_START msg=audit(1618703239.841:666340): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@89-332317-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"
type=SERVICE_STOP msg=audit(1618703240.155:666341): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@89-332317-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"
type=SECCOMP msg=audit(1618703240.643:666342): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332329 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 arch=c000003e syscall=9 compat=0 ip=0x7fbb09a6a967 code=0x80000000\x1dAUID="someuser" UID="someuser" GID="somegroup" ARCH=x86_64 SYSCALL=mmap
type=ANOM_ABEND msg=audit(1618703240.643:666343): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332329 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 res=1\x1dAUID="someuser" UID="someuser" GID="somegroup"
type=SERVICE_START msg=audit(1618703240.664:666344): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@90-332330-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"
type=SERVICE_STOP msg=audit(1618703241.108:666345): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@90-332330-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"
type=SECCOMP msg=audit(1618703241.693:666346): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332347 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 arch=c000003e syscall=9 compat=0 ip=0x7f975300d967 code=0x80000000\x1dAUID="someuser" UID="someuser" GID="somegroup" ARCH=x86_64 SYSCALL=mmap
type=ANOM_ABEND msg=audit(1618703241.693:666347): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332347 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 res=1\x1dAUID="someuser" UID="someuser" GID="somegroup"
type=SERVICE_START msg=audit(1618703241.706:666348): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@91-332348-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"
type=SERVICE_STOP msg=audit(1618703242.024:666349): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@91-332348-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"

bug#47828: seccomp test failures

[Philipp Stephani]

Am So., 18. Apr. 2021 um 02:01 Uhr schrieb Glenn Morris <rgm@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.

bug#47828: seccomp test failures

[Philipp Stephani]

Am So., 18. Apr. 2021 um 10:32 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am So., 18. Apr. 2021 um 02:01 Uhr schrieb Glenn Morris <rgm@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?

bug#47828: seccomp test failures

[Glenn Morris]

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)

bug#47828: seccomp test failures

[Philipp Stephani]

Am So., 18. Apr. 2021 um 18:19 Uhr schrieb Glenn Morris <rgm@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?

bug#47828: seccomp test failures

[Glenn Morris]

Philipp Stephani wrote:

> What's the failing syscall in this case?

IIUC, it's arch_prctl.

bug#47828: seccomp test failures

[Philipp Stephani]

Am So., 18. Apr. 2021 um 23:58 Uhr schrieb Glenn Morris <rgm@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).

bug#47828: seccomp test failures

[Glenn Morris]

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
)

bug#47828: seccomp test failures

[Philipp Stephani]

Am Mo., 19. Apr. 2021 um 17:49 Uhr schrieb Glenn Morris <rgm@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.

bug#47828: seccomp test failures

[Philipp Stephani]

Am Mo., 19. Apr. 2021 um 18:00 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am Mo., 19. Apr. 2021 um 17:49 Uhr schrieb Glenn Morris <rgm@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.

bug#47828: seccomp test failures

[Glenn Morris]

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.

bug#47828: seccomp test failures

[Philipp Stephani]

Am Mo., 19. Apr. 2021 um 18:39 Uhr schrieb Glenn Morris <rgm@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.