=== chris14_ is now known as chris14
[09:37] <snctfd> howdy, been working with apparmor and noticed some subprofiles were being generated and showing up in apparmor_status, e.g. `[base profile]//null-/bin/cat`. the documentation seems to vaguely hint that this is a "dynamically generated learning profile" (as per https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorProfileSpec#special-prefixes), but i'd like to know when exactly these are created
[09:38] <ebarretto> jjohansen, ^
[09:41] <snctfd> for context, the base profile is running in complain mode and most (if not all) executables specified in the profile are marked as `ix` - am i correct in assuming that the permitted executables will not trigger the creation of these learning profiles, since they are set to inherit the base profile?
[09:44] <snctfd> in this case, `/bin/cat` is not actually allowed in the profile, so i'm assuming the default behavior given that the profile is in complain mode is simply "complain and assign the new process a learning profile"
[10:38] <jjohansen> snctfd, ebarretto: those null-XXX profiles are created when a profile is in complain mode and it executes an application without matching a rule in the profile. This is done even if the application has a profile defined because apparmor does not know if the application being executed will use the predefined profile or if the complain profile will use a different profile, inherit ...
[10:39] <jjohansen> snctfd: you are correct that if a rule exists that specifies ix then the application should inherit and not create a null-XXX profile
[10:40] <jjohansen> and yes, because /bin/cat does not have a rule covering it that would be why it gets a null-XXX profile
[10:54] <snctfd> jjohansen, gotcha, thanks a lot :)
[10:59] <snctfd> jjohansen: follow-up question - what rules exactly do these null-XXX profiles contain? is it just an "audit everything" type deal?
[11:00] <jjohansen> snctfd: well atm, they contain no rules, and unfortunately an old set abi. That is they don't inherit the parents abi
[11:00] <jjohansen> this means they won't audit some rule types atm
[11:00] <jjohansen> and they will re-audit accesses on each occurance
[11:01] <jjohansen> so, pita. Good to get rid of as soon as possible
[11:01] <snctfd> understood
[11:01] <jjohansen> there is wip to give them a cache so they can remember what has already been audited
[11:02] <jjohansen> and also inherit the parent profile abi
[11:02] <jjohansen> the cache will have a size limit but it should greatly reduce repeat audit
[11:03] <jjohansen> but that hasn't landed yet, and I don't expect we will get it done for mantic with the feature window being only a few weeks away and other stuff a priority
[11:04] <snctfd> that makes sense, will keep an eye out for it going forward :)
[11:04] <snctfd> last question, hopefully; is there a way to change the default behavior when executing disallowed files in complain mode from "give child a null-XXX profile" to "inherit profile"?
[11:04] <snctfd> haven't been able to find anything about this so i'm assuming there isn't, but worth a shot asking lol
[11:08] <jjohansen> sorry no there isn't. You might be able to get away with a generic exec rule, ie.
[11:08] <jjohansen>   /** ix,
[11:08] <jjohansen> but if you have any other type of x rule in the profile it will cause conflicts. That is something I hope we can have fixed for 23.10
[11:09] <snctfd> yeah, thought that might be the case
[11:09] <snctfd> thanks for your time, much appreciated :))
=== chris14_ is now known as chris14
=== JanC_ is now known as JanC