AppArmor kernel config

[roar]

I've noticed that the AppArmor kernel config was switched off from kernels 4.19.x onwards. I've searched the forum and the github issues but haven't found any problems related AppArmor.

I'm using the current kernel for cubox (5.4.x) that I've compiled by adding AppArmor config back, everything works as it should for a headless system.

Would it be possible to add the AppArmor kernel config back? I can help with testing on the following boards: cubox, olimex lime2, cubietruck

[Igor]

2 hours ago, roar said:

Would it be possible to add the AppArmor kernel config back? I can help with testing on the following boards: cubox, olimex lime2, cubietruck

 

I am trying to recall why we disable this in first place - it was probably broken / in a conflict with something while its possible that this is not the case anymore ... if you do test this feature perhaps also with crypto-root, eMMC/USB root install  .... and prepare a PR I don't see any obstacles to merge that in.

 

[roar]

Thanks for the positive reply!

I had thought as much, that it was maybe breaking something else and had been disabled for that reason. However, I'm not sure it even gets loaded if you don't specify the boot parameter for it.

 

I can test this on the boards I have: cubox i, cubietruck and olimex lime 2 with and without eMMC

If it goes well i'll submit a PR with a changed kernel config for these boards

[roar]

So i've gotten round to testing this on the cubox i4 and lime2. Both seem to work fine with the 5.4.22 kernel with apparmor enabled as per the gentoo wiki

I used an ubuntu 18.04 VM with the armbian build system, and used KERNEL_CONFIGURE to change the relevant settings

So far, i've only tried this with an lvm + luks setup on both the cubox i4 and lime2. I took an existing armbian install and just installed the `linux-image` and `linux-dtb` packages on top of it. I also enabled some kernel options for lvm on the lime2, again as per the gentoo wiki

 

Some next steps to try out:

- install to eMMC on the lime2

- try booting from USB/SATA. is this even possible on both boards? i guess armbian-config is good for this

- build a full debian image, flash it and test

[Igor]

On 2/28/2020 at 3:19 PM, roar said:

try booting from USB/SATA. is this even possible on both boards? i guess armbian-config is good for this

Yes, that's generic and it should work.

 

On 2/28/2020 at 3:19 PM, roar said:

and used KERNEL_CONFIGURE to change the relevant settings

When you are changing kernel, configuration is also save to output/config/linux-family-branch.config Copy to config/kernel and submit a PR when done.

 

On 2/28/2020 at 3:19 PM, roar said:

lvm + luks setup

IMO that's already extensive enough.

[ning]

@Igor do you think should we sync no-hardware related kernel configures from debian? thus makes kernel more compatible debian userspace.

[Igor]

2 hours ago, ning said:

do you think should we sync no-hardware related kernel configures from debian? thus makes kernel more compatible debian userspace.

We could do some config merge, on 5.4.y kernels and up?

 

& its some work ... 

[Werner]

This block I grabbed from the linux-image-4.19.0-6-armmp_4.19.67-2+deb10u2_armhf.deb package.

 

Spoiler

CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
CONFIG_SECURITY_APPARMOR_HASH=y
CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
# CONFIG_SECURITY_APPARMOR_DEBUG is not set
# CONFIG_SECURITY_LOADPIN is not set
CONFIG_SECURITY_YAMA=y
CONFIG_INTEGRITY=y
CONFIG_INTEGRITY_SIGNATURE=y
CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y
# CONFIG_INTEGRITY_TRUSTED_KEYRING is not set
CONFIG_INTEGRITY_AUDIT=y
# CONFIG_IMA is not set
# CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is not set
# CONFIG_EVM is not set
# CONFIG_DEFAULT_SECURITY_SELINUX is not set
# CONFIG_DEFAULT_SECURITY_TOMOYO is not set
CONFIG_DEFAULT_SECURITY_APPARMOR=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="apparmor"

 

In comparison for example the most recent sunxi-legacy config from Armbian:

Spoiler

CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=0
CONFIG_SECURITY_APPARMOR_HASH=y
CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
# CONFIG_SECURITY_APPARMOR_DEBUG is not set
# CONFIG_SECURITY_LOADPIN is not set
# CONFIG_SECURITY_YAMA is not set
CONFIG_INTEGRITY=y
							
								  
# CONFIG_INTEGRITY_SIGNATURE is not set
CONFIG_INTEGRITY_AUDIT=y
# CONFIG_IMA is not set
																	  
# CONFIG_EVM is not set
# CONFIG_DEFAULT_SECURITY_SELINUX is not set
# CONFIG_DEFAULT_SECURITY_APPARMOR is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
						

 

There are way more differences between those configs through all areas (not mentioning that debian tries to support many more devices with one kernel).

[Igor]

1 hour ago, Werner said:

4.19.0-6

 

We should merge only kernels 5.4.y and up. Legacy kernels can stay as is. Attached stock Ubuntu 20.04 kernel config from my workstation.

 

Perhaps we should split kernel into sections and make a procedure how to merge this - even there are tools for merge I would rather stick to manual merge and if we share the load somehow, things are not that big. We also have to update this across all our kernels. 

config.ubuntu

[Werner]

21 minutes ago, Igor said:

We should merge only kernels 5.4.y and up.

Yeah I got that. Just provided an example and the config for 4.19 was the first I could think of to get my hands on.