[refpolicy] services_amavis.patch

[refpolicy] services_amavis.patch

[Daniel J Walsh]

http://people.fedoraproject.org/~dwalsh/SELinux/F12/services_amavis.patch

amavis getattr on mounted file systems.

[refpolicy] services_amavis.patch

[Christopher J. PeBenito]

On Thu, 2009-11-12 at 16:11 -0500, Daniel J Walsh wrote:
> http://people.fedoraproject.org/~dwalsh/SELinux/F12/services_amavis.patch
> 
> amavis getattr on mounted file systems.

Merged.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] services_amavis.patch

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://people.fedoraproject.org/~dwalsh/SELinux/F14/services_amavis.patch

Amavis creates var/run dirs and stores spool data in /amavis_spool_t dirs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkx20scACgkQrlYvE4MpobN5FACgsGHt0jrVyZvLbJiBMNjWrvg2
MSwAoKm4yrNilTPmMRmQgN+MqhDAiRMx
=EM6j
-----END PGP SIGNATURE-----

[refpolicy] services_amavis.patch

[Christopher J. PeBenito]

On 08/26/10 16:47, Daniel J Walsh wrote:
> http://people.fedoraproject.org/~dwalsh/SELinux/F14/services_amavis.patch
>
> Amavis creates var/run dirs and stores spool data in /amavis_spool_t dirs.

Merged.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] services_amavis.patch

[Daniel J Walsh]

http://people.fedoraproject.org/~dwalsh/SELinux/F13/services_amavis.patch

amavis reads certs and utmp

[refpolicy] services_amavis.patch

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://people.fedoraproject.org/~dwalsh/SELinux/F10/services_amavis.patch

Add initrc script support

allow admin to start/stop service

Admin needs admin_pattern on all file types



Fix path to /etc/amavisd

amavis can exec itself.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEUEARECAAYFAkjaqHYACgkQrlYvE4MpobNfPwCeIu7/8IJuYJ8l1vI26c3WoNSx
9UQAl2KSvE/SYL2+Rp9ldwfWOSDdhDk=
=7PKR
-----END PGP SIGNATURE-----

[refpolicy] services_amavis.patch

[Russell Coker]

On Thursday 25 September 2008 06:52, Daniel J Walsh <dwalsh@redhat.com> wrote:
> http://people.fedoraproject.org/~dwalsh/SELinux/F10/services_amavis.patch
>
> Add initrc script support

How much success are people having with the policy that has Amavis and ClamAV 
in different domains?

The CentOS servers that I run have Amavis and ClamAV running unconfined 
because getting the policy to work was too difficult (the two daemons 
interact with each other a lot, trying to keep them separate is a lost 
cause).

I've attached the policy that I have written for Debian/Lenny.  It runs 
Amavis, ClamAV, and clamav-milter in the same domain.  I don't think that 
makes any significant reduction to security but it significantly reduces the 
difficulty in configuring it.

This is the change that I had been suggesting for a few years.

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clamav.tgz
Type: application/x-tgz
Size: 2332 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20080925/a67ea51b/attachment.bin 

[refpolicy] services_amavis.patch

[Martin Orr]

On 25/09/08 08:19, Russell Coker wrote:
> On Thursday 25 September 2008 06:52, Daniel J Walsh <dwalsh@redhat.com> wrote:
>> http://people.fedoraproject.org/~dwalsh/SELinux/F10/services_amavis.patch
>>
>> Add initrc script support
> 
> How much success are people having with the policy that has Amavis and ClamAV 
> in different domains?

Well I run amavis and clamav in separate domains (with Courier as MTA, so
that may be different from using exim/postfix), and the only extra rule I
need for clamav is:
read_files_pattern(clamd_t, courier_spool_t, courier_spool_t)
(I have a bunch more rules for amavisd to talk to Courier, but then my
Courier policy is entirely home-grown.)

> The CentOS servers that I run have Amavis and ClamAV running unconfined 
> because getting the policy to work was too difficult (the two daemons 
> interact with each other a lot, trying to keep them separate is a lost 
> cause).

How do they interact with each other beyond communicating by a socket and
clamd reading amavis spool files?

