-----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-----
On Thursday 25 September 2008 06:52, Daniel J Walsh <[email protected]> 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
On 25/09/08 08:19, Russell Coker wrote:
> On Thursday 25 September 2008 06:52, Daniel J Walsh <[email protected]> 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
Russell Coker wrote:
> On Thursday 25 September 2008 06:52, Daniel J Walsh <[email protected]> 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.
On Friday 26 September 2008 06:10, Daniel J Walsh <[email protected]> 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
On Thursday 25 September 2008 22:19, Martin Orr <[email protected]> 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
On 27/09/08 01:42, Russell Coker wrote:
> On Thursday 25 September 2008 22:19, Martin Orr <[email protected]> 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
-----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 <[email protected]> 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-----
On Wednesday 01 October 2008 21:17, Martin Orr <[email protected]> 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
On Sat, 2008-09-27 at 10:42 +1000, Russell Coker wrote:
> On Thursday 25 September 2008 22:19, Martin Orr <[email protected]> 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
On Thursday 02 October 2008 22:31, "Christopher J. PeBenito"
<[email protected]> wrote:
> On Sat, 2008-09-27 at 10:42 +1000, Russell Coker wrote:
> > On Thursday 25 September 2008 22:19, Martin Orr <[email protected]>
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
On Fri, 2008-09-26 at 07:03 +1000, Russell Coker wrote:
> On Friday 26 September 2008 06:10, Daniel J Walsh <[email protected]> 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
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 <[email protected]> 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
On Tuesday 07 October 2008 05:20, "Christopher J. PeBenito"
<[email protected]> 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
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