Bug#806542: liblinux-prctl-perl: autopkgtest failures: seccomp, capbset

[Salvatore Bonaccorso]

Hi,

On Sat, Nov 28, 2015 at 09:03:30PM +0200, Niko Tyni wrote:
> On Sat, Nov 28, 2015 at 07:22:01PM +0100, Salvatore Bonaccorso wrote:
> 
> > > Package: liblinux-prctl-perl
> > > Version: 1.6.0-2 
> 
> > > This package recently started failing its autopkgtest checks on 
> > > ci.debian.net:
> 
> > Thanks for reporting this. I can reproduce the test failures if I
> > build in a LXC container (running sid) on a sid host.
> > 
> > As datapoint: Looks ci.d.n switched from schroot based test to LXC
> > based for at least liblinux-prctl-perl.
> 
> Yeah, that makes sense. I expect the failures are just caused
> by different defaults and/or restrictions inside lxc containers.
> 
> Perhaps an upstream bug ("fails to build in LXC containers") and skipping
> those tests for now would be appropriate?

FTR (not closing this bug!): We have disabled the two tests for the
autopkgtests for now,
https://ci.debian.net/packages/libl/liblinux-prctl-perl/unstable/amd64/

Salvatore

Bug#806542: liblinux-prctl-perl: autopkgtest failures: seccomp, capbset

[Salvatore Bonaccorso]

Hi Niko, hi Antonio

On Sat, Nov 28, 2015 at 09:03:30PM +0200, Niko Tyni wrote:
> On Sat, Nov 28, 2015 at 07:22:01PM +0100, Salvatore Bonaccorso wrote:
> 
> > > Package: liblinux-prctl-perl
> > > Version: 1.6.0-2 
> 
> > > This package recently started failing its autopkgtest checks on 
> > > ci.debian.net:
> 
> > Thanks for reporting this. I can reproduce the test failures if I
> > build in a LXC container (running sid) on a sid host.
> > 
> > As datapoint: Looks ci.d.n switched from schroot based test to LXC
> > based for at least liblinux-prctl-perl.
> 
> Yeah, that makes sense. I expect the failures are just caused
> by different defaults and/or restrictions inside lxc containers.

So indeed this seems the reason. First for the t/capbset.t failures.
The LXC configuration for the debian template contain:

 12 # Default capabilities
 13 lxc.cap.drop = sys_module mac_admin mac_override sys_time

and in same way for t/seccomp.t, this is caused by:

 63 # Blacklist some syscalls which are not safe in privileged
 64 # containers
 65 lxc.seccomp = /usr/share/lxc/config/common.seccomp

where in common.seccomp:

  1 2   
  
  2 blacklist
  3 reject_force_umount  # comment this to allow umount -f;  not recommended
  4 [all]
  5 kexec_load errno 1
  6 open_by_handle_at errno 1
  7 init_module errno 1
  8 finit_module errno 1
  9 delete_module errno 1

In this configuration, get_seccomp will return 2, 

# perl -E 'use Linux::Prctl qw(:constants :functions); say get_seccomp();'
2

   PR_GET_SECCOMP (since Linux 2.6.23)
  Return (as the function result) the secure computing mode of the
  calling thread.  If the caller is not in secure computing  mode,
  this operation returns 0; if the caller is in strict secure com-
  puting mode, then the prctl() call will cause a  SIGKILL  signal
  to be sent to the process.  If the caller is in filter mode, and
  this system call is allowed by the seccomp filters,  it  returns
  2.  This operation is available only if the kernel is configured
  with CONFIG_SECCOMP enabled.

Regards,
Salvatore

Bug#806542: liblinux-prctl-perl: autopkgtest failures: seccomp, capbset

[Antonio Terceiro]

Hi,

On Sun, Nov 29, 2015 at 07:53:55PM +0100, Salvatore Bonaccorso wrote:
> Hi Niko, hi Antonio
> 
> On Sat, Nov 28, 2015 at 09:03:30PM +0200, Niko Tyni wrote:
> > On Sat, Nov 28, 2015 at 07:22:01PM +0100, Salvatore Bonaccorso wrote:
> > 
> > > > Package: liblinux-prctl-perl
> > > > Version: 1.6.0-2 
> > 
> > > > This package recently started failing its autopkgtest checks on 
> > > > ci.debian.net:
> > 
> > > Thanks for reporting this. I can reproduce the test failures if I
> > > build in a LXC container (running sid) on a sid host.
> > > 
> > > As datapoint: Looks ci.d.n switched from schroot based test to LXC
> > > based for at least liblinux-prctl-perl.
> > 
> > Yeah, that makes sense. I expect the failures are just caused
> > by different defaults and/or restrictions inside lxc containers.

Yes, it did. I have a pending announcement email to send about that and
other things.

> So indeed this seems the reason. First for the t/capbset.t failures.
> The LXC configuration for the debian template contain:
> 
>  12 # Default capabilities
>  13 lxc.cap.drop = sys_module mac_admin mac_override sys_time
> 
> and in same way for t/seccomp.t, this is caused by:
> 
>  63 # Blacklist some syscalls which are not safe in privileged
>  64 # containers
>  65 lxc.seccomp = /usr/share/lxc/config/common.seccomp
> 
> where in common.seccomp:
> 
>   1 2 
> 
>   2 blacklist
>   3 reject_force_umount  # comment this to allow umount -f;  not recommended
>   4 [all]
>   5 kexec_load errno 1
>   6 open_by_handle_at errno 1
>   7 init_module errno 1
>   8 finit_module errno 1
>   9 delete_module errno 1
> 
> In this configuration, get_seccomp will return 2, 
> 
> # perl -E 'use Linux::Prctl qw(:constants :functions); say get_seccomp();'
> 2
> 
>PR_GET_SECCOMP (since Linux 2.6.23)
>   Return (as the function result) the secure computing mode of the
>   calling thread.  If the caller is not in secure computing  mode,
>   this operation returns 0; if the caller is in strict secure com-
>   puting mode, then the prctl() call will cause a  SIGKILL  signal
>   to be sent to the process.  If the caller is in filter mode, and
>   this system call is allowed by the seccomp filters,  it  returns
>   2.  This operation is available only if the kernel is configured
>   with CONFIG_SECCOMP enabled.