And people might want to use clamav to scan things other than mail, or to
use a commercial AV scanner with amavis (of course in the latter case, they
would have to write policy for the AV scanner themselves).

Best wishes,

-- 
Martin Orr

[refpolicy] services_amavis.patch

[Russell Coker]

On Thursday 25 September 2008 22:19, Martin Orr <martin@martinorr.name> wrote:
> > The CentOS servers that I run have Amavis and ClamAV running unconfined
> > because getting the policy to work was too difficult (the two daemons
> > interact with each other a lot, trying to keep them separate is a lost
> > cause).
>
> How do they interact with each other beyond communicating by a socket and
> clamd reading amavis spool files?

They can communicate by a socket or by running a program.

> And people might want to use clamav to scan things other than mail, or to
> use a commercial AV scanner with amavis (of course in the latter case, they
> would have to write policy for the AV scanner themselves).

Even with the low quality we expect from closed-source software, I don't think 
it's a significant benefit to run it in a different domain.

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

[refpolicy] services_amavis.patch

[Martin Orr]

On 27/09/08 01:42, Russell Coker wrote:
> On Thursday 25 September 2008 22:19, Martin Orr <martin@martinorr.name> wrote:
>>> The CentOS servers that I run have Amavis and ClamAV running unconfined
>>> because getting the policy to work was too difficult (the two daemons
>>> interact with each other a lot, trying to keep them separate is a lost
>>> cause).
>> How do they interact with each other beyond communicating by a socket and
>> clamd reading amavis spool files?
> 
> They can communicate by a socket or by running a program.

Doesn't seem like interacting a lot to me.

But I've thought a bit more about why I dislike merging the amavis and
clamav domains, and my primary concern is that it is confusing to have
amavisd running as clamav_t.  If I saw a denial with
comm="amavisd" scontext=system_u:system_r:clamav_t:s0
then I would assume that there was a missing transition somewhere.

For similar reasons I dislike the fact that wpa_supplicant runs as
NetworkManager_t, and the MTA policy is full of confusingly named types and
attributes, but that's no reason to introduce another one.

So while I still don't see the value of merging amavis_t and clamav_t when
separate policy has already been written, I would be a lot happier if the
merged domain were not called clamav_t.

Best wishes,

-- 
Martin Orr

[refpolicy] services_amavis.patch

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Orr wrote:
> On 27/09/08 01:42, Russell Coker wrote:
>> On Thursday 25 September 2008 22:19, Martin Orr <martin@martinorr.name> wrote:
>>>> The CentOS servers that I run have Amavis and ClamAV running unconfined
>>>> because getting the policy to work was too difficult (the two daemons
>>>> interact with each other a lot, trying to keep them separate is a lost
>>>> cause).
>>> How do they interact with each other beyond communicating by a socket and
>>> clamd reading amavis spool files?
>> They can communicate by a socket or by running a program.
> 
> Doesn't seem like interacting a lot to me.
> 
> But I've thought a bit more about why I dislike merging the amavis and
> clamav domains, and my primary concern is that it is confusing to have
> amavisd running as clamav_t.  If I saw a denial with
> comm="amavisd" scontext=system_u:system_r:clamav_t:s0
> then I would assume that there was a missing transition somewhere.
> 
> For similar reasons I dislike the fact that wpa_supplicant runs as
> NetworkManager_t, and the MTA policy is full of confusingly named types and
> attributes, but that's no reason to introduce another one.
> 
> So while I still don't see the value of merging amavis_t and clamav_t when
> separate policy has already been written, I would be a lot happier if the
> merged domain were not called clamav_t.
> 
> Best wishes,
> 
mailscanner_t  perhaps?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjjbbcACgkQrlYvE4MpobPvkgCfX+KEfAuZXhgzD9aRozZgyuWR
9hkAn0rSeI+6xIzyIbNN58EvkXifDZel
=mIhq
-----END PGP SIGNATURE-----

[refpolicy] services_amavis.patch

[Russell Coker]

On Wednesday 01 October 2008 21:17, Martin Orr <martin@martinorr.name> wrote:
> > They can communicate by a socket or by running a program.
>
> Doesn't seem like interacting a lot to me.

