1 IRC_meeting_2022 4 12

John Johansen edited this page 2022-04-12 19:07:12 +00:00

(11:00:46 AM) jjohansen1: cboltz, georgiag, jontourville, sbeattie, sarnold: meeting time
(11:00:58 AM) ***cboltz hides
(11:01:01 AM) ***jontourville is here
(11:01:31 AM) jjohansen1: cboltz: well hopefully this will be quick
(11:01:31 AM) ***sbeattie waves hello
(11:02:14 AM) cboltz: No worries, it's my only meeting for today ;-)
(11:02:48 AM) jjohansen1: lets get started
(11:02:56 AM) jjohansen1: the agenda is empty :)
(11:03:11 AM) cboltz: well, I have two things
(11:03:12 AM) jjohansen1: does anybody have anything that we need to discuss
(11:03:22 AM) jjohansen1: cboltz: go
(11:03:32 AM) cboltz: 1 - do we want synonyms in the rule syntax (see discussion in !858)
(11:04:10 AM) cboltz: 2 - backporting of profile updates and additions, especially those merged today (870, 866 and 867)
(11:04:28 AM) cboltz: I guess 2 is a quick one, so we might want to start in reverse order ;-)
(11:04:30 AM) jjohansen1: so, I get not liking them, but we have done them in the past, and the synonyms do match up with the language around a give feature
(11:05:54 AM) jjohansen1: 866 looks fine
(11:06:25 AM) jjohansen1: 867 is fine
(11:06:57 AM) jjohansen1: 870 unlikely, that is a whole new profile
(11:07:26 AM) cboltz: I know, I made it when I became aware of that funny[tm] zgrep/xzgrep bug
(11:07:45 AM) cboltz: (before, my thought basically was "why would you want a profile for such a boring program? ;-)
(11:08:09 AM) sbeattie: boring programs get incorporated into exciting pipelines, alas.
(11:09:15 AM) jjohansen1: sure I get that, but adding a whole new profile in point release is introducing breakage potential
(11:09:48 AM) cboltz: right, I understand that
(11:10:21 AM) cboltz: (I already submitted the zgrep/xzgrep profile to the openSUSE Tumbleweed package, so technically I don't care too much if it also gets backported upstream)
(11:11:01 AM) sbeattie: yes, agreed on not backporting, at least without some widespread testing to ensure that it doesn't break those exciting pipelines people have.
(11:11:29 AM) cboltz: [sidenote re "boring programs": the first surprise was that zgrep and xzgrep are shell scripts - and the second surprise is that they fixed the broken sed call (that was exploitable by funny[tm] filenames) with a different sed call]
(11:12:00 AM) cboltz: ok, then let's wait see if "survived my testing" is good enough ;-)
(11:14:00 AM) sbeattie: re synonyms, the tension is in exposing the complexity and inconsistency of kernel interfaces versus trying to abstract them in such a way as to make writing policy comprehensible.
(11:14:28 AM) sbeattie: (without also making things worse)
(11:15:06 AM) cboltz: indeed, there's no perfect way ;-)
(11:15:47 AM) cboltz: personally I prefer if computer languages only offer one option to do a thing - having more options/keywords for the same thing can be confusing
(11:17:00 AM) jjohansen1: and using different terms than what an interface uses can be confusing
(11:17:34 AM) jjohansen1: its a no win situation, and the correct answer is highly dependent on who ends up being the primary user
(11:18:25 AM) cboltz: I should probably quote a line I already wrote in !858 ;-)
(11:18:29 AM) cboltz:     Hehe, so if someone who is familiar with AppArmor writes the profile using open, the sysv/message queue expert won't understand that, and will ask why it doesn't allow associate ;-)
(11:18:42 AM) cboltz: I guess that's a nice summary of the problem
(11:19:30 AM) cboltz: and I agree that there's no perfect solution
(11:19:34 AM) jjohansen1: yep
(11:20:26 AM) jjohansen1: so 866, and 867 are clean cherry-picks to 3.0 but have merge conflicts in 2.13
(11:20:48 AM) jjohansen1: is 3.0 enough or do we want to carry those patches back further
(11:21:28 AM) sbeattie: well, what is clear is that whether we choose synonyms or not, we need to have clear documentation as to what each keyword means and maps to in the context of the specific subsystem being mediated.
(11:21:45 AM) cboltz: 866 is for an extra profile, therefore I'd say 3.0 is enough
(11:22:12 AM) cboltz: 867 "only" silences the log, therefore I'd also tend not to spend time on backporting to 2.13
(11:23:40 AM) jjohansen1: yes, documentation needs to be clear
(11:24:57 AM) cboltz: indeed, but that still doesn't answer the question if we want synonyms or not ;-)
(11:24:58 AM) jjohansen1: beyond that, I don't think we need to choose today. message queues aren't going to merge soon
(11:25:18 AM) cboltz: I doubt that we have different arguments in a month ;-)
(11:25:30 AM) cboltz: it might sound silly, but - should we just vote?
(11:25:33 AM) jjohansen1: I think we think about. Try and write some documentation
(11:25:49 AM) jjohansen1: and argue about the documentation, and see if that helps
(11:26:43 AM) jjohansen1: it probably won't but, its worth a shot
(11:27:06 AM) ***cboltz wonders if jjohansen1 tries to trick him into writing documentation
(11:27:30 AM) jjohansen1: trick? didn't I just say you would? :P
(11:27:48 AM) sbeattie: testcases also, attempting to use the interfaces and policy in pseudo-anger can also help inform us.
(11:27:58 AM) jjohansen1: yeah
(11:28:17 AM) jjohansen1: atm I think we aren't ready for a vote
(11:28:29 AM) ***sbeattie votes +1 to not voting yet.
(11:28:33 AM) sbeattie: :)
(11:28:51 AM) jjohansen1: and since we don't need to merge yet, lets try to inform ourselves more
(11:28:57 AM) jjohansen1: +1 :)
(11:29:33 AM) cboltz: ok, then let's see what we think in the next meeting ;-)
(11:29:55 AM) cboltz: FYI: georgiag already added synonyms handling to is_covered_localvars() in the tools
(11:30:25 AM) cboltz: that leaves two somewhat technical questions:
(11:31:05 AM) cboltz: - should is_equal_localvars() see "open" and "associate" as _equal_ (because it's a synonym) or as _different_ (because it's another word)?
(11:31:26 AM) jjohansen1: eual
(11:31:33 AM) cboltz: - should get_clean() (aka writing a clean profile) return the rule with the "preferred" synonym?
(11:31:36 AM) jjohansen1: equal, they are functionally the same
(11:33:11 AM) jjohansen1: preferred is we don't change from what was written but, if we are merging two that differ I think it doesn't really matter, probably best we choose what we think is the most common and be consistent
(11:33:28 AM) georgiag: I think get_clean should return both "open" and "associate" in case the queuename is not specified. and the preferred synonym when it is specified 
(11:33:50 AM) jjohansen1: that is possible
(11:34:02 AM) jjohansen1: we can handle the redundance
(11:34:39 AM) cboltz: handle yes, but - what do we win with that redundance?
(11:36:23 AM) jjohansen1: not having to choose :P
(11:37:15 AM) cboltz: ok, you won that round ;-))
(11:38:03 AM) ***georgiag will make the changes
(11:40:25 AM) cboltz: I'm not sure if jjohansen1' comment was meant too serious (mine for sure wasn't ;-)
(11:40:47 AM) jjohansen1: well, it was half in jest
(11:40:59 AM) georgiag: hehe sorry
(11:41:19 AM) cboltz: no need to apologize for making me laugh ;-)
(11:41:27 AM) jjohansen1: no its fine, I don't think its necessarily a bad choice
(11:42:12 AM) jjohansen1: and avoiding choosing .... well for some reason that is compelling :)
(11:42:40 AM) cboltz: ;-)
(11:44:42 AM) jjohansen1: alright, if there is nothing else
(11:44:51 AM) cboltz: well, I have something ;-)
(11:45:05 AM) jjohansen1: okay, go
(11:45:06 AM) cboltz: cache handling
(11:45:16 AM) cboltz: first have a look at https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/L3DTQ34GQL53WEKZUE7REP3XYJVQYSE5/
(11:45:52 AM) cboltz: basically I had some fun with the precompiled cache (which was accidently older than the text profiles, and therefore ignored)
(11:46:24 AM) jjohansen1: yep
(11:46:43 AM) cboltz: however, I'm somewhat afraid that the fix introduces a new problem as long as we only check the timestamps to find out if the precompiled cache is usable
(11:46:54 AM) jjohansen1: so, the plan is to introduce fast hashing of text policy, and store the hash in the compiled file
(11:47:02 AM) jjohansen1: I started the patches several years ago
(11:47:14 AM) jjohansen1: its just a matter of getting time to finish them
(11:47:33 AM) cboltz: I know ;-) - so, when will you have time for this?
(11:47:56 AM) jjohansen1: hopefully its something that we can get done for the next major release
(11:48:33 AM) cboltz: the case I'm afraid of is:  1) new installation  2) admin edits local/foo   3) distro releases a maintenance release for AppArmor (with timestamps newer than the edited local/foo)
(11:48:49 AM) jjohansen1: I have a lot of changes in progress I am trying to squeeze in, while I work on certain more official items to do with say fixing how permissions are carried
(11:49:02 AM) cboltz: if I understand the timestamp-based mechanism right, the parser will think that the precompiled cache from 3) is new enough and use it :-/
(11:49:46 AM) cboltz: yeah, I know you are not bored ;-)
(11:50:16 AM) jjohansen1: so maybe. The timestamp mechanism considers the stamp of each file used by the policy (it does enough of a parse to find all the includes)
(11:50:33 AM) jjohansen1: and it also takes into account the parsers own time stamp
(11:51:04 AM) jjohansen1: so depends on what timestamps are updated in 3)
(11:51:31 AM) cboltz: typically all apparmor-* packages (parser, utils, profiles)
(11:51:52 AM) cboltz: but unfortunately local/foo will still be older than parser and precompiled cache
(11:51:55 AM) jjohansen1: right, the one to worry about with 3 is if it ships precompiled cache
(11:52:03 AM) jjohansen1: in which case yes its a problem
(11:52:13 AM) jjohansen1: timestamps can't do everything
(11:52:50 AM) jjohansen1: we have run into several cases where they are just wrong, for various reasons over the years and that has broken caching
(11:52:57 AM) jjohansen1: thats why we need to do the hashing
(11:53:12 AM) cboltz: agreed
(11:54:11 AM) cboltz: however I'd love to have something now instead of in the 3.1 release ;-)
(11:54:18 AM) cboltz: hmm, a quick (?) fix might be to embed the _parser timestamp_ in the cache file. Would this be as quick as I'd hope, and backport-able?
(11:54:31 AM) jjohansen1: nope, and nope
(11:54:39 AM) cboltz: would have been too easy ;-)
(11:54:49 AM) jjohansen1: yeah
(11:56:37 AM) jjohansen1: alright next meeting is tentatively scheduled for Tuesday May 10
(11:56:43 AM) jjohansen1: meeting adjourned
(11:56:46 AM) jjohansen1: thanks everyone