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
Cheers,
--
intrigeri