There's also the issue of Unix domain sockets and inter-relations between 
paths.

> But I've thought a bit more about why I dislike merging the amavis and
> clamav domains, and my primary concern is that it is confusing to have
> amavisd running as clamav_t.  If I saw a denial with
> comm="amavisd" scontext=system_u:system_r:clamav_t:s0
> then I would assume that there was a missing transition somewhere.
>
> So while I still don't see the value of merging amavis_t and clamav_t when
> separate policy has already been written, I would be a lot happier if the
> merged domain were not called clamav_t.

I'm happy to rename it (but not for Lenny).  What do you suggest?

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

[refpolicy] services_amavis.patch

[Christopher J. PeBenito]

On Wed, 2008-10-01 at 12:17 +0100, Martin Orr wrote:
> On 27/09/08 01:42, Russell Coker wrote:
> > On Thursday 25 September 2008 22:19, Martin Orr <martin@martinorr.name> wrote:
> >>> The CentOS servers that I run have Amavis and ClamAV running unconfined
> >>> because getting the policy to work was too difficult (the two daemons
> >>> interact with each other a lot, trying to keep them separate is a lost
> >>> cause).
> >> How do they interact with each other beyond communicating by a socket and
> >> clamd reading amavis spool files?
> > 
> > They can communicate by a socket or by running a program.
> 
> Doesn't seem like interacting a lot to me.
> 
> But I've thought a bit more about why I dislike merging the amavis and
> clamav domains, and my primary concern is that it is confusing to have
> amavisd running as clamav_t.  If I saw a denial with
> comm="amavisd" scontext=system_u:system_r:clamav_t:s0
> then I would assume that there was a missing transition somewhere.

I'd tend to agree with this.

> For similar reasons I dislike the fact that wpa_supplicant runs as
> NetworkManager_t, and the MTA policy is full of confusingly named types and
> attributes, but that's no reason to introduce another one.

Getting the right granularity for the upstream policy is an ongoing
struggle.  I've heard others complain about this particular one too.

> So while I still don't see the value of merging amavis_t and clamav_t when
> separate policy has already been written, I would be a lot happier if the
> merged domain were not called clamav_t.

I'm not so convinced about a merged policy, but I'm open to new ideas.
I'd have to see patches.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] services_amavis.patch

[Christopher J. PeBenito]

On Sat, 2008-09-27 at 10:42 +1000, Russell Coker wrote:
> On Thursday 25 September 2008 22:19, Martin Orr <martin@martinorr.name> wrote:
> > > The CentOS servers that I run have Amavis and ClamAV running unconfined
> > > because getting the policy to work was too difficult (the two daemons
> > > interact with each other a lot, trying to keep them separate is a lost
> > > cause).
> >
> > How do they interact with each other beyond communicating by a socket and
> > clamd reading amavis spool files?
> 
> They can communicate by a socket or by running a program.

Can you clarify what you mean by "running a program"?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] services_amavis.patch

[Russell Coker]

On Thursday 02 October 2008 22:31, "Christopher J. PeBenito" 
<cpebenito@tresys.com> wrote:
> On Sat, 2008-09-27 at 10:42 +1000, Russell Coker wrote:
> > On Thursday 25 September 2008 22:19, Martin Orr <martin@martinorr.name> 
wrote:
> > > > The CentOS servers that I run have Amavis and ClamAV running
> > > > unconfined because getting the policy to work was too difficult (the
> > > > two daemons interact with each other a lot, trying to keep them
> > > > separate is a lost cause).
> > >
> > > How do they interact with each other beyond communicating by a socket
> > > and clamd reading amavis spool files?
> >
> > They can communicate by a socket or by running a program.
>
> Can you clarify what you mean by "running a program"?

Amavis can run a clam program.  ClamAV can be a daemon or a utility program.  
Amavis can even be configured to try both methods.

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

[refpolicy] services_amavis.patch

[Daniel J Walsh]

