Bug 147169 - spamd can't autolearn (bayes and autowhitelist)
spamd can't autolearn (bayes and autowhitelist)
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2005-02-04 11:59 EST by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-11 13:01:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
these are the messages logged in /var/log/auditd (11.43 KB, text/plain)
2005-02-04 12:06 EST, Alexandre Oliva
no flags Details

  None (edit)
Description Alexandre Oliva 2005-02-04 11:59:58 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
Starting spamassassin with spamc out of .procmailrc, it will
apparently correctly detect spam from ham and add headers to the
delivered mail, but I'm not sure it is actually able to use info from
the bayes database, and I know auto-learning is broken because the
added header says autolearn=failed.  The audit log confirms a number
of lnk_file and lnk_filee operations are denied.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.echo Subject: test | spamc

Actual Results:  Subject: test
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on
X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,MISSING_DATE,
        MISSING_SUBJECT autolearn=failed version=3.0.2

Expected Results:  autolearn=ham or =spam was expected.  It doesn't
seem to have succeeded in using the bayes database either.

Additional info:
Comment 1 Alexandre Oliva 2005-02-04 12:06:40 EST
Created attachment 110664 [details]
these are the messages logged in /var/log/auditd
Comment 2 Daniel Walsh 2005-02-04 13:31:59 EST
allow spamd_t default_t:lnk_file read;

This is because your /home directory is a symbolic link and it is not
allowed to follow it.

Comment 3 Alexandre Oliva 2005-02-04 15:21:01 EST
/home is a symbolic link, .spamassassin is another symbolic link to a
pathname that has yet another symbolic link.  Does everybody have to
rearrange their filesystem layouts to accomodate even a targeted
policy?  I didn't think so.

Or is the line above going into the main policy?

Couldn't we arrange for every context to be able to follow symlinks. 
I fail to see the point of preventing this action, if the context
would grant direct access to the linked-to location if accessed directly.
Comment 4 Daniel Walsh 2005-02-09 10:15:36 EST
The problem with following symlinks is the user is allowed to set
certain context that could fool SELinux, so if you could some how
convince an application to follow a symlink you could thwart SELinux
protection.  I am not that familiar with spamassasin and how it is
working.  Is the daemon writing to users home directories or is the
user running spamassassin direcectly?  This could be spamassasin
transitioning when it should not be.

Comment 5 Daniel Walsh 2005-02-09 10:26:00 EST
Colin I wanted to bring you into this discussion, since you wrote the
original policy for spam. 
Comment 6 Colin Walters 2005-02-09 11:35:37 EST
The first problem here is that the file is labeled default_t.  No
non-unconfined program in policy can access this. 

My suggestion is to label the /home symlink as usr_t (e.g. chcon -h -t
usr_t /home/aoliva).  Many programs can access symlinks of this type.

Now, the second major problem with the current Spamassassin policy is
that (according to apol at least) no home directory access is allowed.
 The apache.te has a hack for this (ifdef(targeted)) that duplicates a
bit of code from apache_macros.te.  I guess we need to replicate that
in the spamassassin policy.

