Bug 864501 - selinux policy prevents sa-update from reading /root/.spamassassin
selinux policy prevents sa-update from reading /root/.spamassassin
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
: Reopened
: 880421 (view as bug list)
Depends On:
Blocks: 910935
  Show dependency treegraph
Reported: 2012-10-09 09:17 EDT by Michael Cronenworth
Modified: 2013-02-13 17:32 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 910935 (view as bug list)
Last Closed: 2013-02-12 00:07:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Cronenworth 2012-10-09 09:17:31 EDT
Description of problem:
Cron emails me this report:
config: path "/root/.spamassassin" is inaccessible: Permission denied
config: path "/root/.spamassassin" is inaccessible: Permission denied
config: path "/root/.spamassassin" is inaccessible: Permission denied
09-Oct-2012 04:20:50: SpamAssassin: Update processed successfully

# grep 04:20:50 /var/log/messages
Oct  9 04:20:50 balthasar setroubleshoot: SELinux is preventing /usr/bin/perl from using the dac_read_search capability. For complete SELinux messages. run sealert -l b4d39549-64ca-4654-aff1-c3e8d454f1b3

# sealert -l b4d39549-64ca-4654-aff1-c3e8d454f1b3
SELinux is preventing /usr/bin/perl from using the dac_read_search capability.

*****  Plugin dac_override (91.4 confidence) suggests  ***********************

If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system
Then turn on full auditing to get path information about the offending file and generate the error again.

Turn on full auditing
# auditctl -w /etc/shadow -p w
Try to recreate AVC. Then execute
# ausearch -m avc -ts recent
If you see PATH record check ownership/permissions on file, and fix it, 
otherwise report as a bugzilla.

*****  Plugin catchall (9.59 confidence) suggests  ***************************

If you believe that perl should have the dac_read_search capability by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
allow this access for now by executing:
# grep sa-update /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:spamd_update_t:s0-s0:c0.c1023
Target Context                system_u:system_r:spamd_update_t:s0-s0:c0.c1023
Target Objects                 [ capability ]
Source                        sa-update
Source Path                   /usr/bin/perl
Port                          <Unknown>
Host                          balthasar.cchtml.com
Source RPM Packages           perl-5.14.2-215.fc17.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-153.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     balthasar.cchtml.com
Platform                      Linux balthasar.cchtml.com 3.5.6-1.fc17.x86_64 #1
                              SMP Sun Oct 7 19:31:14 UTC 2012 x86_64 x86_64
Alert Count                   9
First Seen                    2012-10-09 04:10:02 CDT
Last Seen                     2012-10-09 04:20:49 CDT
Local ID                      b4d39549-64ca-4654-aff1-c3e8d454f1b3

Raw Audit Messages
type=AVC msg=audit(1349774449.976:791): avc:  denied  { dac_read_search } for  pid=7416 comm="sa-update" capability=2  scontext=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 tcontext=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 tclass=capability

type=SYSCALL msg=audit(1349774449.976:791): arch=x86_64 syscall=open success=no exit=EACCES a0=7f707aedd6eb a1=80000 a2=1b6 a3=238 items=0 ppid=7160 pid=7416 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=95 comm=sa-update exe=/usr/bin/perl subj=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 key=(null)

Hash: sa-update,spamd_update_t,spamd_update_t,capability,dac_read_search


#============= spamd_update_t ==============
allow spamd_update_t self:capability dac_read_search;

audit2allow -R

#============= spamd_update_t ==============
allow spamd_update_t self:capability dac_read_search;

Version-Release number of selected component (if applicable):
Comment 1 Michael Cronenworth 2012-10-09 09:19:05 EDT
It is an empty directory with the correct context applied.

# restorecon -Rv /root
# ls -Zd .spamassassin/
drwx------. root root system_u:object_r:spamc_home_t:s0 .spamassassin/
# ls -la .spamassassin/
total 8
drwx------.  2 root root 4096 Oct 13  2011 .
dr-xr-x---. 10 root root 4096 Sep 23 12:53 ..
Comment 2 Daniel Walsh 2012-10-09 12:10:33 EDT
ls -lad /root
Comment 3 Michael Cronenworth 2012-10-09 12:14:16 EDT
$ ls -Zlad /root
dr-xr-x---. 10 system_u:object_r:admin_home_t:s0 root root 4096 Sep 23 12:53 /root
Comment 4 Daniel Walsh 2012-10-09 12:18:47 EDT
chmod 750 /root
Comment 5 Michael Cronenworth 2012-10-09 12:24:15 EDT
Daniel, what are you suggesting? I logged into a few Fedora 17 and RHEL6 boxes and they have /root set to 550. AFAIK this is the correct default setting.
Comment 6 Daniel Walsh 2012-10-09 12:40:42 EDT
I guess this is the correct permission that the /root directory is supposed to have.

Eric, why would I get a dac_read_search?
Comment 7 Steve Grubb 2012-10-09 12:46:32 EDT
If its trying to read ~/.spamassassin it should be able to. My guess its its trying to create the file...which it probably does not need to do.
Comment 8 Daniel Walsh 2012-10-09 12:49:23 EDT
I would figure that would be dac_override though?