Russell Coker wrote:
> On Thursday 25 September 2008 06:52, Daniel J Walsh <dwalsh@redhat.com> wrote:
>> http://people.fedoraproject.org/~dwalsh/SELinux/F10/services_amavis.patch
>>
>> Add initrc script support
> 
> How much success are people having with the policy that has Amavis and ClamAV 
> in different domains?
> 
> The CentOS servers that I run have Amavis and ClamAV running unconfined 
> because getting the policy to work was too difficult (the two daemons 
> interact with each other a lot, trying to keep them separate is a lost 
> cause).
> 
> I've attached the policy that I have written for Debian/Lenny.  It runs 
> Amavis, ClamAV, and clamav-milter in the same domain.  I don't think that 
> makes any significant reduction to security but it significantly reduces the 
> difficulty in configuring it.
> 
> This is the change that I had been suggesting for a few years.
> 
I tend to think this is is a good idea to look at some domains and start
to combine them to simplify policy.   The pendulum has swung to far
towards least privs and needs to start coming back the other way.  Email
handling/spam filtering/virus checking is the worst example of this.

[refpolicy] services_amavis.patch

[Russell Coker]

On Friday 26 September 2008 06:10, Daniel J Walsh <dwalsh@redhat.com> wrote:
> I tend to think this is is a good idea to look at some domains and start
> to combine them to simplify policy. ? The pendulum has swung to far
> towards least privs and needs to start coming back the other way. ?Email
> handling/spam filtering/virus checking is the worst example of this.

I don't agree with the blanket statement that the pendulum has swung too far 
towards least privs.

However I think that there are some specific examples which seemed to involve 
too many domains at the time they were created and which never demonstrated a 
need for them.

One example is the Postfix and Qmail policy which I wrote knowing that there 
were not security benefits in using so many domains.  My plan for many years 
has been to review both of them and determine which domains could be merged.  
When I had time to work on this there were no tools to allow such analysis.  
I'll have to get back to this.

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

[refpolicy] services_amavis.patch

[Christopher J. PeBenito]

On Fri, 2008-09-26 at 07:03 +1000, Russell Coker wrote:
> On Friday 26 September 2008 06:10, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > I tend to think this is is a good idea to look at some domains and start
> > to combine them to simplify policy.   The pendulum has swung to far
> > towards least privs and needs to start coming back the other way.  Email
> > handling/spam filtering/virus checking is the worst example of this.
> 
> I don't agree with the blanket statement that the pendulum has swung too far 
> towards least privs.
> 
> However I think that there are some specific examples which seemed to involve 
> too many domains at the time they were created and which never demonstrated a 
> need for them.
> 
> One example is the Postfix and Qmail policy which I wrote knowing that there 
> were not security benefits in using so many domains.  My plan for many years 
> has been to review both of them and determine which domains could be merged.  
> When I had time to work on this there were no tools to allow such analysis.  
> I'll have to get back to this.

One thing specific example that I noticed recently about these was that
there is a mail_spool_t in mta, and postfix and qmail also have their
own spool types.  Those sounded like they could possibly all merge into
mail_spool_t, but I haven't had a chance to investigate further.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] services_amavis.patch

[Russell Coker]

On Tuesday 07 October 2008 05:20, "Christopher J. PeBenito" 
<cpebenito@tresys.com> wrote:
> One thing specific example that I noticed recently about these was that
> there is a mail_spool_t in mta, and postfix and qmail also have their
> own spool types. ?Those sounded like they could possibly all merge into
> mail_spool_t, but I haven't had a chance to investigate further.

The mail_spool_t in mta.te is for /var/spool/mail - this is fully accessible 
to users.

The spool directories for the mail servers have limited access for users.

So there is some possibility for type sharing, but /var/spool/mail should not 
share a type with /var/spool/postfix.

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

[refpolicy] services_amavis.patch

[Christopher J. PeBenito]

On Wed, 2008-09-24 at 16:52 -0400, Daniel J Walsh wrote:
> http://people.fedoraproject.org/~dwalsh/SELinux/F10/services_amavis.patch
> 
> Add initrc script support
> 
> allow admin to start/stop service
> 
> Admin needs admin_pattern on all file types
> 
> 
> 
> Fix path to /etc/amavisd
> 
> amavis can exec itself.

Merged.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150