Bug 455820

I've written entirely new policy for spamass-milter and am in the process of
trying to get it merged into upstream refpolicy. Please give it a try - see Bug
#452248

Thanks, I'll give it a try.  I'm just about to head off for a week, so unlikely
before then.

Looks like Paul's smpostfix.te works for me.

Was getting
type=AVC msg=audit(1224055574.663:2811): avc: denied { execute } for pid=4986 comm="spamass-milter" name="spamc" dev=dm-0 ino=5135861 scontext=unconfined_u:system_r:spamd_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file
with
spamass-milter-0.3.1-8.fc9.x86_64
selinux-policy-3.3.1-95.fc9
spamassassin-3.2.5-1.fc9.x86_64

I would have expected components shipped with FC9 to work with the default SELinux settings in FC9.
Actually, I would have expected working SELinux policy for each component to be included in the RPM for that component, rather than having a huge policy file for everything that might get installed, but I'm still trying to get familiar with this stuff

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

advax,

There are arguments for and against that.  Mainly if we allow the applications writers to write there own policy, they will do a lousy job of writing secure policy.  They would write extremely loose policy so their apps would just work.  


Fixed in selinux-policy-3.5.13-34.fc10

(In reply to comment #5)
> advax,
> 
> There are arguments for and against that.  Mainly if we allow the applications
> writers to write there own policy, they will do a lousy job of writing secure
> policy.  They would write extremely loose policy so their apps would just work. 

Maybe. But they know what their apps need better than I do as an end user.

I'm currently trying to migrate one system from FC4 (no SELinux) to FC9, and one from RH9 to RHEL5. I have, for now, abandoned the attempt to run SELinux in enforcing mode.
ClamAV milter, as shipped in FC9, errors on every mail message while creating a temporary file, while getting my Apache setup to run has been a stumbling block.
Principally because I have my web content on my home partition, not my system partition. But also because I've got a bunch of scriptaliased directories, 
system calls in CGI, symlinks and whatnot dating back to 1994. (Before I replaced my ReiserFS3 partition with a new ext3, I had 10,000 SEL errors/hour from procmail + dmail (UW imap util) trying repeatedly to deliver spam to my personal mail directory).
No doubt this is all fixable (maybe) if I took a lot of time to RTFM and tinker with configs. But the pragmatic approach is to turn it off globally.
(I did get named to run in SEL without too much work, after importing my existing configs. Yay!)

As a computer security officer, I would like to have SELinux running. Really. It's just hard, even with the wizard giving hints.

(In reply to comment #5)
> advax,
> 
> There are arguments for and against that.  Mainly if we allow the applications
> writers to write there own policy, they will do a lousy job of writing secure
> policy.  They would write extremely loose policy so their apps would just work. 
> 
> 
> Fixed in selinux-policy-3.5.13-34.fc10

What change has been made to fix this?

The milter policy now merged upstream addresses this issue and also Bug #446975 and Bug #452248. I guess that will make it into F11 but are F9 and F10 users going to be stuck with the old policy of the milter sharing the spamd domain?

I have the same issue, but with some additional information.

I run spamass-milter with -u spamd switch. It gives abilities to use user specific settings and if user doesn't exist or multiple addressees, then default (in my case spamd) user will be used.

I also have perl-Razor-Agent and pyzor installed. This is what being created in user's home:

# ls -AZ /home/spamd

drwxr-xr-x  spamd spamd system_u:object_r:spamc_home_t   .pyzor
drwxr-xr-x  spamd spamd system_u:object_r:user_home_t    .razor
drwx------  spamd spamd system_u:object_r:spamc_home_t   .spamassassin

It's not a secret that some e-mail, mostly spam, comes to root@
His home context is different:

# ls -AZ /root

drwxr-xr-x  root root system_u:object_r:admin_home_t   .pyzor
drwxr-xr-x  root root system_u:object_r:admin_home_t   .razor
drwx------  root root system_u:object_r:admin_home_t   .spamassassin

I have spamd_enable_home_dirs --> on

I get lots of AVC like these:

node=hut.chepkov.lan type=AVC msg=audit(1231970713.227:28875): avc:  denied  { read
} for  pid=6242 comm="pyzor" path="inotify" dev=inotifyfs ino=1
scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:inotifyfs_t:s0
tclass=dir

node=hut.chepkov.lan type=AVC msg=audit(1231971233.995:28920): avc:  denied  { ioctl
} for  pid=5435 comm="spamd" path="/root/.spamassassin/user_prefs" dev=dm-0 ino=4126
scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:admin_home_t:s0
tclass=file

drwxr-xr-x  spamd spamd system_u:object_r:user_home_t    .razor

This should be spamc_home_t also?

You could change the labels on the /root/.pyzor and friends to spamc_home_t also, if you want the filters to write to these directories.

But I think in enforcing mode, the spam filters will get a dontaudit for search /root and will not use the directory at all and not generate any AVC messages.

I just started to switch to SELinux as you must have noticed and I can see why so many people just ditch it, too many issues. But I am determined :)

Anyway, something is weird about razor policy. It seems like it does exist. I found this in the source rpm:

type razor_home_t;
userdom_user_home_content(user, razor_home_t)

and

HOME_DIR/\.razor(/.*)?          gen_context(system_u:object_r:razor_home_t,s0)

but, as you can see it's not getting applied and furthermore restorecon reverts the changes I do manually:

# restorecon -Rv /home/spamd/
restorecon reset /home/spamd/.razor context system_u:object_r:razor_home_t:s0->system_u:object_r:user_home_t:s0

As for root home
I am trying not to use chcon, I want to have all my changes permanent and surviving relabel
So I added proper context into my local policy

/root/\.razor(/.*)?     gen_context(system_u:object_r:razor_home_t,s0)
/root/\.pyzor(/.*)?     gen_context(system_u:object_r:pyzor_home_t,s0)
/root/\.spamassassin(/.*)?      gen_context(system_u:object_r:spamc_home_t,s0)

that doesn't work:

libsepol.context_from_record: invalid security context: "system_u:object_r:razor_home_t:s0"
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert system_u:object_r:razor_home_t:s0 to sid
invalid context system_u:object_r:razor_home_t:s0
libsemanage.semanage_install_active: setfiles returned error code 1.
semodule:  Failed!

so I changed it to
/root/\.razor(/.*)?     gen_context(system_u:object_r:spamc_home_t,s0)

And it seems to be working

In Fedora 10 and beyond we have combined all of the different spam handling tools into a single domain/type so file types like pyzor_home_t and razor_home_t are now aliased to spamc_home_t.

Spam has been a huge mess for SELinux since there are so many tools that handle it and the interaction between the tools is huge.

You can use 

# semanage fcontext -t spamc_home_t '/root/\.razor(/.*)?'

To permanently change the labeling.

Miroslav, there is a bug in razor.te,
Alias line should be
	typealias spamc_home_t alias razor_home_t;

(In reply to comment #7 by me)
> The milter policy now merged upstream addresses this issue and also Bug #446975
> and Bug #452248. I guess that will make it into F11 but are F9 and F10 users
> going to be stuck with the old policy of the milter sharing the spamd domain?

F-9 and F-10 should be getting an update to include the new milter policy soon - see Bug #483849. This should address the original problem raised in this ticket.


(In reply to comment #3 by advax)
> Looks like Paul's smpostfix.te works for me.

Can I infer from this that you're using spamass-milter with Postfix? If so, there's an updated spamass-milter package in the pipeline with better Postfix support - see Bug #452248; I'd be grateful if you could test it once it appears in the testing repo and let me know if it helps.

spamass-milter-0.3.1-13.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-13.fc10

spamass-milter-0.3.1-13.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-13.fc9

spamass-milter-0.3.1-13.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

spamass-milter-0.3.1-13.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

still having AVCs

type=AVC msg=audit(1240774442.029:463752): avc:  denied  { read } for  pid=7168 comm="pyzor" path="inotify" dev=inotifyfs ino=1 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:inotifyfs_t:s0 tclass=dir

I had to add the following to the local policy

fs_list_inotifyfs(spamc_t)

Is this being launched out of a cron job?

No, regular service call.

$ ps -efZ|grep spam
system_u:system_r:spamd_t       root      2112     1  0 Apr26 ?        00:00:18 /usr/bin/spamd -d -c -m8 -H -r /var/run/spamd.pid                    
system_u:system_r:initrc_t      sa-milt   2162     1  0 Apr26 ?        00:00:00 /bin/bash /usr/sbin/spamass-milter-wrapper -p /var/run/spamass-milter/spamass-milter.sock -P /var/run/spamass-milter.pid -m -r 15 -u spamd
system_u:system_r:spamass_milter_t sa-milt 2163 2162  0 Apr26 ?        00:00:00 /usr/sbin/spamass-milter -p /var/run/spamass-milter/spamass-milter.sock -P /var/run/spamass-milter.pid -m -r 15 -u spamd
system_u:system_r:spamd_t       root     24296  2112  0 07:00 ?        00:02:19 spamd child                                                          
system_u:system_r:spamd_t       root     30614  2112  0 09:55 ?        00:00:05 spamd child

Miroslav, Add it then.

Fixed in selinux-policy-3.5.13-59.fc10

This update (selinux-policy-3.5.13-59.fc10) is now in stable - have the AVCs gone?

Yes, thank you.

I still think the proper context need to be added to the apropriate modules, I imagine lots of people have to add similar to their local policy:

/root/\.pyzor(/.*)?            gen_context(system_u:object_r:spamc_home_t,s0)
/root/\.spamassassin(/.*)?     gen_context(system_u:object_r:spamc_home_t,s0)


razor.fc in the targeted policy has the proper context set, for example:

/root/\.razor(/.*)?            gen_context(system_u:object_r:spamc_home_t,s0)

I guess those should be added also.

Fixed in selinux-policy-3.5.13-61.fc10