You are not logged in.
Pages: 1
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
Hello:
... furious ...
Hmmm ...
How about taking two or three cups of chamomile tea? 8^7
---
... 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.
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
Hmmm ...
How about taking two or three cups of chamomile tea? 8^7
I've downed an entire barrel of it already!
$~ man apparmor
Or this.
I have read through both of that, top to bottom and skipping the Ubuntu section.
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
Hello:
I've downed an entire barrel of it already!
Right ...
Seems to have worked.
Good sport! ;^ )
... read through both of that ...
... skipping the Ubuntu ...
Good.
... 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
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
Hello:
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
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:
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"
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
Hello:
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.
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.
Everything seems fine:
apt-get install -f --dry-run Reading package lists... Done Building dependency tree Reading state information... Done
... 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
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
Hello:
... both apparmor-utils and dh-apparmor.
Right.
... install NSCD and what do you know:
apparmor started to work.
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.
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
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
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
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
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)
Offline
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
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.
Offline
That means only 3 processes are actually confined. That is not many.
I have to check what the situation is with Fedora/SELinux.
Offline
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)
Offline
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
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)
Offline
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)
Offline
I'm more furious to have apparmor bloatware enabled by default.
First thing I did, stopped the service and apt purge that thing out of my laptop.
Is a laptop, not a server.
Having it enabled by default is IMHO a very stupid choice.
Offline
just an fyi, i would treat apparmor on a case by case basis. When im not using openbsd i use firejail profiles.
As this person says in below link, most profiles are ubuntu based.
https://github.com/cryptofuture/apparmor-profiles
and ive read one should maybe only use firejail or apparmor, not both together.
Offline
Pages: 1