coredumb commented on this pull request.
> +# Load config
+[ -r /etc/rc.apparmor ] && . /etc/rc.apparmor
+
+# Proceed to load profiles depending on user settings
+msg "Loading AppArmor profiles..."
+
+if [ "$APPARMOR" != "disable" -a -n "$APPARMOR" ]; then
+ if [ "$APPARMOR" != "complain" -a "$APPARMOR" != "enforce" ]; then
+ printf '! AppArmor incorrect option %s - ignoring profiles\n' "$APPARMOR"
+ exit 0
+ fi
+
+ [ "$APPARMOR" = "complain" ] && AACOMPLAIN="-C"
+
+ if [ -d /etc/apparmor.d -a -x /usr/bin/apparmor_parser ]; then
+ for profile in $(find /etc/apparmor.d -maxdepth 1 -type f); do
apparmor_parser will then try to load everythin recursively as well as files supposed to be included and not loaded directly which ends with a lot of error.
Indeed you end up with your profiles loaded but I think it's nicer to only load profiles
coredumb commented on this pull request.
> @@ -0,0 +1,30 @@
+# vim: set ts=4 sw=4 et:
+
+# AppArmor is not enabled in kernel, silently exit
+[ ! -d /sys/kernel/security/apparmor ] && exit
You're right I overlooked that, I should use return instead of exit
Will fix
coredumb commented on this pull request.
> @@ -0,0 +1,30 @@
+# vim: set ts=4 sw=4 et:
+
+# AppArmor is not enabled in kernel, silently exit
+[ ! -d /sys/kernel/security/apparmor ] && exit
+
+# Load config
+[ -r /etc/rc.apparmor ] && . /etc/rc.apparmor
+
+# Proceed to load profiles depending on user settings
+msg "Loading AppArmor profiles..."
+
+if [ "$APPARMOR" != "disable" -a -n "$APPARMOR" ]; then
I wanted to match explicit "disable" as well but you're right check on unset would be sufficient
will fix
So I made some unixbenchmark runs on linux4.10-4.10.4_1.
The result is an average on 5 runs on 2CPUs VM:
- No LSM enabled (Void repo)
- Index score: **1650**
- AppArmor enabled Kernel with securityfs not mounted
- Index score: **1412**
- AppArmor enabled and the 3 profiles loaded
- Index score: **1661**
I'm pretty sure the result of the run with AppArmor disabled is not relevant. I'll see if I have 2.5h ahead of me to rerun it :)
The results are totally unexpected. I would expect a slightly slower performance on Apparmor kernel enabled (it needed profiling enabled) and worsen with Apparmom userspace enabled.
I think i have to run the tests myself :S
When you have ~3% drop with a full grsec kernel I wouldn't expect anything noticeable
with just a LSM module enabled.
Now benchmarking a userland app confined would certainly give some more relevant numbers.
Gottox commented on this pull request.
Neat! :)
> @@ -32,9 +32,20 @@ post_install() {
vconf ${FILESDIR}/hostname
vconf ${FILESDIR}/os-release
vconf ${FILESDIR}/locale.conf
+ vconf ${FILESDIR}/rc.apparmor
This should go to `/etc/defaults/apparmor`
> @@ -0,0 +1,8 @@
+#!/bin/sh
+[ -r conf ] && . ./conf
+
+# Find all profiles in $APPARMORD and load them
+for profile in $(find ${APPARMORD} -maxdepth 1 -type f); do
+ apparmor_parser -a $profile
+done
+exec chpst -b apparmor pause
Why do we need a sv-service if there's already a core-service? Can you explain?
> @@ -0,0 +1,8 @@
+#!/bin/sh
+[ -r conf ] && . ./conf
+
+# Find all profiles in $APPARMORD and load them
+for profile in $(find ${APPARMORD} -maxdepth 1 -type f); do
`APPARMORD` should default to `/etc/apparmor.d`:
```bash
${APPARMORD:-/etc/apparmor.d}
```
conf file can be removed then.
olivier-mauras commented on this pull request.
> @@ -0,0 +1,8 @@
+#!/bin/sh
+[ -r conf ] && . ./conf
+
+# Find all profiles in $APPARMORD and load them
+for profile in $(find ${APPARMORD} -maxdepth 1 -type f); do
https://github.com/voidlinux/void-packages/pull/13309 let's get the details there ^^