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): selinux-policy-targeted-1.21.8-2 How reproducible: Always Steps to Reproduce: 1.echo Subject: test | spamc Actual Results: Subject: test X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on livre.redhat.lsd.ic.unicamp.br X-Spam-Level: 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:
Created attachment 110664 [details] these are the messages logged in /var/log/auditd
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.
/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.
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. Dan
Colin I wanted to bring you into this discussion, since you wrote the original policy for spam.
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.
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 [127.0.0.1] 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 [/home/aoliva/.spamassassin/user_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> 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 - scantime=1.3,size=2236,mid=<20050219181551.25766.qmail>,autolearn=failed These strace logs are also particularly scary: stat("/home/aoliva/.spamassassin", 0x505140) = -1 EACCES (Permission denied) stat("/home/aoliva/.spamassassin", 0x505140) = -1 EACCES (Permission denied) 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 open("/home/aoliva/.spamassassin/auto-whitelist.lock.livre.redhat.lsd.ic.unicamp.br.30517", 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 denied) stat("/home/aoliva/.spamassassin", 0x505140) = -1 EACCES (Permission denied) 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 /l/aoliva/mail 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 /l/aoliva/main 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 /l/home/aoliva 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.
allow spamd_t user_home_dir_t:dir { search getattr }; This is correct; it's included in the normal Spamassassin macros for users. 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.
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. Dan
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.
Removed for now from targeted policy. selinux-policy-targeted-1.21.15-5