I think I remember from unrelated discussions that your /home is a
symlink to a USB key or the like?  This brings up a larger issue of
"/home on USB key" which would be nice to support.  It's quite tricky
however (see for example bug #119498), because it raises issues of
whether the filesystem on the USB device permits labeling or not, and
how to identify whether or not you actually want to trust the labels
on a USB key.
Comment 7 Alexandre Oliva 2005-02-19 13:51:03 EST
Ok, I found out that /l (the root dir of the filesystem mounted from
external firewire/USB LVM-on-raid storage) was unlabeled.  Since /home
was a link to l/home, I suppose that's why I had some oddities. 
Still, I needed the following line added to the end of spamd.te:

allow spamd_t home_root_t:dir { search getattr };

One of search or getattr was actually already there, but I needed both
for auto-learn from spamc/spamd to stop logging audit messages. 
Still, it didn't work.  /var/log/maillog still gets messages such as:

Feb 19 16:17:56 livre spamd[30517]: connection from
livre.redhat.lsd.ic.unicamp.br [] at port 40325
Feb 19 16:17:56 livre spamd[30517]: info: setuid to aoliva succeeded
Feb 19 16:17:56 livre spamd[30517]: Creating default_prefs
Feb 19 16:17:56 livre spamd[30517]: Cannot write to
/home/aoliva/.spamassassin/user_prefs: Permission denied
Feb 19 16:17:56 livre spamd[30517]: Couldn't create readable
default_prefs for [/home/aoliva/.spamassassin/user_prefs]
Feb 19 16:17:56 livre spamd[30517]: processing message
<20050219181551.25766.qmail@sourceware.org> for aoliva:404.
Feb 19 16:17:57 livre spamd[30517]: clean message (0.0/5.0) for
aoliva:404 in 1.3 seconds, 2236 bytes.
Feb 19 16:17:57 livre spamd[30517]: result: .  0 - 

These strace logs are also particularly scary:

stat("/home/aoliva/.spamassassin", 0x505140) = -1 EACCES (Permission
stat("/home/aoliva/.spamassassin", 0x505140) = -1 EACCES (Permission
stat("/home/aoliva", 0x505140)          = -1 EACCES (Permission denied)
stat("/home/aoliva", 0x505140)          = -1 EACCES (Permission denied)
stat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
mkdir("/home/aoliva", 0700)             = -1 EEXIST (File exists)
stat("/home/aoliva", 0x505140)          = -1 EACCES (Permission denied)
umask(077)                              = 0
O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)
umask(0)                                = 077
select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout)
stat("/home/aoliva/.spamassassin/bayes_toks", 0x505140) = -1 EACCES
(Permission denied)
stat("/home/aoliva/.spamassassin/bayes_toks.db", 0x505140) = -1 EACCES
(Permission denied)
stat("/home/aoliva/.spamassassin", 0x505140) = -1 EACCES (Permission
stat("/home/aoliva/.spamassassin", 0x505140) = -1 EACCES (Permission
stat("/home/aoliva", 0x505140)          = -1 EACCES (Permission denied)
stat("/home/aoliva", 0x505140)          = -1 EACCES (Permission denied)
stat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

Here's all the relevant context info:

drwxr-xr-x  root     root     system_u:object_r:root_t         /
lrwxrwxrwx  root     root     system_u:object_r:usr_t          /home
-> l/home
lrwxrwxrwx  aoliva   aoliva   system_u:object_r:user_home_t   
/home/aoliva/... -> /l/aoliva
drwxr-xr-x  root     root     system_u:object_r:usr_t          /l
drwxr-xr-x  aoliva   aoliva   system_u:object_r:user_home_t    /l/aoliva
drwxr-xr-x  aoliva   aoliva   system_u:object_r:user_home_t   
lrwxrwxrwx  aoliva   aoliva   system_u:object_r:user_home_t   
/l/aoliva/mail/.spamassassin -> Mail/.nobackup/.spamassassin
drwxr-xr-x  aoliva   aoliva   system_u:object_r:user_home_t   
lrwxrwxrwx  aoliva   aoliva   system_u:object_r:user_home_t   
/l/aoliva/main/.spamassassin -> ../mail/.spamassassin
drwxr-xr-x  root     root     system_u:object_r:home_root_t    /l/home
drwx--x--x  aoliva   aoliva   system_u:object_r:user_home_dir_t
lrwxrwxrwx  aoliva   aoliva   system_u:object_r:user_home_t   
/l/home/aoliva/.spamassassin -> .../mail/.spamassassin

I'm not sure why I'd be missing audits for the failed stat()s, but the
following additions fix it:

allow spamd_t user_home_dir_t:dir { search getattr };
rw_dir_create_file(spamd_t, user_home_t)

Now spamassassin can both use the bayes database and autolearn.

As for Dan's question on how spamassassin works, there are several
ways to run it: from the command line, from procmail directly or
through spamc.  The way I use it is through spamc.  spamc contants a
local spamd daemon, that runs as spamd_t.  This daemon caches rules
defined for each user, speeding up the start-up time of spamassassin,
that's quite long.  It becomes the user in order to access the user's
databases and configurations.
Comment 8 Colin Walters 2005-02-19 14:52:06 EST
allow spamd_t user_home_dir_t:dir { search getattr };

This is correct; it's included in the normal Spamassassin macros for

rw_dir_create_file(spamd_t, user_home_t)

This is a very bad idea.  You have given a compromised, misconfigured,
or buggy Spamassassin complete access to your home directory.  The
existing spamassassin_macros.te defines a type for ~/.spamassassin:

type $1_home_spamassassin_t, file_type, $1_file_type, sysadmfile;

We need to ensure that
1) This macro is invoked so that we have the type defined
2) User's home directories are automatically labeled with this type

I just noticed an existing bug in the policy actually, it grants
r_dir_file($1_$2_t, $1_home_t) in spamassassin_program_domain.  That
should be dropped.
Comment 9 Daniel Walsh 2005-02-20 11:55:29 EST
So this looks like spam should not be running under a special context
for targeted policy.  Does the spamd listen for incoming connections?
 Or is it just a user daemon.  I don't want targeted policy to have to 
worry about file contexts of the users home directory (Other than
apache).  Once we start having to worry about homedir file context we
are on the slipper slope to strict policy.

Comment 10 Colin Walters 2005-02-22 11:59:31 EST
Spamassassin is pretty complex.  It can act as a network TCP
spam-filtering server.  Users can invoke it via "spamc in e.g.
~/.procmailrc to talk to the server, which could be on localhost or
elsewhere.  Or they can just run a new "spamassassin" process each time. 

I don't know whether or not it should be in targeted.  Certainly a
policy seems a lot less valuable if user's home directories are not
protected.  But I guess since the server runs as root (typically) it
would still be useful.

Comment 11 Daniel Walsh 2005-03-08 14:25:25 EST
Removed for now from targeted policy.


Note You need to log in before you can comment on or make changes to this bug.