1 IRC_meeting_2024 06 11

John Johansen edited this page 2024-06-11 19:06:42 +00:00

(11:01:13 AM) jjohansen: cboltz, georgiag, mbelair, sbeattie, sarnold, anyone else who is interested, meeting time
(11:01:22 AM) ***georgiag is here
(11:01:44 AM) ***cboltz is 50% here
(11:02:05 AM) ***iskunk is here
(11:05:21 AM) jjohansen: so we don't really have anything on the agenda, maybe policy layout but I don't think I am ready to discuss that
(11:05:39 AM) jjohansen: so I will give a quick update
(11:06:20 AM) jjohansen: 4.x has so far proven to be quite buggy, we are working on a 4.0.2 release before we make the broader 4.0 release announcement
(11:06:37 AM) jjohansen: I think we are close now
(11:06:57 AM) jjohansen: cboltz: how do feel the tool side is?
(11:08:06 AM) cboltz: when the pending MRs are merged, and the bug I opened for unix rules is fixed, the tools should be fine
(11:08:37 AM) jjohansen: ack, I think the parser is largely the same
(11:08:59 AM) jjohansen: so hopefully, we can cut a new release this weekend
(11:09:19 AM) jjohansen: kernel side: there is a lot in flight
(11:10:16 AM) cboltz: having 4.0.2 soon would be nice, the patch count in the openSUSE package is a bit ;-) larger than I'd like
(11:10:28 AM) jjohansen: the goal is to merge more cleanups upstream for 4.11, it would be nice if we can get to the dfa merge but I doubt that will happen as I don't have it ready yet
(11:10:43 AM) jjohansen: the only feature I would like to see land is af_uinx mediation
(11:11:11 AM) jjohansen: however it will break abi, so current user space parsers will not support it
(11:11:48 AM) jjohansen: support in userspace might be backported to 4.0.x
(11:12:04 AM) jjohansen: so it doesn't have to wait for the fall release
(11:13:34 AM) cboltz: will that then need <abi/4.0.3> or so? ;-)
(11:13:38 AM) jjohansen: the fall release is currently scheduled as 4.1 however, if we manage to land rule priorities, boolean operations, and a couple other things that are wip the policy we be different enough to justify going with 5.0
(11:14:17 AM) jjohansen: cboltz: yes, use of the new upstream af_unix will require a new abi file
(11:14:41 AM) jjohansen: its a good point. Policy won't just start using it
(11:15:04 AM) jjohansen: backporting it would only make it available
(11:15:24 AM) cboltz: that sounds like a good argument to switch the version number to 4.1 - and make 4.0.x a _really_ short-lived release
(11:15:45 AM) jjohansen: though there might be potential to have a config to promot the af_unix in the old abi to allow use of new
(11:16:12 AM) jjohansen: cboltz: actually that isn't a half bad idea
(11:22:21 AM) iskunk left the room.
(11:22:34 AM) iskunk [~oftc-webi@sas08022.nat.sas.com] entered the room.
(11:22:45 AM) jjohansen: okay, that is all I have
(11:23:09 AM) jjohansen: so time to open it up, does anyone else have something they would like to discuss?
(11:23:20 AM) iskunk: I have a few questions
(11:23:34 AM) jjohansen: iskunk: ok, go
(11:23:50 AM) iskunk: dbus labels: before I could do name=org.freedesktop.UPower, now there's only label=unconfined ... how does that get straightened out? it's not just writing up profiles for them, is it?
(11:25:21 AM) iskunk: (btw, the webchat frontend dropped me for a few minutes, in case I disappear)
(11:26:06 AM) jjohansen: iskunk: can you clarify about now there is only label=unconfined?
(11:26:06 AM) jjohansen: has name= been dropped from the profile
(11:26:06 AM) jjohansen: is it not being reported
(11:26:06 AM) jjohansen: is the parser dying on it
(11:26:06 AM) jjohansen: is logprof/genprof dying on it
(11:26:17 AM) jjohansen: also are you using dbus or dbus-broker
(11:26:52 AM) jjohansen: iskunk: yeah noticed the drop, no worries, nothing happen while you were out either
(11:27:32 AM) iskunk: (great!) this is related to the firefox profile MR... I had a profile break due to the name= no longer being set, just the label. (I am using the same profile on debian+ubuntu, so there may be a difference in the distro setup)
(11:28:30 AM) iskunk: I'm just wondering what is needed so that all dbus endpoints have a proper name, since it seems haphazard whether it's set or not from aa's pov
(11:30:05 AM) iskunk2 [~iskunk@sas08022.nat.sas.com] entered the room.
(11:30:20 AM) iskunk: arrrgh
(11:30:51 AM) jjohansen: ah! got it
(11:31:00 AM) iskunk2: (trying hexchat now)
(11:31:22 AM) jjohansen: unfortunately it is some what hap hazard
(11:31:57 AM) iskunk2: there's no way to set it reliably with some config?
(11:32:26 AM) iskunk2: (then again, I would think it would get the name the same way it gets the dbus path/interface/etc.)
(11:33:41 AM) jjohansen: so name= is depend on how the application registers with the dbus. It is up to the application/service to be consistent
(11:34:31 AM) iskunk2: hmmm... that's odd, I wouldn't expect to see a regression like this, then. so if I see a dbus service that doesn't have a proper name, I can file that as a bug against the service?
(11:34:59 AM) jjohansen: there are so technicalities around dbus and name= that I am not remembering, so I could be getting something wrong, I will need to dig a little
(11:35:24 AM) jjohansen: but yeah it might be a bug in dbus, or in the service
(11:35:47 AM) iskunk2: okay. I just want to know what is needed to get this resolved, as it's been an ongoing annoyance. will get back to you on the MR for addressing that specific profile.
(11:35:56 AM) jjohansen: or it is possible that there is a patch in recent dbus that changed something. I am going to have to do some digging, to figure out which it is
(11:36:13 AM) iskunk2: wouldn't expect that to cause a regression, either... at least, I'd hope not
(11:36:27 AM) iskunk2: new Q: is the aa 4.0 bugginess the reason it's not yet in debian?
(11:36:49 AM) jjohansen: for the label= portion, we just want to abstract that to a variable, based on what the expect target is like UPower
(11:37:13 AM) cboltz: you'll have to ask the Debian apparmor maintainer ;-)
(11:37:14 AM) jjohansen: atm that variable might just specify
(11:37:14 AM) jjohansen: @{UPower}=unconfined
iskunk iskunk2 
(11:37:41 AM) iskunk2: but is there a way to write the profile so that either label=unconfined or name=Foo.bar... is accepted?
(11:37:55 AM) jjohansen: iskunk2: partially, while we have cut releases, we haven't done an official announcement either
iskunk iskunk2 
iskunk iskunk2 
(11:38:20 AM) jjohansen: iskunk2 yes
(11:38:25 AM) iskunk2: I was surprised to do a sid testing install and still see all the old 3.x stuff
(11:38:49 AM) jjohansen: @{UPower}=unconfined Foo.bar
(11:38:52 AM) iskunk2: can I do e.g. ({label=unconfined,name=Foo.bar})
(11:39:08 AM) jjohansen: will allow unconfined of Foo.bar
iskunk iskunk2 
(11:39:35 AM) iskunk2: but one is "label", the other is "name" ...
(11:40:22 AM) jjohansen: oh I sorry, I missed that.  No that isn't possible in one rule, you can get that with 2 rules
(11:40:58 AM) iskunk2: ah, nuts. would it be OK for now to just do without that last line, no label nor name?
(11:41:05 AM) jjohansen: one will have
(11:41:05 AM) jjohansen:   name=Foo.bar
(11:41:05 AM) jjohansen: the other will have
(11:41:05 AM) jjohansen:    label=unconfined
(11:41:05 AM) jjohansen: the rest is the same
(11:41:35 AM) iskunk2: would make for a lot of extra verbiage in the profiles if you want to cover your bases
(11:41:37 AM) jjohansen: yes its not the cleanest solution but it will work
iskunk iskunk2 
(11:42:25 AM) iskunk2: okay, please let me know (in the MR) what the root cause is, if bug reports need to be filed against other projects I'll be happy to go after them.
(11:42:29 AM) jjohansen: iskunk2 specifying neither will work it, will then allow any value for those two conditionals that have been left off
iskunk iskunk2 
(11:42:45 AM) jjohansen: iskunk2: ack
(11:43:16 AM) iskunk2: that's what I'm thinking as a stopgap measure. the rule is already matching the other dbus keywords, so it shouldn't be too bad, I hope
(11:43:41 AM) jjohansen: right
(11:44:16 AM) iskunk2: new Q: re 4.0 bugginess, I've run into some cases where an application is affected by restrictions (I can see the syscalls failing in strace), yet there is no aa denial message in syslog. is that considered a filable bug?
(11:44:42 AM) jjohansen: yes
(11:45:01 AM) iskunk2: okay, i've got a bit of material there
(11:45:27 AM) iskunk2: new Q: feasible to get in some profile backports to 4.0 before the next release?
(11:46:39 AM) jjohansen: basically, if you have an issue file it, we will work it and try to figure out why. Once its figured out it will get fixed or if it isn't actually apparmor then at least we know that and it can be closed that way to
iskunk iskunk2 
(11:47:04 AM) iskunk2: mainly wondering if that was a known issue already
(11:47:27 AM) jjohansen: iskunk2: possible yes. a release this weekend would be nice, but it will also depend on bugs, and work todo
(11:48:06 AM) iskunk2: okay. I'll try to get the firefox MR sorted out asap, and then include it in a backport MR.
(11:48:15 AM) jjohansen: its less work to not have to do a 4.0.3 release a week or two after the 4.0.2 release so delay a little is an option
(11:48:49 AM) iskunk2: might end up needing the time... hope I'm not adding too much to your workload :-)
(11:48:50 AM) ***cboltz wonders if "no delay" was ever an option for releases
(11:49:21 AM) iskunk2: last Q: is there a known deadline for getting in a 24.04 SRU?
iskunk iskunk2 
(11:50:46 AM) georgiag: iskunk2: there's already one sru on the way: https://launchpad.net/ubuntu/noble/+queue?queue_state=1&queue_text=apparmor unfortunately we still need the SRU team to approve it so it will land in the -proposed pocket, then spend 7 days there and then it will be available in the -updates pocket
(11:50:47 AM) jjohansen: iskunk2: a specific SRU yes, in an SRU no. currently 4.0.1 is working its way through SRU so it is to late for that. We are planning on SRUing 4.0.2, so that is another opportunity
(11:51:05 AM) jjohansen: and I know we plan to do an SRU after 4.0.2
(11:51:59 AM) iskunk2: okay, understood. I'm assuming the backport is needed as a first step? and then the request to get those specific profiles updated in the SRU
(11:52:34 AM) jjohansen: cboltz: yes, "no delay" is an option. There has to be a good reason for it, because in my experience releasing a broken release instead of delaying is more work. And since we are already so resource constrained that really sucks
iskunk iskunk2 
(11:52:47 AM) jjohansen: iskunk2 yes
(11:53:22 AM) cboltz: agreed, broken releases don't help anyone
(11:53:27 AM) iskunk2: okay, sounds good. georgiag: thanks for the link, I see that went out a number of days ago, so no near miss there :)
(11:53:44 AM) jjohansen: or at least greatly preferred, Ubuntu side like suse side we are trying to keep the patchset carried beyound the upstream release minimal
(11:53:56 AM) georgiag: on the backport topic, I'd like us to try to always have a bug attached to the commit message, or to the merge request. that makes it a lot easier to file SRUs on ubuntu's side
(11:54:26 AM) iskunk2: all right, that's all on my end. will keep chugging away at those profiles, as usual. thanks for your help, everyone!
(11:54:51 AM) jjohansen: not just the Ubuntu side, it is pretty much a requirement on the debian side
(11:55:00 AM) cboltz: jjohansen: keeping the patch count minimal didn't really work for 4.0.1 - it came with some, well, surprises ;-)
iskunk iskunk2 
(11:55:06 AM) jjohansen: thanks for the work iskunk2
(11:55:35 AM) jjohansen: cboltz: indeed, but that is why you would like a 4.0.2 soon
(11:55:37 AM) jjohansen: us too
(11:55:38 AM) iskunk2: georgiag: understood. will try to do cherry-picks, but if it's just a new commit, I'll make sure to refer to bug reports
iskunk iskunk2 
(11:56:17 AM) jjohansen: iskunk2 yes just a buglink works. we don't care if its apparmor, debian, suse, ubuntu, ...
(11:56:50 AM) iskunk2: sounds good, there should be receipts for all the changes
(11:59:59 AM) jjohansen: does anyone have anything else they would like to discuss
(12:00:10 PM) georgiag: nothing else from me :)
(12:00:13 PM) cboltz: nothing from me
(12:00:25 PM) iskunk2: all good here
(12:01:30 PM) jjohansen: okay, I would like to skip the July meeting as atm I will likely be unavailable
(12:02:07 PM) jjohansen: so next meeting would then be August 13 @18:00
(12:02:23 PM) jjohansen: meeting adjourned
(12:02:23 PM) jjohansen: thanks everyone
(12:03:13 PM) cboltz: thanks