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 <terceiro at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20151129/a9f5e2e5/attachment.sig>