[12:30] <UnivrslSuprBox> sbeattie: You've been subscribed to 2012949 as requested
[13:11] <ahasenack> hi #security, apparmor question. I have this kea-lfc profile, and it contains this bit: https://pastebin.ubuntu.com/p/ZqD5ZX5sQ6/
[13:11] <ahasenack> you'll note a comment wondering about including <abstractions/nameservice> instead of those individual rules for resolv.conf, nsswitch.conf, etc
[13:11] <ahasenack> I looked at that abstraction, and it will also allow ldap stuff (because nsswitch -> nss_ldap -> ldap stuff)
[13:12] <ahasenack> a bug came in just now, where a user has an actual /etc/resolv.conf file which is not a symlink to the stub in /run/systemd/....
[13:12] <ahasenack> and the obvious fix is to allow /etc/resolv.conf r, too
[13:12] <ahasenack> but now I'm wondering even more whether it's just not better to include that abstraction
[13:12] <ahasenack> thoughts?
[13:13] <sdeziel> there are many valid targets for `/etc/resolv.conf`
[13:13] <sdeziel> systemd-resolved provide 2 (stub being the default)
[13:14] <ahasenack> afaik systemd was the only one replacing resolv.conf with a symlink, am I mistaken?
[13:14] <ahasenack> I thought resolvconf just replaced the file entirely
[13:14] <ahasenack> (but I have never used it, tbh)
[13:16] <sdeziel> resolvconf and openresolv come to mind
[13:17] <sdeziel> that said, neither are in lunar anymore so maybe you can get away without the abstraction :)
[13:18] <ahasenack> the other thing about using an abstraction, is that I can benefit from improvements done to the abstraction
[13:18] <ahasenack> it's like a library
[13:20] <ahasenack> but that nameservice abstractions really does include many others
[13:20] <ahasenack> nis, ldapclient, winbind, likewise (!), mdns, kerberosclient, nss-systemd
[13:20] <ahasenack> likewise(-open), I think that was from lucid
[13:20] <ahasenack> back when we momentarily had a big push to ldapify things
[13:22] <sdeziel> I personally always go with the abstraction but I'm curious to hear from #security as well :)
[13:25] <sdeziel> ahasenack: I didn't look at the full apparmor profile but if you don't include the `<abstractions/nameservice>` you probably need to allow the network bits to let the connection to the DNS server happen
[13:25] <ahasenack> one downside is that, if there is a problem with the abstraction, fixing that is going to be in a different package
[13:26] <ahasenack> I allow dgram, for udp
[13:26] <ahasenack> the nameservice abstraction does allow that and more
[13:26] <ahasenack> stream also, for ipv4 and ipv6
[13:26] <ahasenack> so maybe that's another reason to include the abstraction instead
[13:27] <ahasenack> ok, I'm almost convinced
[13:27] <sdeziel> ahasenack: the user lookup also sometimes require the dbus rules
[13:32] <ahasenack> I wouldn't expect this user (a system user: _kea) to be in ldap or any other network-type of user db lookup, but I don't know about dbus being user for that
[13:32] <ahasenack> that would be a systemd thing I suspect?
[13:32] <ahasenack> dynamic systemd users, for services?
[13:33] <sdeziel> yeah, I'll try to dig up the bug I'm half remembering, sec
[13:34] <sdeziel> ahasenack: https://bugs.launchpad.net/snapd/+bug/1869024
[13:34] -ubottu:#ubuntu-security- Launchpad bug 1869024 in apparmor (Ubuntu) "add support for DynamicUser feature of systemd" [High, Fix Released]
[13:36] <ahasenack> "The abstraction is meant to cover the client, not systemd internal specifics. A client simply accessing that DBus API won't need it and a client simply accessing those sockets won't need it."
[13:36] <ahasenack> might not need it, though
[13:36] <ahasenack> or was that about boot_iod
[13:36] <ahasenack> or was that about boot_id
[13:36] <sdeziel> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1796911 <= from you where bind/named would trip on this
[13:36] -ubottu:#ubuntu-security- Launchpad bug 1796911 in apparmor (Ubuntu) "libnss-systemd was denied talking to pid1" [High, Fix Released]
[13:37] <ahasenack> huh, I filed that
[13:38] <sdeziel> that comment about the client not needing those doesn't apply here because kea is the daemon doing the UID change so causing the user lookup, no?
[13:38] <ahasenack> maybe
[13:40] <ahasenack> we don't even have resolvconf anymore (going back to /etc/resolv.conf), but debian does
[13:40] <ahasenack> this was a bug filed by a debian user against debian, btw
[13:40] <ahasenack> I'm monitoring the isc-kea debian bugs because my apparmor profile landed there too
[13:44] <ahasenack> ok, install resolvconf in debian, and you get /etc/resolv.conf -> ../run/resolvconf/resolv.conf
[13:45] <ahasenack> which the nameservice abstraction covers
[13:45] <ahasenack> but not my profile