"Expanded Security Maintenance for Applications" shown every time I log on!

[Keith]

On 3/12/23 5:26 PM, Bo Berglund wrote:
> On Sun, 12 Mar 2023 14:11:03 -0500, Keith <keithw at caramail.com> wrote:
> 
>> What does the following show?
>>
>> $ ls -l /etc/apparmor.d/tunables
> 
> ls -l /etc/apparmor.d/tunables
> total 56
> -rw-r--r-- 1 root root  624 sep 27  2018 alias
> -rw-r--r-- 1 root root  376 sep 27  2018 apparmorfs
> -rw-r--r-- 1 root root  804 sep 27  2018 dovecot
> -rw-r--r-- 1 root root  720 maj 19  2020 global
> -rw-r--r-- 1 root root  983 sep 27  2018 home
> drwxr-xr-x 2 root root 4096 feb 21  2021 home.d
> -rw-r--r-- 1 root root 1391 maj 19  2020 kernelvars
> -rw-r--r-- 1 root root  631 sep 27  2018 multiarch
> drwxr-xr-x 2 root root 4096 feb 21  2021 multiarch.d
> -rw-r--r-- 1 root root  405 maj 19  2020 securityfs
> -rw-r--r-- 1 root root  819 maj 19  2020 share
> -rw-r--r-- 1 root root  378 maj 19  2020 sys.dpkg-dist
> -rw-r--r-- 1 root root  868 sep 27  2018 xdg-user-dirs
> drwxr-xr-x 2 root root 4096 feb  3  2020 xdg-user-dirs.d
> 
> 
>> Do you have a /etc/apparmor.d/tunables/proc file and is it readable?
> 
> No, does not exist...
> 
>> It's just an ASCII text file and like all the other files in that
>> directory should have 644 perms. If that file is not there or is
>> corrupted then you should reinstall the apparmor package.
>>
>> $ sudo apt install --reinstall apparmor
> 
> ....
> Fetched 494 kB in 0s (5 041 kB/s)
> Preconfiguring packages ...
> (Reading database ... 295205 files and directories currently installed.)
> Preparing to unpack .../apparmor_2.13.3-7ubuntu5.1_amd64.deb ...
> Unpacking apparmor (2.13.3-7ubuntu5.1) over (2.13.3-7ubuntu5.1) ...
> Setting up apparmor (2.13.3-7ubuntu5.1) ...
> AppArmor parser error for /etc/apparmor.d/lsb_release in
> /etc/apparmor.d/tunables/global at line 17: Could not open 'tunables/proc'
> AppArmor parser error for /etc/apparmor.d/nvidia_modprobe in
> /etc/apparmor.d/tunables/global at line 17: Could not open 'tunables/proc'

[snipped]

How odd.
Here's the file list for focal's apparmor package
https://packages.ubuntu.com/focal-updates/amd64/apparmor/filelist

So its surprising that with reinstalling the apparmor apparmor, dpkg 
didn't copy the missing file into the directory after unpacking it.

[snipped]

> I thought apt-get was deprecated....

Nope, it's recommended to use in scripts. The apt command by itself 
doesn't support the "check" action.

> Still:
> 
> $ sudo apt-get check
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> 
No broken packages,k.

> 
>> $ sudo dpkg -C (checks database consistency and looks for packages that
>> may not be fully or correctly installed and suggests what to do to fix
>> the problem)
> 
> THis does nothing, immediately returns...

Well, that means that dpkg thinks the package database is ok. Dpkg 
didn't detect an error when copying the apparmor conf files to their 
destination in /etc/apparmor.d


>>
>> $ sudo dpkg -V (performs md5sum verification on files installed from
>> packages provided that any installed package comes with a file
>> containing the md5sums of its file contents to compare with.)
> 
> Skipped this
> 
>> You can also list individual packages to verify as the above command can
>> take awhile as it calculates md5sums on thousands of installed files.
>>
>> $ sudo dpkg -V apparmor (will quickly tell you if there is integrity
>> issues with the apparmor package files.)
> 
> $ sudo dpkg -V apparmor
> ??5?????? c /etc/apparmor.d/tunables/proc
> ??5?????? c /etc/apparmor.d/tunables/sys

This is a puzzler. ls -l doesn't show the proc file in a directory 
listing, but dpkg did a md5sum verificaton on the proc and sys files. 
The "??5??????" means that dpkg is detecting that the proc and sys files 
have different md5sums as compared to when they were installed. If those 
files were missing, then the output would instead be "missing  c 
/etc/app..." Also, I notice that while you don't show a sys file, there 
is sys.dpkg-dist. This means that at some point a change was made to sys 
and then later a new version of that file was installed which dpkg 
renamed to sys.dpkg-dist in order to preserve the changes made to the 
original. That's default Debian policy.

Anyways, they're simple text files that I've copied to termbin
https://termbin.com/4wp7  - proc
https://termbin.com/xoib8 - sys

Save and copy them to /etc/apparmor.d/tunables
> 
>> Note that -V currently only reports md5sum verification, not whether a
>> file has had its permissions changed from when it was first installed.
> 
> Still no joy...
> 
> Is livepatch or apparmor somehow depending on the desktop?
> I am not using the standard Ubuntu desktop on this device, but it was set up a
> while ago and I think it is MATE, how can I find out from a PuTTY or VNC
> session?
> (the system is in a box and not used interactively).

You don't particularly need livepatch if the server uptime isn't a 
critical requirement and you have maintenance window that can allow you 
to update the kernel and reboot the system instead of applying security 
patches to the running kernel without the necessity of rebooting.

Apparmor is definately needed if you have snaps installed as snapd is 
dependent on it. Apparmor executables and policies provides the 
confinement security of snap programs. Generally, its a security layer 
that enforces access control for other programs like web browsers or 
some network service to limit the kinds of things they could do to the 
system were they to be compromised because of a security vulnerablity.

I would run a fsck on the system drive first chance you get. It's odd 
the proc and sys file didn't show up in the /etc/apparmor.d/tunables 
directory listing, but dpkg was able to perform an md5sum comparison on 
them. Hopefully manually copying the files to the directory will take 
care of the apparmor error messages. Until its fixed, I doubt you'll be 
able to install any snap programs, not just the canonical-livepatch. And 
there might be other non-snap related issues as well.

-- 
Keith