The officially official Devuan Forum!

You are not logged in.

#1 2020-06-07 22:57:22

specing
Member
Registered: 2019-02-12
Posts: 16  

Apparmor (support) is a complete joke

I am furious, FURIOUS!

Following https://wiki.debian.org/AppArmor/HowToUse, I am unable to setup Apparmor in Devuan Ascii:

First, I had to(!) reboot to boot with apparmor=1 security=apparmor (apparently not possible otherwise).

Second, I had to(!) reboot for a second time after manually(!) setting every single thing to enforce(a-enforce /etc/apparmor.d/*),
because confinement apparently cannot be applied to running processes.


And after all this, # aa-unconfined still reports that everything is unconfined.



How does one setup Apparmor on Devuan Ascii?

Offline

#2 2020-06-08 00:01:07

Altoid
Member
Registered: 2017-05-07
Posts: 411  

Re: Apparmor (support) is a complete joke

Hello:

specing wrote:

... furious ...

Hmmm ...
How about taking two or three cups of chamomile tea?  8^7

---

specing wrote:

... unable to setup Apparmor in Devuan Ascii:
... had to(!) reboot ...
... had to(!) reboot for a second time ...
... still reports that everything is unconfined.

Hmm ...
Tsk, tsk.

Seems you are having a hard time.

specing wrote:

How does one setup Apparmor ...

Try this:

$~ man apparmor

Or this.

Particularly the part that says this:  (because ASCII = Stretch < Buster)

Enable AppArmor
If you are using Debian 10 "Buster" or newer, AppArmor is enabled by default so you can skip this step.   <- if you are running Devuan ASCII, you don't get to skip it.

The AppArmor Linux Security Modules (LSM) must be enabled from the linux kernel command line in the bootloader:

$ sudo mkdir -p /etc/default/grub.d
$ echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=1 security=apparmor"' \
  | sudo tee /etc/default/grub.d/apparmor.cfg
$ sudo update-grub
$ sudo reboot

Now ...
Take a couple of deep breaths and once you are your usual calm self, carry on and try again.

There's far too much BS going on in the world now to get so furious over a nothing. ie: don't be a dick.
Especially on a Sunday night.

Cheers,

A.

Last edited by Altoid (2020-06-08 00:03:15)

Offline

#3 2020-06-08 01:42:35

specing
Member
Registered: 2019-02-12
Posts: 16  

Re: Apparmor (support) is a complete joke

Altoid wrote:

Hmmm ...
How about taking two or three cups of chamomile tea?  8^7

I've downed an entire barrel of it already!

Altoid wrote:
$~ man apparmor

Or this.

I have read through both of that, top to bottom and skipping the Ubuntu section.

Altoid wrote:

Particularly the part that says this:  (because ASCII = Stretch < Buster)

Enable AppArmor
If you are using Debian 10 "Buster" or newer, AppArmor is enabled by default so you can skip this step.   <- if you are running Devuan ASCII, you don't get to skip it.

The AppArmor Linux Security Modules (LSM) must be enabled from the linux kernel command line in the bootloader:

$ sudo mkdir -p /etc/default/grub.d
$ echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=1 security=apparmor"' \
  | sudo tee /etc/default/grub.d/apparmor.cfg
$ sudo update-grub
$ sudo reboot

That was what the first reboot was for in my original post.

Offline

#4 2020-06-08 12:18:22

Altoid
Member
Registered: 2017-05-07
Posts: 411  

Re: Apparmor (support) is a complete joke

Hello:

specing wrote:

I've downed an entire barrel of it already!

Right ...
Seems to have worked.
Good sport!   ;^ )

specing wrote:

... read through both of that ...
... skipping the Ubuntu ...

Good.

specing wrote:

... what the first reboot was for in my original post.

I see.

Please have a look at /etc/default/grub.d/apparmor.cfg:

~$ cat /etc/default/grub.d/apparmor.cfg

There should be a line like this one:

GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=1 security=apparmor"

Cheers,

A.

Offline

#5 2020-06-08 12:24:14

specing
Member
Registered: 2019-02-12
Posts: 16  

Re: Apparmor (support) is a complete joke

Altoid wrote:

Hello:
...There should be a line like this one:
...

There is, and:

cat /proc/cmdline
BOOT_IMAGE=/devuan/root.subvol/boot/vmlinuz-4.9.0-6-amd64 root=UUID=d7e92d18-e57a-4d4a-9f7e-e9301fa4c16e ro rootflags=subvol=devuan/root.subvol quiet apparmor=1 security=apparmor

Offline

#6 2020-06-08 13:33:43

Altoid
Member
Registered: 2017-05-07
Posts: 411  

Re: Apparmor (support) is a complete joke

Hello:

specing wrote:

There is, and:

cat /proc/cmdline 
BOOT_IMAGE=/devuan/root.subvol/boot/vmlinuz-4.9.0-6-amd64 root=UUID=d7e92d18-e57a-4d4a-9f7e-e9301fa4c16e ro rootflags=subvol=devuan/root.subvol quiet apparmor=1 security=apparmor

I see.
Looking for apparmor bug reports I found this:

Devuan bug report logs: bugs in source package apparmor
There is no maintainer for apparmor. This means that this package no longer exists (or never existed). Please do not report new bugs against this package.

Notwithstanding, apparmor would seem to be available as a package for Devuan ascii.

Much to my chagrin, this is as far as I can go with this as it is rather above my pay grade, so to speak and like I mentioned in my first post, I only once had an issue with apparmor showing up on my dmesg, which took me to learn that apparmor was disabled in Devuan ascii and that was it as I was not interested in enabling it.

There has to be a trace of this somewhere in your system logs.
eg: in my case, I get this output in /var/log/syslog:  (same in /var/log kern.log and /var/log/messages)

~$ cat /var/log/syslog | grep -i apparmor 
--- snip ---
[    0.010665] AppArmor: AppArmor disabled by boot time parameter
~$

There is also the remote possibility of a missing dependency.

~# apt-get install -f --dry-run

Check to see what it says and post back.
I'm sure someone knows much more than me about this.

Cheers,

A.

Last edited by Altoid (2020-06-08 13:36:38)

Offline

#7 2020-06-08 18:42:16

specing
Member
Registered: 2019-02-12
Posts: 16  

Re: Apparmor (support) is a complete joke

Altoid wrote:

Hello:
I see.
Looking for apparmor bug reports I found this:

Devuan bug report logs: bugs in source package apparmor
There is no maintainer for apparmor. This means that this package no longer exists (or never existed). Please do not report new bugs against this package.

Looks like the topic title is on point, then D:

Altoid wrote:

Notwithstanding, apparmor would seem to be available as a package for Devuan ascii.

Much to my chagrin, this is as far as I can go with this as it is rather above my pay grade, so to speak and like I mentioned in my first post, I only once had an issue with apparmor showing up on my dmesg, which took me to learn that apparmor was disabled in Devuan ascii and that was it as I was not interested in enabling it.

There has to be a trace of this somewhere in your system logs.
eg: in my case, I get this output in /var/log/syslog:  (same in /var/log kern.log and /var/log/messages)

~$ cat /var/log/syslog | grep -i apparmor 
--- snip ---
[    0.010665] AppArmor: AppArmor disabled by boot time parameter
~$

Everything seems to be enabled, just not working:

Jun  7 22:54:14 devuan kernel: [    0.000000] Kernel command line: BOOT_IMAGE=/devuan/root.subvol/boot/vmlinuz-4.9.0-6-amd64 root=UUID=d7e92d18-e57a-4d4a-9f7e-e9301fa4c16e ro rootflags=subvol=devuan/root.subvol quiet apparmor=1 security=apparmor
Jun  7 22:54:14 devuan kernel: [    0.008000] AppArmor: AppArmor initialized
Jun  7 22:54:14 devuan kernel: [    0.213838] AppArmor: AppArmor Filesystem Enabled
Jun  7 22:54:14 devuan kernel: [    0.404639] AppArmor: AppArmor sha1 policy hashing enabled
Jun  7 22:54:14 devuan kernel: [   11.708360] audit: type=1400 audit(1591563247.192:2): apparmor="STATUS" operation="profile_load" name="ping" pid=1544 comm="apparmor_parser"
Altoid wrote:

There is also the remote possibility of a missing dependency.

~# apt-get install -f --dry-run

Check to see what it says and post back.
I'm sure someone knows much more than me about this.

Cheers,

A.

Everything seems fine:

apt-get install -f --dry-run
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following package was automatically installed and is no longer required:
  dwz
Use 'apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded

I think the problem is how to associate programs with AppArmor profiles. I've installed both apparmor-profiles and apparmor-profiles-extra, and then aa-enforce'd /etc/apparmor.d/*, but that has not produced even one confined process (after reboot, ofcourse... total joke).

Offline

#8 2020-06-08 19:26:40

Altoid
Member
Registered: 2017-05-07
Posts: 411  

Re: Apparmor (support) is a complete joke

Hello:

specing wrote:

Looks like the topic title is on point ...

I beg to differ.
Not having a designated maintainer is not the same as support being a joke.
There could be/are many reasons for not having a maintainer.

specing wrote:

Everything seems to be enabled, just not working:

Jun  7 22:54:14 devuan kernel: [    0.000000] Kernel command line: BOOT_IMAGE=/devuan/root.subvol/boot/vmlinuz-4.9.0-6-amd64 root=UUID=d7e92d18-e57a-4d4a-9f7e-e9301fa4c16e ro rootflags=subvol=devuan/root.subvol quiet apparmor=1 security=apparmor
Jun  7 22:54:14 devuan kernel: [    0.008000] AppArmor: AppArmor initialized
Jun  7 22:54:14 devuan kernel: [    0.213838] AppArmor: AppArmor Filesystem Enabled
Jun  7 22:54:14 devuan kernel: [    0.404639] AppArmor: AppArmor sha1 policy hashing enabled
Jun  7 22:54:14 devuan kernel: [   11.708360] audit: type=1400 audit(1591563247.192:2): apparmor="STATUS" operation="profile_load" name="ping" pid=1544 comm="apparmor_parser"

Right.

specing wrote:

Everything seems fine:

apt-get install -f --dry-run
Reading package lists... Done
Building dependency tree       
Reading state information... Done
specing wrote:

... how to associate programs with AppArmor profiles.
... apparmor-profiles and apparmor-profiles-extra ...

I have seen more than one application with no apparent dependency issues eg: apt-get install -f not installing anything but they would still not work because an unlisted dependency was (obviously) not installed.   

These are the apparmor related (by name) packages that show up in synaptic:

apparmor-easyprof
apparmor-notify
apparmor-utils
dh-apparmor

See if installing these changes anything, especially apparmor-utils and dh-apparmor.

Then check these sites:
https://apparmor.net/
https://medium.com/information-and-tech … 4d7ae211ed

Cheers,

A.

Offline

#9 2020-06-08 21:47:57

specing
Member
Registered: 2019-02-12
Posts: 16  

Re: Apparmor (support) is a complete joke

I have both apparmor-utils and dh-apparmor.

What I just did was install NSCD and what do you know:

43 profiles are loaded.
43 profiles are in enforce mode.
...
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
   /usr/sbin/nscd (3725) 
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

I also just did dpkg-reconfigure apparmor.

The "0 processes are unconfined but have a profile defined." line suggests that everything other than nscd does not have a profile at all. Which means I need to get more profiles somewhere.

And indeed, a short excursion into /etc/apparmor.d reveals that there aren't many profiles present.

Last edited by specing (2020-06-08 21:51:39)

Offline

#10 2020-06-08 22:40:44

Altoid
Member
Registered: 2017-05-07
Posts: 411  

Re: Apparmor (support) is a complete joke

Hello:

specing wrote:

... both apparmor-utils and dh-apparmor.

Right.

specing wrote:

... install NSCD and what do you know:

apparmor started to work.

specing wrote:
43 profiles are loaded.
43 profiles are in enforce mode.
...
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
   /usr/sbin/nscd (3725) 
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
specing wrote:

The "0 processes are unconfined ...
... suggests that everything other than nscd does not have a profile at all.

So the problem was not in apparmor but in how you have to configure it.
Right?

Glad you managed to get it to work.

See?
Wasn't that hard.
Lack of designed maintainer and all.

Cheers,

A.

Offline

#11 2020-06-09 11:21:11

specing
Member
Registered: 2019-02-12
Posts: 16  

Re: Apparmor (support) is a complete joke

Altoid wrote:

Glad you managed to get it to work.

See?
Wasn't that hard.
Lack of designed maintainer and all.

Cheers,

A.

"work" is too strong of a word given the state of AppArmor on this test VM.

Every package I install, every README and man-page I read, every command I execute and ultimately, every post I add to this thread is a further nail to AppArmor-on-Devuan's coffin.


/usr/share/doc/apparmor-profiles/extras/README contains example commands of which: 2/7 do not exist, 4/7 use invocations of aa-enforce/aa-complain that are not documented in their man pages (but actually do something) and the remaining one is useless to me.

I have dhclient running, and there is a dhclient profile in /usr/share/doc/apparmor-profiles/extras/sbin.dhclient. So I followed instructions in the README by copying (which is bad from a maintenance perspective, not to mention that the profile should probably be part of the isc-whatever-dhclient package in the first place) that profile to /etc/apparmor.d. Then I ran

aa-enforce /etc/apparmor.d/sbin.dhclient

which resulted in

Setting /etc/apparmor.d/sbin.dhclient to enforce mode.

Yay, right? Nope: aa-status now says:

44 profiles are in enforce mode.
   /usr/bin/irssi
   ...
   dhclient
   ..

Notice how dhclient has no /sbin in front of it? The heck?

After n+1th reboot, dhclient is still not confined.

This is also funny:

# aa-enforce /sbin/dhclient 
Setting /sbin/dhclient to enforce mode.

ERROR: /etc/apparmor.d/sbin.dhclient contains no profile

(Yes, I've checked:  /etc/apparmor.d/sbin.dhclient does define a profile)

Offline

#12 2020-06-09 11:29:53

specing
Member
Registered: 2019-02-12
Posts: 16  

Re: Apparmor (support) is a complete joke

I've now changed the profile definition line from

profile dhclient /{usr/,}sbin/dhclient

to

profile /sbin/dhclient

Which results in progress:

0 profiles are in complain mode.
2 processes have profiles defined.
1 processes are in enforce mode.
   /usr/sbin/nscd (1899) 
0 processes are in complain mode.
1 processes are unconfined but have a profile defined.
   /sbin/dhclient (880) 

Last edited by specing (2020-06-09 11:30:10)

Offline

#13 2020-06-10 13:45:40

specing
Member
Registered: 2019-02-12
Posts: 16  

Re: Apparmor (support) is a complete joke

I think this is due to networking being ahead of apparmor in the boot order:

TARGETS = mountkernfs.sh eudev keyboard-setup.sh mountdevsubfs.sh brltty bootlogd urandom mountall.sh mountall-bootclean.sh hwclock.sh mountnfs.sh mountnfs-bootclean.sh alsa-utils networking checkroot.sh hostname.sh procps checkfs.sh checkroot-bootclean.sh bootmisc.sh kmod espeakup screen-cleanup x11-common stop-bootlogd-single apparmor

How do I make apparmor start first? Apparently that init script is responsible for loading profiles into the kernel and must run before anything else.
I have tried moving S12apparmor symlink to S00apparmor in /etc/rcS.d/ to no avail.

Offline

#14 2020-06-10 21:12:06

Marjorie
Member
From: Teignmouth, UK
Registered: 2019-06-09
Posts: 55  

Re: Apparmor (support) is a complete joke

I never bothered with apparmor in Ascii but it 'works out of the box' in Beowulf (well almost I had to add a a line to/etc/apparmor/ usr.sbin.cupsd for /etc/dnscrypt-proxy/resolv.conf when I symlinked /etc/resolv.conf to it as then started to complain).

However I can confirm that in Beowulf /etc/rcS.d/S12apparmor does start before /etc/rcS.d/S13networking as one can can see by looking at /var/log/boot. I doubt if moving it any earlier (before file systems are mounted) would help.

Last edited by Marjorie (2020-06-10 21:12:37)

Online

#15 2020-06-10 22:32:32

specing
Member
Registered: 2019-02-12
Posts: 16  

Re: Apparmor (support) is a complete joke

Marjorie wrote:

I never bothered with apparmor in Ascii but it 'works out of the box' in Beowulf (well almost I had to add a a line to/etc/apparmor/ usr.sbin.cupsd for /etc/dnscrypt-proxy/resolv.conf when I symlinked /etc/resolv.conf to it as then started to complain).

However I can confirm that in Beowulf /etc/rcS.d/S12apparmor does start before /etc/rcS.d/S13networking as one can can see by looking at /var/log/boot. I doubt if moving it any earlier (before file systems are mounted) would help.


Upgrading to beowulf will be the best, then. Are there any unconfined processes left?

Offline

#16 2020-06-10 23:05:44

Marjorie
Member
From: Teignmouth, UK
Registered: 2019-06-09
Posts: 55  

Re: Apparmor (support) is a complete joke

Beowulf is now 'stable', and Ascii 'oldstable' so you might well find that upgrading is a good idea.
Not sure what the effect of upgrading an only partially working apparmor will be on apparmor. I did a clean install and then restored my /home directory.

Anyway this is my status report in Beowulf. It says there are no processes unconfined that have a profile defined.

$ sudo service apparmor status
apparmor module is loaded.
23 profiles are loaded.
21 profiles are in enforce mode.
   /usr/bin/evince
   /usr/bin/evince-previewer
   /usr/bin/evince-previewer//sanitized_helper
   /usr/bin/evince-thumbnailer
   /usr/bin/evince//sanitized_helper
   /usr/bin/man
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium
   /usr/sbin/cups-browsed
   /usr/sbin/cupsd
   /usr/sbin/cupsd//third_party
   /usr/sbin/tcpdump
   firejail-default
   libreoffice-senddoc
   libreoffice-soffice//gpg
   libreoffice-xpdfimport
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
2 profiles are in complain mode.
   libreoffice-oopslash
   libreoffice-soffice
3 processes have profiles defined.
3 processes are in enforce mode.
   /usr/sbin/cups-browsed (2095) 
   /usr/sbin/cupsd (2065) 
   /usr/lib/cups/notifier/dbus (3187) /usr/sbin/cupsd
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Online

#17 2020-06-10 23:47:48

specing
Member
Registered: 2019-02-12
Posts: 16  

Re: Apparmor (support) is a complete joke

That means only 3 processes are actually confined. That is not many.

I have to check what the situation is with Fedora/SELinux.

Offline

#18 2020-06-11 08:43:35

Marjorie
Member
From: Teignmouth, UK
Registered: 2019-06-09
Posts: 55  

Re: Apparmor (support) is a complete joke

I think you haven't understood that profiles are only activated ('defined') for running processes.

If I start up Document Viewer (evince) as process /usr/bin/evince with PID 5440 then apparmor defines another process and in this case puts it in enforce mode. Only running programs that have profiles have defined/enforced/complain processes which are then shown with their PID.

Compare this status result with my previous one:

$ sudo service apparmor status
apparmor module is loaded.
23 profiles are loaded.
21 profiles are in enforce mode.
   /usr/bin/evince
   /usr/bin/evince-previewer
   /usr/bin/evince-previewer//sanitized_helper
   /usr/bin/evince-thumbnailer
   /usr/bin/evince//sanitized_helper
   /usr/bin/man
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium
   /usr/sbin/cups-browsed
   /usr/sbin/cupsd
   /usr/sbin/cupsd//third_party
   /usr/sbin/tcpdump
   firejail-default
   libreoffice-senddoc
   libreoffice-soffice//gpg
   libreoffice-xpdfimport
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
2 profiles are in complain mode.
   libreoffice-oopslash
   libreoffice-soffice
5 processes have profiles defined.
5 processes are in enforce mode.
   /usr/bin/evince (5440) 
   /usr/sbin/cups-browsed (2102) 
   /usr/sbin/cupsd (5368) 
   /usr/lib/cups/notifier/dbus (5371) /usr/sbin/cupsd
   /usr/lib/cups/notifier/dbus (5372) /usr/sbin/cupsd
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Note: I've shutdown/restarted overnight which is why the PIDs have all changed. If I close Evince and open LibreOffice Calc I get:

6 processes have profiles defined.
4 processes are in enforce mode.
   /usr/sbin/cups-browsed (2102) 
   /usr/sbin/cupsd (5368) 
   /usr/lib/cups/notifier/dbus (5371) /usr/sbin/cupsd
   /usr/lib/cups/notifier/dbus (5372) /usr/sbin/cupsd
2 processes are in complain mode.
   /usr/lib/libreoffice/program/oosplash (7583) libreoffice-oopslash
   /usr/lib/libreoffice/program/soffice.bin (7631) libreoffice-soffice
0 processes are unconfined but have a profile defined.

Last edited by Marjorie (2020-06-11 08:53:12)

Online

#19 2020-06-11 11:33:59

specing
Member
Registered: 2019-02-12
Posts: 16  

Re: Apparmor (support) is a complete joke

Marjorie wrote:

I think you haven't understood that profiles are only activated ('defined') for running processes.

I have understood it perfectly. A running basic install typically has over 20 processes in addition to the kernel threads. The fact that only 3 of them are confined is worrying.

Why is LO in complain and not enforce?

Offline

#20 2020-06-11 13:57:55

Marjorie
Member
From: Teignmouth, UK
Registered: 2019-06-09
Posts: 55  

Re: Apparmor (support) is a complete joke

Apparmor profiles are only provided for processes that are recognized as potentially dangerous and Apparmor confinement is provided to make your computer safer.

If you do a default Beowulf install you get at default set of profiles that are known to work, or they may be provided with additional packages/programs you install. I've installed LibreOffice from backports and the Firejail package, that is explicitly provided to create a jail for Firefox. These profiles are the one you see in my previous Apparmor status reports.

Profiles that are more experimental that are not guaranteed to work are provided set to complain mode so they don't break anything but you can still use/test them and see what apparmor complains about in the logs.

The Debian package apparmor-profiles provides various experimental Apparmor profiles. It says do not expect them to work out-of-the-box. The package description says "These profiles are not mature enough to be shipped in enforce mode by default on Debian (and hence Devuan). They are shipped in complain mode so that users can test them, choose which are desired, and help improve them upstream if needed". Some even more experimental profiles are included in apparmor-profiles-extras.

Having now installed these optional profile packages the number applied in enforce or complain does not change because they are not being used. Some relate to programs I don't use on my PC (e.g pidgin), some are simply not being used at the moment (e.g. ping, avahi-daemon).

Not every program/process has an Apparmor profile. There is one for Thunderbird (as i don't use this I've moved it to /etc/apparmor.d/disable) but there isn't (to my knowledge) one for Evolution, a program I do use and is running at the moment. Also some programs (such as ping) may only run momentarily so you won't be able to see it enforced/complaining in a status report without opening a second xterm and timing it right.

Here's my apparmor status report with the two experimental profile packages installed:

$ sudo service apparmor status
[sudo] password for marjorie: 
apparmor module is loaded.
46 profiles are loaded.
28 profiles are in enforce mode.
   /usr/bin/evince
   /usr/bin/evince-previewer
   /usr/bin/evince-previewer//sanitized_helper
   /usr/bin/evince-thumbnailer
   /usr/bin/evince//sanitized_helper
   /usr/bin/man
   /usr/bin/pidgin
   /usr/bin/pidgin//sanitized_helper
   /usr/bin/totem
   /usr/bin/totem-audio-preview
   /usr/bin/totem-video-thumbnailer
   /usr/bin/totem//sanitized_helper
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium
   /usr/sbin/apt-cacher-ng
   /usr/sbin/cups-browsed
   /usr/sbin/cupsd
   /usr/sbin/cupsd//third_party
   /usr/sbin/tcpdump
   firejail-default
   libreoffice-senddoc
   libreoffice-soffice//gpg
   libreoffice-xpdfimport
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
18 profiles are in complain mode.
   /usr/bin/irssi
   /usr/sbin/dnsmasq
   /usr/sbin/dnsmasq//libvirt_leaseshelper
   avahi-daemon
   identd
   klogd
   libreoffice-oopslash
   libreoffice-soffice
   mdnsd
   nmbd
   nscd
   ping
   smbd
   smbldap-useradd
   smbldap-useradd///etc/init.d/nscd
   syslog-ng
   syslogd
   traceroute
5 processes have profiles defined.
5 processes are in enforce mode.
   /usr/sbin/cups-browsed (2141) 
   /usr/sbin/cupsd (2109) 
   /usr/lib/cups/notifier/dbus (2110) /usr/sbin/cupsd
   /usr/lib/cups/notifier/dbus (2111) /usr/sbin/cupsd
   /usr/lib/cups/notifier/dbus (3262) /usr/sbin/cupsd
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Last edited by Marjorie (2020-06-11 14:00:00)

Online

#21 2020-06-11 22:32:15

Marjorie
Member
From: Teignmouth, UK
Registered: 2019-06-09
Posts: 55  

Re: Apparmor (support) is a complete joke

Just to add, there are quite a large number of additional profiles that come in the apparmor-profiles package that aren't installed by default. They are put in /usr/share/apparmor/extra-profiles instead. These include basic stuff like postfix, evolution and firefox profiles. However they do warn you that they may not work as intended, and need to be tested in complain mode against your particular installation, and perhaps modified. So I would have to agree that apparmor as currently available, if not a joke, is still quite immature.

Update: Having looked at some of these extra-profiles, they do seem very out of date:  e.g. in the firefox profile I see references to the latest version - Firefox 4 b8 (2010-11); the location of the evolution files changed long ago from that in the profiles (local evolution moved from ~./evolution to ~./local/share/evolution); most of the last modified dates in the other profiles are no later than 2005-2014. Clearly they have not been maintained.

Last edited by Marjorie (2020-06-12 13:56:13)

Online

Board footer