1 IRC_meeting_2023 09 12

John Johansen edited this page 2023-09-12 19:14:45 +00:00

(11:00:45 AM) jjohansen: cboltz, georgiag, sbeattie, sarnold, anyone else who is interested meeting time
(11:00:59 AM) ***georgiag is here
(11:01:07 AM) ***cboltz hides
(11:01:37 AM) jjohansen: well, good thing it looks like there is nothing on the agenda so  ...
(11:01:40 AM) jjohansen: :)
(11:02:04 AM) cboltz: well, except the network rules syntax ;-9
(11:02:13 AM) ***sbeattie arises from a grumpy haze
(11:02:31 AM) cboltz: (and I have some MRs that we might want to backport)
(11:02:52 AM) jjohansen: sigh, if we must. lets tackle the MRs first
(11:03:25 AM) jjohansen: what might we want to backport?
(11:03:32 AM) cboltz: https://gitlab.com/apparmor/apparmor/-/merge_requests/1080 - whereever it applies without conflicts
(11:03:51 AM) cboltz: https://gitlab.com/apparmor/apparmor/-/merge_requests/1079 - whereever needed (no idea what that means in branch names ;-)
(11:04:26 AM) cboltz: https://gitlab.com/apparmor/apparmor/-/merge_requests/1090 - 2.13..3.1
(11:04:37 AM) cboltz: https://gitlab.com/apparmor/apparmor/-/merge_requests/1077 - 3.x
(11:04:56 AM) cboltz: https://gitlab.com/apparmor/apparmor/-/merge_requests/1076 - whereever it applies without conflicts
(11:05:35 AM) cboltz: that's what I have on my list
(11:06:33 AM) jjohansen: 1079 - yes
(11:06:33 AM) jjohansen: 1080 - yes
(11:06:33 AM) jjohansen: 1090 - what is the behavior if we don't
(11:07:13 AM) jjohansen: 1077 - feels like a no to me, anyone else?
(11:07:48 AM) cboltz: 1090 - aa-logprof will propose rules like   signal peer=foo//null-/usr/bin/bash
(11:08:09 AM) jjohansen: 1076 - yes
(11:08:29 AM) georgiag: 1079 doesn't need to be backported anywhere as far as I checked
(11:09:12 AM) jjohansen: hrmmm, so of broken but sort of not
(11:10:22 AM) jjohansen: georgiag: I think you are right, that was introduced by one of the cleanup patches, you even have it tagged in the bug
(11:12:28 AM) jjohansen: cboltz: okay for 1090 I am just not sure if its better for logprof to propose the rule with a bad profile name that could later be edited or just ignore the event peer
(11:13:02 AM) jjohansen: obviously 1090 provides your answer :)
(11:13:28 AM) cboltz: indeed, there's no point in proposing a rule that is guaranteed to be useless ;-)
(11:13:36 AM) jjohansen: but does this rise to something that should be backported? Its a change in behavior that isn't obviously right either
(11:14:28 AM) jjohansen: well I suppose if you aren't looking at manually editing the profile ever
(11:15:49 AM) cboltz: the perfect solution would be to apply the chosen exec rule on the signal/ptrace peer, but unless we have this (patches welcome ;-) it's probably better not to propose a silly rule
(11:16:00 AM) jjohansen: so, I am not going to say no to 1090 but I don't see it as a clear yes either, anyone else?
(11:16:52 AM) jjohansen: so, the silence is deafening. cboltz your choice
(11:17:16 AM) jjohansen: alright moving on
(11:17:16 AM) cboltz: ok, then I'll backport it ;-)
(11:17:58 AM) jjohansen: the 4.0 release - its pushed back some, I will try to push out alpha3 later this week
(11:18:03 AM) cboltz: I also wonder about 1077 - does "feels like a no" also mean "your choice"? ;-9
(11:19:14 AM) cboltz: (yeah, I know, your favorite MR in the last months...)
(11:19:37 AM) jjohansen: no, at least not without some body elses input. I know I am biased though, having a strong dislike for what the patch is doing
(11:19:40 AM) georgiag: 1077 is not just a bug fix, so I would tend towards not backporting it
(11:21:45 AM) cboltz: ok, then let's keep 1077 master only
(11:21:50 AM) jjohansen: right, I know those dirs not being auto added might feel like a bug to some but it doesn't to me, and I don't see new policy requiring it so that it introduces a bug as people start using it
(11:22:02 AM) jjohansen: ack, that make me :)
(11:22:56 AM) jjohansen: back to 4.0 - lets shoot for a beta around the start of october, if possible I would like to land the network mediation
(11:23:13 AM) jjohansen: and that needs at least a couple weeks
(11:23:50 AM) jjohansen: which is a perfect segway to the next topic, network mediation syntax
(11:24:21 AM) jjohansen: cboltz: got your charts and slide show ready? :)
(11:24:29 AM) cboltz: ;-)
(11:24:52 AM) cboltz: most important: the port should NOT be part of the IP, since there's a separate port=
(11:25:09 AM) georgiag: I have no strong preferences on the network mediation syntax so any suggestion/recommendation is appreciated 
(11:26:16 AM) jjohansen: hrmmm, port part of ip is however part of existing standards, I really dislike ignoring standards
(11:26:39 AM) jjohansen: I know iptables does a port and dport does it support addr:port
(11:27:07 AM) jjohansen: what of other firewalls/jails?
(11:27:10 AM) jjohansen: sarnold?
(11:27:15 AM) cboltz: yeah, but a parameter called  ip=  should really only allow an IP ;-)
(11:28:15 AM) cboltz: (and IMHO a separate port= is much easier to read and parse)
(11:28:17 AM) ***acidsys wasn't asked but points out that a separate port= reduces the risk of confusing port colons with IPv6 addresses depending on whether AA requires square brackets
(11:28:43 AM) cboltz: indeed, that's another funny detail
(11:29:04 AM) jjohansen: acidsys: any input is more than welcome, please don't feel like you need to wait to be asked
(11:29:20 AM) acidsys: okey, appreciated :-)
(11:29:48 AM) jjohansen: that goes for anyone else lurking too
(11:30:39 AM) jjohansen: so, the confusion with IPv6 is a real reason to avoid addr:port
(11:31:53 AM) jjohansen: refreshing my mind on iptables syntax, they also like to use colons to specify ranges on the ports like --dports 1024:3000
(11:32:26 AM) jjohansen: which could be another point of confusion when mixing ports and addresses
(11:33:11 AM) jjohansen: thats good enough for me as arguments to agree with cboltz, lets keep ports separate
(11:34:19 AM) jjohansen: cboltz: anything thing else you noticed/wanted?
(11:34:28 AM) cboltz: yes
(11:34:34 AM) georgiag: ack. I also think that range to be divided into iprange and portrange is a good idea
(11:35:00 AM) cboltz: georgiag: actually my question goes into that direction ;-)
(11:35:03 AM) cboltz: does it really make sense to have  ip=  range=  _and_  subnet=
(11:35:05 AM) jjohansen: georgiag: can you give a couple of examples?
(11:35:35 AM) cboltz: or should we merge them into   ip=   which would then also allow to specify a  /24  for subnets   or   ...-...   for a range?
(11:36:20 AM) jjohansen: hrmmm. to me, it makes more sense to have range as part of ip or port.
(11:36:32 AM) georgiag: range right now can be used like range=192.168.0.4-192.168.0.39 for ipv4
(11:36:42 AM) georgiag: range=192.168.0.4-192.168.0.39 for ipv6
(11:36:49 AM) georgiag: range=22-443 for ports
(11:37:06 AM) jjohansen: eg. ip tables is --dports 90,22,53  for individual list --dports 1024:3000 for range
(11:37:09 AM) georgiag: oops range=::578d-::94ab, for ipv6
(11:37:32 AM) jjohansen: not saying that iptables syntax is necessarily what we want just, the firewall I have most recently looked at
(11:37:48 AM) cboltz: what about just   ip=192.168.0.4-192.168.0.39   for IPv4?
(11:37:53 AM) jjohansen: and I know this is done with a couple of other firewalls as well
(11:37:57 AM) cboltz: I'd say the  -  makes it clear enough that it's a range
(11:38:22 AM) jjohansen: that wfm, but does it work for ipv6
(11:38:41 AM) jjohansen: I would hate to have a syntax work for one and not the other
(11:38:45 AM) georgiag: it should work for ipv6, it's fine by me
Unknown command.
(11:39:30 AM) cboltz: ok, then the same question for subnets: what about   ip=192.168.0.0/24   ?
(11:39:40 AM) jjohansen: iirc /24 mask should work for both ipv6 and ipv4
(11:39:57 AM) jjohansen: I just don't think it should be combined with range in the same rule
(11:39:58 AM) georgiag: since a range can be specified with the "ip" conditional, then I don't mind removing subnet and having ip=192.168.0.0/24
(11:40:32 AM) jjohansen: subnet is just a specialized range
(11:41:07 AM) jjohansen: I don't have objections to supporting both, the /24 syntax is well established its just not as flexible
(11:42:23 AM) jjohansen: but it makes not sense to have them on the same address ie. no ip=192.168.0.4-192.168.0.39/24
(11:42:24 AM) georgiag: I wanted subnet to be different because an ip can be specified with a mask, even though it's referring to that specific host
(11:42:56 AM) cboltz: jjohansen: right, that example would be invalid syntax
(11:42:59 AM) georgiag: if I run "ip addr", I see that my ip is specified as 192.168.122.12/24 for example
(11:43:01 AM) jjohansen: and georgiag is right ipv6 likes using : syntax for ranges
(11:44:36 AM) cboltz: georgiag: I know, but that's confusing because your computer will only respond on 192.168.122.12  (ip a is just to lazy to display the netmask separately)
(11:44:49 AM) jjohansen: georgia: hrmmm sorry I I missing the distinction between mask and subnet here
(11:45:06 AM) cboltz: for the network rules, 192.168.122.12/24 would meen 192.168.122.0-192.168.122.255
(11:45:18 AM) cboltz: s/meen/mean/
(11:45:19 AM) jjohansen: yes
(11:47:13 AM) georgiag: if you don't think people would be confused then I'm fine with having ip=192.168.122.12/24 meaning 192.168.122.0-192.168.122.255
(11:47:55 AM) cboltz: for me, that's exactly what /24 means in a firewall contect
(11:48:04 AM) cboltz: the only confusing thing is what  ip a  prints ;-9
(11:48:37 AM) georgiag: hehe true
(11:48:37 AM) ***cboltz wonders if his shift key responsible for 9 vs ) is on vacation
(11:49:23 AM) georgiag: I think it's all settled then 
(11:49:41 AM) cboltz: :-)
(11:50:16 AM) jjohansen: anyone else? have any input?
(11:50:21 AM) cboltz: let me ask a bonus quesion (that should also be answered in the to-be-written apparmor.d sniplet):
(11:50:24 AM) cboltz: do these new rules allow to _open_ the specified port on the given IP, or to _connect_ to the specified IP/port, or _both_?
(11:50:46 AM) cboltz: (I couldn't reverse engeneer this from the MR ;-)
(11:51:18 AM) jjohansen: ideally, I would like to see the service rule split we have with dbus
(11:51:53 AM) jjohansen: where opening/binding permission don't get used with the destination/peer
(11:52:13 AM) jjohansen: so we can avoid any potential confusion
(11:52:55 AM) jjohansen: ie something like
(11:52:55 AM) jjohansen: inet bind port=80,
(11:54:03 AM) cboltz: I'd expect   network inet bind port=80,   but besides that, I like it
(11:54:27 AM) jjohansen: especially if we are keeping the apparmor custom of missing option (addr, port ...) means its ignored for this match
(11:59:38 AM) jjohansen: okay, is there any other topics to discuss?
(11:59:43 AM) cboltz: hmm, another question: should we have  sport=  and  dport=  instead of  port=  ?
(12:00:12 PM) jjohansen: that would entirely depend on wheher we keep the peer=(....)
(12:00:38 PM) jjohansen: style syntax that was originally proposed way back when, and everything else has used since
(12:00:53 PM) jjohansen: in that model the port in the peer=() is the dport
(12:01:20 PM) jjohansen: sarnold: ?
(12:01:22 PM) jjohansen: sbeattie: ?
(12:01:54 PM) cboltz: ah, so the idea is to have   network inet peer=(ip=... port=80)   ?
(12:02:01 PM) jjohansen: calling them out because they were involved in the discussion long ago, but anyone is welcome to comment
(12:02:11 PM) cboltz: (not sure if that is part of the MR)
(12:02:48 PM) georgiag: it's not so far. the specified permissions (open, bind, etc) is also not implemented yet
(12:03:08 PM) jjohansen: yeah, I am not worried about that, we are trying to nail down the syntax
(12:03:57 PM) jjohansen: I am more than happy to have a first pass, but we should have kibitz on the syntax for georgia a month ago
(12:03:59 PM) jjohansen: sorry
(12:08:01 PM) jjohansen: well, I guess, no one is going to speak up. lets try running with the plan from ages ago and use peer=() so we have consistency with the other rules
(12:08:29 PM) jjohansen: one last shot at, is there anything else to discuss?
(12:08:51 PM) cboltz: just a quick status update on backporting the MRs
(12:09:05 PM) jjohansen: ok, cboltz go
(12:09:23 PM) cboltz: 1080 (dovecot libexec dir) backported to 3.0 and 3.1
(12:09:54 PM) cboltz: 1076 (firefox profile) not backported - turns out the profile got quite some changes between 3.1 and master
(12:10:20 PM) cboltz: 1090 (//null- peers) also doesn't apply cleanly, therefore I'll open a backport MR later
(12:10:35 PM) cboltz: that's all ;-)
(12:10:42 PM) Talkless left the room (quit: Quit: Konversation terminated!).
(12:11:32 PM) jjohansen: alright with that
(12:11:45 PM) jjohansen: meeting adjourned
(12:11:45 PM) jjohansen: thanks everyone
(12:12:38 PM) cboltz: thanks everyone
(12:13:07 PM) georgiag: thanks!