KDE support

[curiosityseeker]

I'm working on some profiles as a starting point to support KDE. Before continuing this work and submitting PRs I would like to coordinate with you how to precede. This is what I'm planning:

1. Creation of a new kde group.

2. Creation of a new akonadi abstraction which makes things a lot easier:

   # vim:syntax=apparmor
   
   abi <abi/3.0>,
   
   include <abstractions/kde>
   include <abstractions/kde-icon-cache-write>
   include <abstractions/mesa>
   include <abstractions/vulkan>
   
   /dev/tty r,
   @{etc_ro}/machine-id r,
   @{etc_ro}/nsswitch.conf r,
   @{etc_ro}/passwd r,
   @{PROC}/sys/dev/i915/perf_stream_paranoid r,
   @{PROC}/sys/kernel/core_pattern r,
   @{sys}/devices/pci[0-9]*/**/{device,revision,subsystem_device,subsystem_vendor,uevent,vendor} r,
   @{system_share_dirs}/qt/translations/{qt,qtbase,qtmultimedia,qtscript,qtxmlpatterns}_*.qm r,
   @{system_share_dirs}/icons/breeze/index.theme r,
   @{system_share_dirs}/mime/generic-icons r,
   
   owner @{HOME}/.config/kdedefaults/kdeglobals r,
   owner @{HOME}/.config/kdedefaults/kwinrc r,
   owner @{HOME}/.config/kdeglobals r,
   owner @{HOME}/.config/kwinrc r,
   owner @{HOME}/.config/akonadi/akonadiconnectionrc r,
   
   # Include additions to the abstraction
   include if exists <abstractions/akonadi.d>

   I'm aware that some rules are already in other abstractions but adding those would make the profiles too permissive, IMO.

The profiles I'm working on are the following:

akonadi_control, akonadiserver, various akonadi_*_resource and akonadi_*_agent profiles, kioslave5, ksysguardd, mariadbd, mariadbd_akonadi, startplasma_wayland

Would creating the suggested group and abstraction be okay for you?

Sidenote: I've also created a new sddm profile which works on my Arch KDE system. The available profile broke my system even in complain mode - that's why I'm still only installing specific profiles. I still have to synchronize both versions. I've also created a sddm-helper profile btw.

[roddhjav]

Nice proposal. Yes having a kde is the good option.

Regarding the abstraction:

• No need of the abi
• @{HOME}/.config -> @{user_config_dirs}
• Sort the rules as in the guidelines

Some recommendations too:

• Please ensure you respect the guideline when creating new profiles.
• Have a look at existing profile in case of doubt, a lot of access pattern are common. A search in the project can save a lot of time to find the good rules that is generic enough (and not specific to your device)

Regarding sddm, a profile in complain mode cannot break the software it confines. However, there are some major exception:

• deny rules are enforced even in complain mode. So for sddm remove the deny in deny capability net_admin, this can help.
• If it needs the attach_disconnected (or the mediate_deleted) flag.
• If apparmor does not find the profile to rPx

Once you push your PR, I will setup a KDE based VM to test it deeply.

[curiosityseeker]

Thanks!

Regarding sddm, a profile in complain mode cannot break the software it confines. However, there are some major exception:

Yes, I was aware of that. I had no time to check then. But indeed, allowing capability net_admin, solved the problem.