Episode 236

Posted on Friday, Sep 6, 2024
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.

Show Notes

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