On 2018-01-07 14:59:54 [+0100], intrigeri wrote: > Hi, Hi, > Francois Gouget: > /etc/apparmor.d/usr.sbin.clamd profile, then. > > > So here is my feedback on the current configuration: […] > > Thanks for thinking this through. I'm not knowledgeable with ClamAV so > I'll stick to general comments and recommendations based on my > experience maintaining AppArmor support in Debian and Tails. > I'll leave it to the ClamAV maintainers to decide what they think is > best for Debian and its users. > > Some more data points for context: > > * Ubuntu has been shipping this AppArmor profile since April, 2009.
I think we included it on their request. > * In the Ubuntu bug tracker I see exactly one AppArmor-related bug: > https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1659223 this does not look related to this bug. > * Since AppArmor has been enabled by default in Debian testing/sid > (mid-November, 2017) one single user reported a regression caused > by this change with clamd. > > So with my AppArmor in Debian maintainer hat, I would find it > reasonable if the clamav-daemon maintainers decided to leave it as-is, > possibly improving a little bit the existing documentation in > README.Debian to provide better guidance to power-users whose use case > is not supported by the current AppArmor policy. I'm happy to help > with the latter part if needed. So looking at this I think it is just fine. clamd should only access specific files which includes files from postfix & exim spool directories. By allowing accessing everything it kind of defeats its purpose (however I am not sure how that $HOME rule works). The rules file ends with | # Site-specific additions and overrides. See local/README for details. | #include <local/usr.sbin.clamd> Maybe if you could provide some info how to add a local rule to enable clamd to read everything, that would be nice. > > * Use 'clamdscan --fdpass'. This completely bypasses the apparmor profile. > > What are the security implications of that? As far as I can tell it's It does not completely bypass the the profile because the profile does not forbid fd-passing. It could :). So clamd it not allowed to open random files on its own but it can open any file that the user (at the other end of the socket) is able to. > > not possible to reopen an existing fd with different access bits so > > if clamdscan opens the file to be scanned in read-only mode, then clamd > > should not be able to write to it. So why not make --fdpass the default? > > I'm not knowledgeable enough wrt. ClamAV to have an informed opinion > on this idea but I find it interesting :) If you want to have it used / enabled by default then I could ask upstream what they do think about it. From the build logs, fdpassing is supported on linux & kfreebsd so it should work everywhere within Debian. > Cheers, Sebastian _______________________________________________ Pkg-clamav-devel mailing list Pkg-clamav-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel