APT 1.6 alpha 1 – seccomp and more

I just uploaded APT 1.6 alpha 1, introducing a very scary thing: Seccomp sandboxing for methods, the programs downloading files from the internet and decompressing or compressing stuff. With seccomp I reduced the number of system calls these methods can use to 149 from 430. Specifically we excluded most ways of IPC, xattrs, and most importantly, the ability for methods to clone(2), fork(2), or execve(2) (or execveat(2)). Yes, that’s right – methods can no longer execute programs.

This was a real problem, because the http method did in fact execute programs – there is this small option called ProxyAutoDetect or Proxy-Auto-Detect where you can specify a script to run for an URL and the script outputs a (list of) proxies. In order to be able to seccomp the http method, I moved the invocation of the script to the parent process. The parent process now executes the script within the sandbox user, but without seccomp (obviously).

I tested the code on amd64, ppc64el, s390x, arm64, mipsel, i386, and armhf. I hope it works on all other architectures libseccomp is currently built for in Debian, but I did not check that, so your apt might be broken now if you use powerpc, powerpcspe, armel, mips, mips64el, hhpa, or x32 (I don’t think you can even really use x32).

Also, apt-transport-https is gone for good now. When installing the new apt release, any installed apt-transport-https package is removed (apt breaks apt-transport-https now, but it also provides it versioned, so any dependencies should still be satisfiable).

David also did a few cool bug fixes again, finally teaching apt-key to ignore unsupported GPG key files instead of causing weird errors 🙂


19 thoughts on “APT 1.6 alpha 1 – seccomp and more

  1. > David also did a few cool bug fixes again, finally teaching apt-key to ignore unsupported GPG key files instead of causing weird errors 🙂

    Can we get that backported to stable? There are often people coming into #debian who somehow broke their trusted.gpg – while still having perfectly fine signatures in trusted.gpg.d – which totally breaks updating…

  2. hi, i have some sbuild/schroot boxes, and the new version of apt does not seem to work properly with qemu on my arm builders

    #schroot –all-source-chroots -d / -u root — apt update

    Hit:1 http://ftp.de.debian.org/debian sid InRelease
    Reading package lists… Done
    Building dependency tree
    Reading state information… Done
    37 packages can be upgraded. Run ‘apt list –upgradable’ to see them.
    0% [Working]qemu: Unsupported syscall: 277
    0% [Working]

    as you can see the amd64 update worked but the arm64 hung with that qemu message

      1. I just uploaded 1.6~alpha5 using the QEMU_VERSION hack from the linked bug report, so it should start working again. You of course need to update and upgrade affected chroots with APT::Sandbox::Seccomp set to false first.

  3. hello all
    im getting this error perhaps its related to your update
    W: http: aptMethod::Configuration: could not load seccomp policy: Invalid argument
    am a linux noob googling his erroe output on terminal

  4. hi
    i was running kali linux arm i cant provide you the exact situation now im far from the RPI .. but you can see pple on Github having same issu with the same distro here
    one thing i play with apt-transport-https when i say i play i just run some copie / past from kali blog related to enabling https on APT
    thank you

  5. As mentioned before, I specifically enabled the warning to see if fallback works. There is literally nothing to report here. Everything is working fine. I’m not entirely sure if I’ll disable it completely, or just make a nicer message like “N: Your kernel does not seem to support seccomp, disabling seccomp sandboxing”. But this is definitely not a bug.

  6. Hi Julian.
    After making a good reading of this page since the beginning, I understand that the issue I have posted above is due to my apt package being updated to version 1.6~alpha5, in which you have worked on the seccomp stuff. And I guess that since I run a custom kernel, it does not support the seccomp feature. Am I correct?
    Below are the outputs for dpkg –list | grep apt:
    olimex@micro-a20:~$ sudo dpkg –list | grep apt
    ii apt 1.6~alpha5 armhf commandline package manager
    ii apt-utils 1.6~alpha5 armhf package management related utility programs
    ii aptitude 0.8.10-1 armhf terminal-based package manager
    ii aptitude-common 0.8.10-1 all architecture independent files for the aptitude package manager
    Before installing aptitude, I was running apt version, and it was working fine. I guess that there would be 2 possible solutions there: either enabling seccomp in my kernel by some way (I’m not sure to have the skills to do it), or uninstall aptitude and downgrading apt to previous version. But since I’m not a linux expert I would appreciate that you suggest me the most elegant solution to address that issue efficiently.
    Best regards,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s