(10:17:06 AM) jjohansen: georgiag, rlee287, cboltz, sarnold, sbeattie, iskunk: meeting time
(10:17:11 AM) rlee287: Hello
(10:17:33 AM) ***cboltz splits between this and another meeting
(10:17:40 AM) mbelair: Hello
(10:18:49 AM) jjohansen: cboltz: is that other meeting drinking wine? :)
(10:19:09 AM) cboltz: no, a video conference
(10:19:43 AM) das_j: Doesn't imply a lack of wine though
(10:20:18 AM) jjohansen: Lets get started
(10:21:35 AM) jjohansen: I am going to push off some of the agenda items to next time, as I am either not ready, or just in the interest of time
(10:21:39 AM) jjohansen: 4.1 update
(10:22:20 AM) jjohansen: I cut a beta5 this morning, release notes are a wip but it is available at https://gitlab.com/apparmor/apparmor/-/releases/v4.1.0-beta5
(10:23:15 AM) jjohansen: this looks to be getting close to actual release, there are a few bugs I would still like to fix, but hopefully all the build and CI errors have been shaken out
(10:23:42 AM) jjohansen: I plan to announce to the mailing list, once the release notes are done
(10:24:42 AM) jjohansen: currently next planned release is 5.0, with beta this fall, and release early next year
(10:25:31 AM) jjohansen: it is possible we could roll a 4.2 picking some of the dev for the fall, that is yet to be decided. Feedback welcome
(10:26:39 AM) jjohansen: The reason for the major version bump is further big improvements to policy, are finally coming down the pipe, specifically some object delegation and rule composition
(10:27:40 AM) jjohansen: next up on the agenda: How to handle /etc/apparmor.d and subdirs
(10:28:12 AM) jjohansen: I don't have the proposal written up yet, so I am going to push it off until next meeting
(10:28:42 AM) jjohansen: oops
(10:28:58 AM) jjohansen: for the meeting agenda is at https://gitlab.com/apparmor/apparmor/-/wikis/MeetingAgenda
(10:29:44 AM) jjohansen: for those following feel free to interrupt, ask questions as we go
(10:29:49 AM) jjohansen: now back to the meeting
(10:30:20 AM) jjohansen: file policy rule order consistency: bumped to next meeting :)
(10:30:50 AM) jjohansen: rlee287: AppArmor utils currently using features beyond Python 3.5
(10:31:04 AM) rlee287: Bumping that one to the next meeting
(10:31:06 AM) sbeattie: is there a pointer to a discussion on the rule order consistency stuff?
(10:31:57 AM) rlee287: In one of the previous IRC meetings (don't remember the date) I think it came down to jjohansen and cboltz having different preferences on the preferred way to write file rules
(10:32:32 AM) sbeattie: ohh, prefix vs postfix on the perms.
(10:32:35 AM) sbeattie: got it.
(10:32:53 AM) cboltz: rlee287: right
(10:33:06 AM) sbeattie: okay, please move on.
(10:33:49 AM) jjohansen: sbeattie: yes, some discussion from a pervious meeting https://gitlab.com/apparmor/apparmor/-/wikis/IRC_meeting_2024-09-10
(10:34:11 AM) rlee287: Next item on the agenda is reviewing a draft CONTRIBUTING.md
(10:34:28 AM) rlee287: Don't think I have time to have an extended discussion about that right now, but the MR is at https://gitlab.com/apparmor/apparmor/-/merge_requests/1457
(10:34:33 AM) rlee287: Comments/feedback welcome
(10:35:12 AM) jjohansen: next up: we have a request to use file extension on profile names (maybe .apparmor) to make it easier for external tooling to know/understand what the files are for
(10:35:30 AM) jjohansen: - rlee287 has proposed aaprof
(10:36:05 AM) jjohansen: - there are also possibilities of
(10:36:05 AM) jjohansen: - .aa
(10:36:05 AM) jjohansen: - .aapol
(10:36:05 AM) jjohansen: - .aapolicy
(10:36:21 AM) jjohansen: other suggestions are welcome
(10:36:29 AM) das_j: aa is already in use by audible btw
(10:37:20 AM) cboltz: with all the existing profiles out there, we probably can't enforce using a suffix (and ignore files without that sufix)
(10:37:22 AM) jjohansen: basically, I think having a standardized extension, is worth having. It will make identifying policy files easier for the user
(10:37:34 AM) jjohansen: the tools will still support not using the extension
(10:37:48 AM) jjohansen: cboltz: correct
(10:38:00 AM) rlee287: Having a suffix would also help with editor syntax highlighting autodetection
(10:38:02 AM) jjohansen: its more of for people, and external tooling
(10:38:52 AM) sbeattie: do we want to differentiate between top level policies, abi files, and/or files intended for inclusion in other profiles?
(10:38:56 AM) rlee287: The question also arises as to whether we want new abstractions to start using the file extensions too or if we want to keep them extensionless C++ style
(10:39:13 AM) mbelair: Agreed, we should just pick an extension that no other software already uses,
(10:39:24 AM) jjohansen: sbeattie: maybe? its not something I have thought a lot about
(10:39:39 AM) ***sbeattie either
(10:39:55 AM) rlee287: I'm concerned about the amount of churn that might be needed if we rename the abstractions
(10:40:06 AM) das_j: apd feels unused. "AppArmor policy definition"
(10:40:19 AM) rlee287: Even if we adjust the inclusion logic to look for both extensioned and extensionless files
(10:40:27 AM) jjohansen: as for abstractions, either works, but I think we can make the tooling smart enough to check both
(10:40:28 AM) sbeattie: rlee287: and breaking third party policies and projects.
(10:40:32 AM) rlee287: That too
(10:41:18 AM) jjohansen: the extension at least for now, needs to be optional
(10:41:18 AM) cboltz: I have a feeling the standard will say something like "_if_ you want an extension, use .aa" (just picking one of the extensions)
(10:42:12 AM) jjohansen: tooling will need to support checking with and without the extension for includes, this will allow things to not break
(10:42:34 AM) das_j: cboltz: or "we recommend using the extension .XX for new profiles and abstractions"
(10:42:54 AM) jjohansen: its possible we could use symlinks and auto-detect and dedup in the future, as a means of migration
(10:43:03 AM) sbeattie: (for the bikeshedding on what extension(s) to use, https://fileinfo.com/ is a useful reference for existing usages)
(10:43:21 AM) rlee287: sbeattie: thanks
(10:44:20 AM) jjohansen: .apd - eclipse plugin detector
(10:44:20 AM) jjohansen: .aa - audible book
(10:44:43 AM) jjohansen: .aap - available
(10:44:57 AM) jjohansen: .aaprof - available
(10:45:10 AM) jjohansen: .aapol - available
(10:45:29 AM) jjohansen: .apparmor - available
(10:45:57 AM) jjohansen: .aapolicy - available
(10:46:10 AM) das_j: aap feels nice and short. And allows me to use 8+3 filenames
(10:46:25 AM) jjohansen: .aaa - cryptowall ransomware encrypted file
(10:46:35 AM) jjohansen: yeah
(10:46:36 AM) cboltz: ;-)
(10:47:12 AM) rlee287: das_j: how important is it to you to be able to use 8+3 filenames
(10:47:40 AM) cboltz: I wonder if re-using .aa would be a serious problem - IMHO it's unlikely that someone confuses an audible book with an AppArmor profile
(10:47:41 AM) das_j: rlee287: it's important for DOS interop ;)
(10:47:53 AM) cboltz: AppArmor on DOS? ;-)
(10:48:17 AM) mbelair: Don't talk about nightmare ;-)
(10:48:30 AM) rlee287: cboltz: I'd rather not have extension collisions that would require opening the file itself to disambiguate, even if disambiguating at that point would be very easy
(10:48:37 AM) das_j: cboltz: not sure how good this is tbh. When I associate aa with Audible on my desktop and I download a profile in my browser, that would be horrible
(10:49:19 AM) jjohansen: hahaha, but you could have ai read you to sleep with policy
(10:49:39 AM) rlee287: lol
(10:49:42 AM) jjohansen: I agree that we shouldn't intentionally collide
(10:49:55 AM) das_j: jjohansen: nightmare fuel, depending what software the profile is for
(10:50:07 AM) jjohansen: we likely will anyways, but at least it will be with something uncommon
(10:50:18 AM) jjohansen: true
(10:50:39 AM) mbelair: I think .aap for AppArmor Policy is a natural way to describe the file. Or we want to be extra explicit and use .apparmor. IMO, the best is among these two
(10:51:08 AM) rlee287: Between those two my vote is for .aap
(10:51:19 AM) jjohansen: I don't really care if the extension is 3 letters, but I do think if we can reasonably do it, then it does have some minor advantages
(10:51:58 AM) sbeattie: I think we don't need to decide on an extension here, but that it's generally agreed upon that we should default to an extension.
(10:52:13 AM) jjohansen: yes
(10:52:28 AM) cboltz: ... while knowing that the extension will be optional for a looong time
(10:52:28 AM) sbeattie: maybe let's open a gitlab issue to discuss and move on in the meeting.
(10:52:38 AM) sbeattie: cboltz: agreed.
(10:52:42 AM) jjohansen: we aren't going to do the work for the 4.1 release, so we have some time to decide, and we can do a vote next meeting
(10:53:06 AM) jjohansen: sure, an issue works
(10:53:10 AM) rlee287: Though we should still make the issue to allow for asynchronous discussion if people want that
(10:54:20 AM) jjohansen: https://gitlab.com/apparmor/apparmor/-/issues/489
(10:55:06 AM) jjohansen: I will throw stuff from todays meeting into the issue, and we can proceed from there, with a revisit of the topic next meeting
(10:55:14 AM) rlee287: Sounds good
(10:55:53 AM) jjohansen: next up rlee287: proposal for re"actual_regex"
(10:56:48 AM) jjohansen: this is a proposal to extend the policy language to support a set of RE in addition to the traditional globbing
(10:57:03 AM) rlee287: This is a proposal to have syntax for using full (non-backtracking) regex syntax, in addition to the current syntax that doesn't easily allow expressing something like [:digit:]+
(10:57:08 AM) jjohansen: I should note this is something that has been planned for a long time
(10:57:22 AM) jjohansen: really what needs to be decided is the syntax for doing it
(10:57:25 AM) rlee287: jjohansen: did not know that before, but thanks for letting me know
(10:57:35 AM) rlee287: Rationale for the syntax I proposed:
(10:57:52 AM) rlee287: - AAREs can already be quoted, which is useful for things like including spaces in AAREs
(10:58:20 AM) rlee287: - A prefix to the quote character is easy to parse and is already done in other languages (e.g. Python r"" raw strings)
(10:58:29 AM) rlee287: - "re" for regex
(10:58:51 AM) rlee287: - Easy backwards compatibility by treating any other AARE in the existing way
(10:59:13 AM) rlee287: Thoughts?
(11:00:15 AM) sbeattie: is there a particular regex engine style you're hoping to support?
(11:00:28 AM) jjohansen: I have created an issue to help track discussion around this topic as well https://gitlab.com/apparmor/apparmor/-/issues/490
(11:00:39 AM) sbeattie: jjohansen: thanks
(11:00:46 AM) jjohansen: not python RE
(11:00:53 AM) jjohansen: :P
(11:00:57 AM) sbeattie: :)
(11:01:18 AM) rlee287: sbeattie: was thinking having at least the commonly used elements such as grouping, alternation, etc. which, to my knowledge, use the same syntax in all the full regex engines I've seen
(11:01:31 AM) jjohansen: I would think a subset of extended regular expression (man 7 regex), or pcre
(11:01:33 AM) sbeattie: More wondering whether the intent is to support complex things like backtracking, etc.
(11:01:48 AM) jjohansen: which are largely the same, the subset might even be the same
(11:01:59 AM) rlee287: I specified "non-backtracking" earlier for the obvious reason that we need to ensure we can still boil everything down to a finite automata
(11:02:46 AM) jjohansen: sbeattie: I would like to avoid, or severely limit backtracking, it has memory and time bounds implications
(11:02:52 AM) sbeattie: also, expanding use of regexs is why it's really important to define profile names for each profile, because writing a regex to match a policy name based on the old aare match pattern is painful.
(11:03:28 AM) jjohansen: generic backtracking in policy could then be used to try and attack the kernel (think dos, spectre)
(11:04:15 AM) rlee287: My preference is to only support things that can be compiled down into a DFA so that the kernel doesn't have to be updated for the new regex features
(11:04:17 AM) jjohansen: yeah, very painful
(11:04:32 AM) sbeattie: +1 on limiting backtracking.
(11:04:39 AM) jjohansen: for now that is indeed the constraint
(11:05:17 AM) jjohansen: I will note, I do have work to allow variables, which could be used for backtracking, but it will have hard limits placed on it
(11:06:14 AM) rlee287: jjohansen: Not sure I understand how variables could be used for backtracking; wouldn't they just boil down to a concatenation of literals and alternations of literals?
(11:06:27 AM) jjohansen: so, for any proposed RE I want to make sure we leave room for extensions, to the RE like variable match or a very tightly scoped backtrack
(11:07:08 AM) jjohansen: rlee287: no, as is runtime kernel defined variables like the actual pid of the process
(11:07:17 AM) rlee287: Ah, OK
(11:07:50 AM) jjohansen: think of each capture group for the backtrack defining one of those ...
(11:08:08 AM) jjohansen: but again would have to be extremely tightly scoped
(11:09:23 AM) jjohansen: I propose we move the discussion to the issue for now, we drop proposals, and constraint in there. And revisit the topic next meeting
(11:09:37 AM) rlee287: Sure
(11:10:34 AM) jjohansen: okay with that, we are out of agenda items. Does anyone have something they would like to discuss
(11:11:04 AM) rlee287: roddhjav: (since you appear to be online) would you like to be added to the ping list for future IRC meetings?
(11:11:27 AM) rlee287: (Nothing else on my end)
(11:12:17 AM) sbeattie: (nothing from me as well)
(11:12:25 AM) cboltz: intrigeri: same question (3 lines above) for you
(11:15:11 AM) jjohansen: well I will bring up 1 more thing
(11:16:04 AM) jjohansen: af_unix mediation is sitting in linux-next, it is behind an abi bump so no current parser will support it
(11:16:24 AM) das_j: Oh man, I actually wanted to ask about af_unix :O
(11:16:56 AM) jjohansen: it would be great if people can test and ensure this isn't breaking systems/causing regressions
(11:17:18 AM) rlee287: How much (if any) of the af_unix stuff is in the Ubuntu kernel?
(11:17:49 AM) jjohansen: the dbus mediation in particular is weird in that to support old parsers, and dbuses without requiring a synchronized dbus update
(11:18:06 AM) jjohansen: that dbus policy is sort of enforced but in an always allow manner
(11:18:09 AM) das_j: jjohansen: why is there an abi issue? I thought AA3 supported the new network abi (v8 I think)
(11:19:00 AM) jjohansen: the goal here is to not have systems with existing policy, and kernels that don't support af_unix and dbus to all of a sudden start enforcing stuff, and cause breakage
(11:19:09 AM) jjohansen: because policy needed an update
(11:19:47 AM) jjohansen: there have been several of these style regressions, around af_unix mediation as it spans, file, network, and dbus policy enforcement
(11:20:46 AM) jjohansen: das_j: sure, I will explain
(11:20:46 AM) jjohansen: 1. af_unix mediation affects: files, network (af_unix) socket, and dbus mediation
(11:21:45 AM) jjohansen: due to some LSM changes, file based unix sockets are partially enforced at the moment, its a mess
(11:22:29 AM) jjohansen: but it is where we are at (btw these changes are fairly old, but after Ubuntu had original support of af_unix)
(11:22:33 AM) jjohansen: anyways
(11:23:26 AM) jjohansen: most non-ubuntu systems, do not support the af_unix extension, and thus fine grained af_unix, dbus, and some of the file system interactions
(11:23:50 AM) jjohansen: but they have been getting policy, with af_unix, dbus, and file rules
(11:24:26 AM) jjohansen: the regression is that when af_unix mediation goes live those things will be enforced
(11:25:22 AM) das_j: But isn't that something the distros are/were supposed to take care of?
(11:25:37 AM) jjohansen: unfortunately with the policy has rules for them, the policy may still need additional changes for those non-ubuntu systems
(11:25:55 AM) jjohansen: das_j: if only life were so easy
(11:25:59 AM) das_j: By the "ubuntu patch", do you mean this one? https://git.helsinki.tools/helsinki-systems/kernel-stuff/-/blob/master/6.12/0002-UBUNTU-SAUCE-apparmor-af_unix-mediation.patch?ref_type=heads
(11:26:44 AM) jjohansen: das_j: no, give me a minute
(11:28:16 AM) jjohansen: the problem is then
(11:28:16 AM) jjohansen: 1. we have potential breakage, and with af_unix it can be brutal. like dbus failures causing the system not to boot ...
(11:28:16 AM) jjohansen: 2. this breakage can't be guarded behind existing abi without a bump
(11:28:28 AM) jjohansen: which leads to the final part of the problem
(11:28:55 AM) jjohansen: kernel devs really hate it, when a new kernel they have built, breaks an existing install
(11:29:14 AM) jjohansen: so while a distro can fix the breakage
(11:29:43 AM) jjohansen: I have to worry about the kernel dev case, because this can and has led to patches in the kernel being reverted
(11:30:54 AM) das_j: ahhh I understand
(11:31:17 AM) jjohansen: anyways, long story short. I have tried landing af_unix before a couple of times, and backed it out because of above said breakage
(11:31:56 AM) jjohansen: af_unix is much worse than anything else because how it interacts with so much of the lowlevel of the desktop
(11:31:59 AM) das_j: Just wanted to ask why not add a new profile ABI, but that's probably not helpful for older AA parsers in existence that will upload the unix rules regardless
(11:32:46 AM) jjohansen: so profile ABI is actually related to kernel features and needs parser support
(11:33:07 AM) jjohansen: its behind a new abi in the kernel, it needs a small patch to the parser
(11:33:21 AM) jjohansen: and policy needs to be updated to use the new abi as well
(11:33:36 AM) jjohansen: I plan to drop the patch into 4.1
(11:33:55 AM) jjohansen: so that we have a current release that supports the upstream kernel af_unix
(11:34:09 AM) jjohansen: it just hasn't landed yet
(11:34:19 AM) das_j: But that sounds like it should just work, right? No parser will upload the new unix rules since they don't understand the kernel ABI
(11:35:32 AM) jjohansen: sadly it does require some parser work
(11:35:48 AM) jjohansen: it is complicated
(11:36:02 AM) das_j: Yeah that I do understand :D
(11:37:05 AM) das_j: Also, even though it's compilicated I am very happy that my af_unix patch rebase to 6.12 was likely the last one 🥳
(11:37:49 AM) L29Ah left the room.
(11:37:56 AM) L29Ah [~L29Ah@0002c65d.user.oftc.net] entered the room.
(11:38:13 AM) jjohansen: next meeting is schedule for Tuesday Mar 11, @18:00 utc. This is after TZ changes for some people so it may shift on your calendar
(11:39:27 AM) jjohansen: das_j: well there is other stuff coming to, other potentials that might land in linux-next in the next 3 weeks are improvements to userns mediation, posix mqueue, and the new networking ip/ipv6
(11:39:41 AM) jjohansen: though I expect that will probably get pushed to 6.16
(11:39:58 AM) jjohansen: anyways, thankyou everyone
(11:39:58 AM) jjohansen: meeting adjourned
Comments
Please register or sign in to add a comment.