I'm not sure how to proceed. Granted the lxc setup is way more secure
than the previous schroot one, but we need to reach a compromise between
being secure and being useful. Also, if some code is allowed to be
executed on the buildds -- as I imagine this part of the test suite is
-- it should also be allowed to run on CI. :)

Do you have a recommendation on which lxc settings we might want to
change for the CI test beds?

Also note that at some point I want to add full virtualization with
qemu+kvm, so if it's too difficult to figure out what needs to be
changed maybe we can just declare this tests as needing full
virtualization and they will be skipped for now.

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature

Bug#806542: liblinux-prctl-perl: autopkgtest failures: seccomp, capbset

[Niko Tyni]

Package: liblinux-prctl-perl
Version: 1.6.0-2 
Severity: normal
User: debian-p...@lists.debian.org
Usertags: autopkgtest
X-Debbugs-Cc: Antonio Terceiro 

This package recently started failing its autopkgtest checks on ci.debian.net:
 https://ci.debian.net/packages/libl/liblinux-prctl-perl/unstable/amd64/

I believe this coincides with a system upgrade of ci.debian.net, so
presumably this is caused by the environment there rather than an ABI
incompatibility or something like that. More investigation is needed.

I'm cc'ing Antonio, who's operating ci.debian.net. Does any of this
ring a bell?

  not ok 14 - Checking whether mac_admin is in the bounding set
  
  #   Failed test 'Checking whether mac_admin is in the bounding set'
  #   at t/capbset.t line 16.
  #  got: '0'
  # expected: '1'
  not ok 15 - Checking whether mac_override is in the bounding set
  
  #   Failed test 'Checking whether mac_override is in the bounding set'
  #   at t/capbset.t line 16.
  #  got: '0'
  # expected: '1'
  not ok 29 - Checking whether sys_module is in the bounding set
  
  #   Failed test 'Checking whether sys_module is in the bounding set'
  #   at t/capbset.t line 16.
  #  got: '0'
  # expected: '1'
  
  not ok 35 - Checking whether sys_time is in the bounding set
  
  #   Failed test 'Checking whether sys_time is in the bounding set'
  #   at t/capbset.t line 16.
  #  got: '0'
  # expected: '1'

  not ok 1 - Checking default seccomp value (0)
  
  #   Failed test 'Checking default seccomp value (0)'
  #   at t/seccomp.t line 12.
  #  got: '2'
  # expected: '0'
  not ok 2 - Child received signal
  
  #   Failed test 'Child received signal'
  #   at t/seccomp.t line 21.
  #  got: '0'
  # expected: '1'
  not ok 3 - Child received correct signal
  
  #   Failed test 'Child received correct signal'
  #   at t/seccomp.t line 22.
  #  got: '0'
  # expected: '9'
  
  Test Summary Report
  ---
  t/capbset.t (Wstat: 1024 Tests: 73 Failed: 4)
Failed tests:  14-15, 29, 35
Non-zero exit status: 4
  t/seccomp.t (Wstat: 768 Tests: 3 Failed: 3)
Failed tests:  1-3
Non-zero exit status: 3

Bug#806542: liblinux-prctl-perl: autopkgtest failures: seccomp, capbset

[Salvatore Bonaccorso]

Hi Niko,

On Sat, Nov 28, 2015 at 07:05:00PM +0200, Niko Tyni wrote:
> Package: liblinux-prctl-perl
> Version: 1.6.0-2 
> Severity: normal
> User: debian-p...@lists.debian.org
> Usertags: autopkgtest
> X-Debbugs-Cc: Antonio Terceiro 
> 
> This package recently started failing its autopkgtest checks on ci.debian.net:
>  https://ci.debian.net/packages/libl/liblinux-prctl-perl/unstable/amd64/
> 
> I believe this coincides with a system upgrade of ci.debian.net, so
> presumably this is caused by the environment there rather than an ABI
> incompatibility or something like that. More investigation is needed.
> 
> I'm cc'ing Antonio, who's operating ci.debian.net. Does any of this
> ring a bell?

Thanks for reporting this. I can reproduce the test failures if I
build in a LXC container (running sid) on a sid host.

As datapoint: Looks ci.d.n switched from schroot based test to LXC
based for at least liblinux-prctl-perl.

Had not yet time to investigate closer, any hint in the right
direction would be welcome.

Regards,
Salvatore

Bug#806542: liblinux-prctl-perl: autopkgtest failures: seccomp, capbset

[Niko Tyni]

On Sat, Nov 28, 2015 at 07:22:01PM +0100, Salvatore Bonaccorso wrote:

> > Package: liblinux-prctl-perl
> > Version: 1.6.0-2 

> > This package recently started failing its autopkgtest checks on 
> > ci.debian.net:

> Thanks for reporting this. I can reproduce the test failures if I
> build in a LXC container (running sid) on a sid host.
> 
> As datapoint: Looks ci.d.n switched from schroot based test to LXC
> based for at least liblinux-prctl-perl.

Yeah, that makes sense. I expect the failures are just caused
by different defaults and/or restrictions inside lxc containers.

Perhaps an upstream bug ("fails to build in LXC containers") and skipping
those tests for now would be appropriate?
-- 
Niko