fedora-selinux August 2010 archive
Main Archive Page > Month Archives  > fedora-selinux archives
fedora-selinux: Re: Clamd - again...

Re: Clamd - again...

From: Dominick Grift <domg472_at_nospam>
Date: Sun Aug 22 2010 - 18:08:13 GMT
To: selinux@lists.fedoraproject.org

On 08/22/2010 11:29 AM, Arthur Dent wrote:
> Hello all,
>
> Since upgrading from F11 to F13 I still have 3 outstanding issues. 1 is
> my earlier thread about mlogc which is still the subject of some
> correspondence on the modsecurity list, another is a mysterious "leaked
> file descriptor" AVC which has a permissive type anyway so I will worry
> about that later (and may have stopped since the latest selinux policy
> release) and that just leaves clamd... sigh...
>
> The relationship between procmail and clamd and selinux always seems to
> be a troubled one and I don't know why it should be so, but hey...
>
> Every time I upgrade Fedora I go through this little dance - remove my
> old home made clamd policy, run my fetchmail->procmail->clamd( and
> spamd)-> dovecot mail-chain and see what AVCs emerge. I create a policy
> using audit2allow, rinse, repeat until all AVCs go away.

So why not do it properly this time and help fix this upstream?

Can you remove your custom modules and enclose raw AVC denials please?

> Well I have done that as usual, all the AVCs have gone away, but still I
> get this message in my logs:
> X-virus-report: /usr/local/bin/clamdscan error 2
> X-virus-checker-version: clamassassin 1.2.4 with clamdscan / ERROR: Can't connect to clamd: Permission denied
>
> But NO AVCs
>
> I have proved that selinux is the culprit. Putting SEL into permissive
> mode temporarily allows clamd to work as it should (but still no AVCs).
>
> I am a little reluctant to do the "semodule -DB" to reveal any silent
> denials as I get swamped with stuff (but if that's what it takes...)
>
> In the meantime can anyone suggest any other approach?

Show us raw AVC denials, also for the rules you added below. Also use
semodule -DB to collect the AVC denials as it may reveal hidden denials.

> Here is my current clamd module as created by audit2allow:
>
> =========================8<========================================
> # cat selinux/myclamd.te
> module myclamd 13.1.3;
>
> require {
> type unconfined_t;
> type var_run_t;
> type clamd_var_run_t;
> type initrc_t;
> type procmail_t;
> class sock_file write;
> class unix_stream_socket connectto;
> }
>
> #============= procmail_t ==============
> allow procmail_t initrc_t:unix_stream_socket connectto;
> #!!!! This avc is allowed in the current policy

What is running initrc_t? Can you show the raw avc denial.

> allow procmail_t unconfined_t:unix_stream_socket connectto;
> #!!!! This avc is allowed in the current policy
>
> allow procmail_t var_run_t:sock_file write;

Mislabeled sock file.

> allow procmail_t clamd_var_run_t:sock_file write;
> #!!!! This avc is allowed in the current policy

This does look legit to me

> =========================8<========================================
>
> Note - those comments are created by audit2allow.

Yes, those comments are annoying.

> Thanks in advance...
>
> Mark
>
>
>
>
>
> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux

-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux