Hi, Sebastian Andrzej Siewior: > intrigeri, I added you on Cc since you were a help the last time > apparmor came around.
Thanks! Sure, happy to give a hand. I've usertagged this bug so it's on the AppArmor team's radar (and not just on mine). See the corresponding documentation: https://wiki.debian.org/AppArmor/Reportbug#Usertags :) > On 2018-11-06 10:45:15 [+0800], Paul Wise wrote: >> AVC apparmor="DENIED" operation="capable" profile="/usr/sbin/clamd" >> pid=13277 comm="clamd" capability=12 capname="net_admin" >> AVC apparmor="DENIED" operation="open" profile="/usr/sbin/clamd" >> name="/etc/ssl/openssl.cnf" pid=13277 comm="clamd" requested_mask="r" >> denied_mask="r" fsuid=111 ouid=0 > I have no idea what the first one is one about. If this is related to > #903834 then I think I know what I have to do. I doubt this is related to #903834 because this time, the requested capability is missing in the usr.sbin.clamd profile. But in any case, fixing the racy postinst would be good and who knows, it might fix this bug too. The net_admin capability is about modifying the network state, such as creating network devices, changing sysctls such as net.core.somaxconn, using RAW or PACKET sockets, binding to any address, modifying routing tables, some setsockopt() options, this sort of things. If clamd needs to do this sort of things in order to do its job, then the AppArmor profile needs: capability net_admin, If it does not need to do this and works fine with the capability being denied, then you can silence this denial with: deny capability net_admin, Making this judgement call is not always trivial though. For example, while allowing clamd to use the net_admin capability increases the attack surface, it might be that clamd would use this capability to make things safer overall. For this kind of things, upstream developers are often the best placed to tell what's the impact of denying a specific permission their piece of software happens to request. > The second one should be required by every application using libssl. Is > there a general rule where it could be allowed for every application to > just read the openssl.cnf file or is the clamd profile too restrictive > and not allowing it by default? I've noticed that other software recently started reading /etc/ssl/openssl.cnf (no idea why, would be interesting to investigate but not a blocker), e.g. we fixed that same issue in tor (#909364). I guess that's due to a change in OpenSSL or some library clamd is using. I recommend applying the same fix as what we did in src:tor: #include <abstractions/openssl> Cheers, -- intrigeri