Episode Artwork
1.0x
0% played 00:00 00:00
Sep 06 2024 18 mins   61 1 0

Overview


The long awaited preview of snapd-based AppArmor file prompting is finally
seeing the light of day, plus we cover the recent 24.04.1 LTS release and the
podcast officially moves to a fortnightly cycle.


This week in Ubuntu Security Updates


45 unique CVEs addressed


[USN-6972-4] Linux kernel (Oracle) vulnerabilities



[USN-6982-1] Dovecot vulnerabilities



[USN-6983-1] FFmpeg vulnerability



  • 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)



[USN-6984-1] WebOb vulnerability



  • 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)



[USN-6973-4] Linux kernel (Raspberry Pi) vulnerabilities



[USN-6981-2] Drupal vulnerabilities



[USN-6986-1] OpenSSL vulnerability



  • 1 CVEs addressed in Jammy (22.04 LTS), Noble (24.04 LTS)



[USN-6987-1] Django vulnerabilities



[USN-6988-1] Twisted vulnerabilities



  • 2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS)



[USN-6985-1] ImageMagick vulnerabilities



Goings on in Ubuntu Security Community


Ubuntu 24.04.1 LTS released (02:55)



Ubuntu Security Center with snapd-based AppArmor home file access prompting preview (05:45)



  • https://news.itsfoss.com/ubuntu-security-center-near-stable/

  • Details the new Desktop Security Center application

    • Written by the Ubuntu Desktop team - new application built using Flutter +
      Dart etc and published a snap

    • Eventually this will allow to manage various security related things like
      full-disk encryption, enabling/usage of Ubuntu Pro, Firewall control and
      finally for snap permission prompting

      • this last feature is the only one currently supported - has a single
        toggle which is to enable “snaps to ask for system permissions” -
        aka. snapd-based AppArmor prompting

      • and then once this is enabled, allows the specific permissions to be
        futher fine-tuned










  • What is AppArmor?

  • AppArmor policies - and MAC systems in general are static - policy defined by
    sysadmin etc

  • Not well suited for dynamic applications that are controlled by a user - like
    desktop / CLI etc - can’t know in advance every possible file a user may want
    to open in say Firefox so have to grant access to all files in home directory
    just in case

  • Ideally system would only allow files that the user explicitly chooses -
    number of ways this can be done, XDG Portals one such way - using Powerbox
    concept pioneered in tools from the object-capability based security community
    like CapDesk/Polaris and Plash (principle of least-authority shell) - access
    is mediated by a privileged component that acts with the users whole authority
    to then delegate some of that authority to the application - seen say in the
    file-chooser dialog with portals - this runs outside of the scope of the
    application itself and so has the full, unrestricted access to the system to
    allow a file to be chosen - then the application is then just given a
    file-descriptor to the file to grant it the access (or similar)

  • This only works in the case of applications that open files interactively -
    can’t allow the user to explicitly grant access to the configuration file that
    gets loaded from a well-known path at startup in a server application etc

  • One way to handle that case is to alert the user and explicitly prompt them
    for that access - and this is currently how this new prompting feature works

  • When the feature is enabled, the usual broad-based access rules for the home
    interface in snapd get tagged with a prompt attribute - any access then which
    would normally be allowed is instead delegated to a trusted helper application
    which displays a dialog to the user asking them to explicitly allow such
    access






  • since this happens directly in the system-call path within the kernel, the
    application itself is unaware that this is happening - but is just suspended
    whilst waiting for the users response - and then assuming they grant the
    access it proceeds as normal (or if they deny then the application gets a
    permission denied error)

  • Completely transparent to the application and supports any kind of file-access
    regardless of which API might be used (unlike portals which only support the
    regular file-chooser scenario)

  • Allows tighter control of what files a snap is granted access to - and can be
    managed by the user in the Security Center later to revoke any such permission
    that they granted






  • Has been in development for a long time, and is certainly not a new concept -
    seccomp has supported this via the seccomp_unotify interface - allows to
    delegate seccomp decisions to userspace in a very similar manner - existed
    since the 5.5 kernel released in January 2020

  • Even before that, prototype LSMs existed which implemented this kind of
    functionality (https://sourceforge.net/projects/pulse-lsm/ /
    https://crpit.scem.westernsydney.edu.au/confpapers/CRPITV81Murray.pdf)


  • Can test this now on an up-to-date 24.04 or 24.10 install

    • Need to use snapd from the latest/edge channel and then install both the
      desktop-security-center snap as well as the prompting-client snap

    • Launch Security Center and toggle the option



  • Note this is experimental but has undergone a fair amount of internal testing

  • Very exciting to see this finally available in this pre-release stage - has
    been talked about since at least 2018

  • Give it a spin and provide feedback - I would suggest to use the link in the
    security center application itself for this but it is not working currently -
    instead report via a Github issue on the desktop-security-center project


Get in contact