/* Override all DAC access, including ACL execute access if
   [_POSIX_ACL] is defined. Excluding DAC access covered by

#define CAP_DAC_OVERRIDE     1

/* Overrides all DAC restrictions regarding read and search on files
   and directories, including ACL restrictions if [_POSIX_ACL] is
   defined. Excluding DAC access covered by CAP_LINUX_IMMUTABLE. */

Comment 9 Steve Grubb 2012-10-09 13:41:26 EDT
The translated flags to open are: a1=O_RDONLY|O_CLOEXEC. If the dir is 0550 and the uid is 0 and the gid is 0...read access should be allowed without any capabilities.
Comment 10 Michael Cronenworth 2012-10-23 09:11:22 EDT
Any update on this? (CC'ing SA maintainers)
Comment 11 John Griffiths 2013-01-16 11:23:41 EST
This is still happening. Any progress?
Comment 12 Daniel Walsh 2013-01-16 15:53:22 EST
We allow this in F18, Miroslav can you back port to F17.
Comment 13 Daniel Walsh 2013-01-16 15:54:50 EST
*** Bug 880421 has been marked as a duplicate of this bug. ***
Comment 14 Miroslav Grepl 2013-01-17 07:25:31 EST
This is already fixed.

sesearch -A -s spamd_update_t -t spamd_update_t  -c capability
Found 2 semantic av rules:
   allow spamd_update_t spamd_update_t : capability dac_read_search ;
Comment 15 John Griffiths 2013-01-17 09:23:01 EST
I beg to differ. I got this in an email from my Fedora 17 systems this morning.

config: path "/root/.spamassassin" is inaccessible: Permission denied
config: path "/root/.spamassassin" is inaccessible: Permission denied
config: path "/root/.spamassassin" is inaccessible: Permission denied

Yet, when I run:

sesearch -A -s spamd_update_t -t spamd_update_t  -c capability

I get:

Found 2 semantic av rules:
   allow spamd_update_t spamd_update_t : capability dac_read_search ; 
   allow spamd_update_t spamd_update_t : capability net_bind_service ; 

This is not fixed and this bug needs to be reopened. If you don't want to do that, I will clone it.
Comment 16 Michael Cronenworth 2013-01-17 09:24:20 EST
Yes, I see the added policy on my F17 box, but I am still getting Cron e-mails about read failures every morning. This is an e-mail from this morning:

config: path "/root/.spamassassin" is inaccessible: Permission denied
config: path "/root/.spamassassin" is inaccessible: Permission denied
config: path "/root/.spamassassin" is inaccessible: Permission denied
17-Jan-2013 04:54:53: SpamAssassin: Update processed successfully
Comment 17 Scott Shambarger 2013-01-20 21:08:24 EST
I finally chased this down today... the denials are caused by two "dontaudit" denials:

type=AVC msg=audit(1358727584.642:16181): avc:  denied  { search } for  pid=24396 comm="sa-update" name="root" dev="dm-0" ino=3932161 scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir

type=AVC msg=audit(1358729533.648:16336): avc:  denied  { getattr } for  pid=24841 comm="sa-update" path="/root/.spamassassin" dev="dm-0" ino=3932264 scontext=system_u:system_r:spamd_update_t:s0 tcontext=unconfined_u:object_r:spamc_home_t:s0 tclass=dir

(this assumes /root/.spamassassin exists, only the first is triggered if it doesn't)

The code that causes this is in /usr/bin/sa-update calling the function lint_check_dir() when the downloaded spam rules are checked for correctness.  A instance of Mail::SpamAssassin is created, and lint_rules() is called on it, which calls init(1) (use_user_pref=1) in turn calling get_and_create_userstate_dir(), which stats $self->{user_dir}, ".spamassassin") looking for a user pref.

Adding the following semodule resolves the errors:

module mysaupdate 1.0;

require {
        type spamd_update_t;
        type admin_home_t;
        type spamc_home_t;
        class dir { search getattr };

#============= spamd_update_t ==============
allow spamd_update_t admin_home_t:dir search;
allow spamd_update_t spamc_home_t:dir getattr;

Both of these denials are currently dontaudit in the policy, so don't show up in ausearch w/o using semodule -DB

(this also assumes current fcontext on /root/.spamassassin, if it exists)
Comment 18 Miroslav Grepl 2013-01-21 10:28:31 EST
Great. Thank you.
Comment 19 Paul Howarth 2013-01-24 04:52:06 EST
I see this in F-18 too.
Comment 20 Miroslav Grepl 2013-01-30 04:55:52 EST
Comment 21 Fedora Update System 2013-02-04 17:03:20 EST
selinux-policy-3.10.0-167.fc17 has been submitted as an update for Fedora 17.
Comment 22 Scott Shambarger 2013-02-04 18:17:02 EST
Installed and ran from sa-update from cron, didn't see any warning output.

Appears fixed. :)
Comment 23 Fedora Update System 2013-02-05 11:58:53 EST
Package selinux-policy-3.10.0-167.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-167.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 24 Fedora Update System 2013-02-12 00:07:30 EST
selinux-policy-3.10.0-167.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

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