Add "Apparmor" option group to config shell

[rjfd]

ceph-bootstrap

Add a Apparmor option group to the config shell. This group should be able to configure all options required by ceph-salt-formula:apparmor state.

ceph-salt-formula

Currently the apparmor state is not doing much. We should check what was being done in DeepSea (https://github.com/SUSE/DeepSea/tree/master/srv/salt/ceph/apparmor) and add those things to ceph-salt formula.

Also, we need to check what cephadm is doing in this regard, and make sure that what ceph-salt formula preforms is compatible with cephadm.

[sebastian-philipp]

According to @saschagrunert podman will have a new dependency to apparmor-profiles, fixing the issue that @p-se found (https://github.com/SUSE/sesdev/issues/60 )

[p-se]

Moved upstream: https://tracker.ceph.com/issues/43859

[sebastian-philipp]

can we close this issue then?

[smithfarm]

can we close this issue then?

No, please leave the issue open to track the need for a config setting that enables the user to control whether nodes are provisioned (and ceph cluster bootstrapped/deployed) with or without AppArmor.

If AppArmor is set to "off", then ceph-salt should ensure that it is disabled in the containers, too (if that makes any sense).

[smithfarm]

For further rationale, see https://github.com/SUSE/sesdev/issues/136

[smithfarm]

Also relevant for containers in SLE: https://bugzilla.suse.com/show_bug.cgi?id=1165821

[smithfarm]

Now that https://bugzilla.suse.com/show_bug.cgi?id=1165821 is fixed by podman 1.8.0, I'm asking @sebastian-philipp if that means https://github.com/ceph/ceph/pull/33850 can now be reverted, thereby paving the way for work on this issue to go forward?

[smithfarm]

What cephadm is doing with AppArmor? It's definitely doing something:

$ ag -i apparmor src/cephadm/cephadm
5015:    _apparmor_path_list = ['/etc/apparmor']
5371:        """Determine the security features enabled in the kernel - SELinux, AppArmor"""
5390:        def _fetch_apparmor():
5391:            """Read the apparmor profiles directly, returning an overview of AppArmor status"""
5393:            for apparmor_path in HostFacts._apparmor_path_list:
5394:                if os.path.exists(apparmor_path):
5395:                    security['type'] = "AppArmor"
5396:                    security['description'] = "AppArmor: Enabled"
5398:                        profiles = read_file(['/sys/kernel/security/apparmor/profiles'])
5420:            elif 'apparmor' in lsm:
5421:                return _fetch_apparmor()
5425:                    "description": "Linux Security Module framework is active, but is not using SELinux or AppArmor"

[smithfarm]

https://github.com/SUSE/ceph/pull/417 is open to revert https://github.com/ceph/ceph/pull/33850 in SES7

Once we have a build in filesystems:ceph:octopus, it should be possible for ceph-salt to bootstrap a single-node cluster with no AppArmor on it anywhere. I'll verify this.

[smithfarm]

I'll verify this.

Turns out the only way to disable AppArmor completely is to add apparmor=0 to the kernel command line. But it's not easy to make a libvirt VM boot up with a modified kernel commandline. Actually, the only reasonable way is to boot it, modify the GRUB config, and then reboot.

Not sure how relevant this is, but I thought I'd mention it. For details, see:

• https://github.com/SUSE/sesdev/issues/136
• https://github.com/SUSE/sesdev/pull/543

[smithfarm]

@ricardoasmarques @tserong @jan--f Given that ceph-salt apply tries its best to disable AppArmor, although it does not succeed completely, it looks like there's a good chance that, in a SES6 -> SES7 upgrade scenario, it will remove the AppArmor profiles installed by DeepSea. I guess that's the intention, right? We're assuming the unmodified SES6 profiles would not work correctly with the SES7 daemons?

[smithfarm]

What if a user has some other (non-SES-related) production AppArmor profiles on their nodes? Won't ceph-salt apply interfere with those?