"default" profile for processes with kernel credential
Bug #1725335 reported by
Mikhail Kurinnoi
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| AppArmor |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
We had "default" profile feature, as I see this feature was removed from kernel git by some reason and added into "TODO" list (at least I see this marks in kernel sources). But, is it possible add "default" profile for processes with kernel credential?
I mean, could we have 2 "default" profiles? One for processes with kernel credential and one for other processes?
| summary: |
- "default" profiles for processes with kernel credential + "default" profile for processes with kernel credential |
Revision history for this message
| John Johansen (jjohansen) wrote | #1 |
| Changed in apparmor: | |
| status: | New → Triaged |
| importance: | Undecided → Wishlist |
To post a comment you must log in.
The old default profile from boot was never fully implemented, and never supported in Ubuntu. It was removed, because it was not ready for upstream. It would allow you to specify a profile name that would be used instead of unconfined on boot, so assigned to init. Using the grub kernel parameter
unconfined=foo
That profile was in an unconfined state, still unconfined in all but name, until it was replaced. It basically allowed defining a name for the profile on init, and its children until policy was loaded, it was still up to the userspace to load policy, and if early policy was required make it available in the initrd. It never provided a true default profile as there was several cases where unconfined would be used.
It will make a return in a slightly different form, the kernel parameter's name will change to "default", there will be a way to set it as part of the kernel build, and more importantly it will be a try default for the policy namespace, so profile removal will result in tasks falling back to the default instead of unconfined, etc.
The kernel currently runs under an unconfined credential, it would be possible to add a kernel credential that is unconfined in all but name, so kernel tasks could be tracked separate from unconfined. However there isn't currently any plans to allow userspace to specify a policy on kernel tasks.