Canonical Livepatch service for Ubuntu requires snapd+apparmor packages - ISPConfig support?

Hello,

Canonical's relatively new Livepatch service, which provides "live" kernel patching (no reboot required to apply the patches), requires both the "snapd" and "apparmor" packages.

Both of these packages pose problems for ISPConfig: removing apparmor is a requisite for installing ISPConfig, and snapd creates loopback devices that cause problems for ISPConfig's disk usage monitoring (see: https://www.howtoforge.com/community/threads/ubuntu-18-04.79055/ ).

Are there any plans to support Canonical Livepatch on ISPConfig systems?

Thanks in advance.

 

Thanks for the quick reply, Till! Much appreciated.

Glad to hear it, regarding the loopback issue.

Regarding apparmor, will it interfere with ISPConfig even if the only apparmor profiles installed are those pertaining to Snap?

In other words, does apparmor restrict processes "by default", or only when a profile is loaded for them and set to enforce mode? I'm finding this question more difficult to answer than I had expected!

From what I've read, it seems as though a profile must be installed and loaded for apparmor to restrict a process's behavior, in which case having snapd and apparmor installed seems like a non-issue, given my specific configuration.

 

hmm I prefer selinux anyway ^^
regarding apparmor, debian wiki say it can interfer even if not set to enforcing mode
https://wiki.debian.org/AppArmor/HowToUse

oftentimes debian and ubuntu have things in common, dunno about this

 

yes just saying in regard of integration of such system to default setups - it will cause issues with admins preferences.
and the question was wether apparmor might cause issues even if not in enforcing mode - debian at least says yes, dunno ubuntu but possible its the same.

 

Thanks for taking a look, guys!

@till , it looks as though somebody has already created a Feature Request for this (to which I've added a thumbs-up):

https://git.ispconfig.org/ispconfig/ispconfig3/issues/2840

@ztk.me , I should clarify my question slightly: absent an apparmor policy, is it possible for apparmor affect a given executable's behavior?

Everything I've read seems to imply that if there is no policy that targets a specific executable, then apparmor will not interfere with its behavior.

On my system:

Code:

# apparmor_status
apparmor module is loaded.
7 profiles are loaded.
7 profiles are in enforce mode.
   /snap/core/4917/usr/lib/snapd/snap-confine
   /snap/core/4917/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   snap-update-ns.canonical-livepatch
   snap-update-ns.core
   snap.canonical-livepatch.canonical-livepatch
   snap.canonical-livepatch.canonical-livepatchd
   snap.core.hook.configure
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
   snap.canonical-livepatch.canonical-livepatchd (10117)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

This makes me think that apparmor will only target the livepatch daemon, and will not interfere with ISPConfig functionality at all.

In other words, it seems like apparmor would be problematic only if profiles that affect core ISPConfig-controlled services are installed, such as for Apache, NGINX, PHP, Dovecot, Postfix, PureFTPd, etc.

 

I don't think that it is necessary to use Canonical's Livepatch as Ubuntu should be updating the kernel from time to time which is almost the same as patching it except for Ubuntu will tell you to reboot thereafter of which you can schedule the best time for it.

The concern should be weighed against the frequency of kernel updates that need reboot, which I think are currently very minimal especially when you are using the latest version of Ubuntu 18.08, the Bionic Beaver as the reboot are the fastest so far.

There also kexec software on Ubuntu that allows you to load kernel into memory and reboot it as pre-loaded, bypassing hardware initialization normally performed by BIOS or firmware.

There is also script like uktools automatically grab the latest version from Ubuntu mainline kernel server (choose non-rc version as they are considered stable) to keep your kernel updated to the latest and mainstream.

The option is always yours on whether to force yourself in using troublesome softwares or find some other ways around. My cents.