I am currently trying to tidy up my local modules which have been in place for a number of years and which have probably been superseded by more recent policies. I put SE into permissive mode and removed the relevant local policy module.
One resulting denial suggested allowing access with: setsebool -P spamd_enable_home_dirs=1
This surprised me because I thought I had this set. Sure enough: # getsebool -a | grep spam spamassassin_can_network --> off spamd_enable_home_dirs --> on
Surely SETroubleshoot should realise that this bool is already set?
I can of course recreate a local policy module to deal with this denial, but I just wondered why this came up as a suggested remedy?
The full avc is listed below.
Thank you to all involved in this this great endeavour...
Mark
Summary SELinux is preventing the spamd daemon from reading users' home directories. Detailed Description [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.]
SELinux has denied the spamd daemon access to users' home directories. Someone is attempting to access your home directories via your spamd daemon. If you only setup spamd to share non-home directories, this probably signals a intrusion attempt.
Allowing Access If you want spamd to share home directories you need to turn on the spamd_enable_home_dirs boolean: "setsebool -P spamd_enable_home_dirs=1" Fix Command setsebool -P spamd_enable_home_dirs=1 Additional Information
Source Context: unconfined_u:system_r:spamd_t:s0 Target Context: system_u:object_r:user_pyzor_home_t:s0 Target Objects: /home/mark/.pyzor/servers [ file ] Source: pyzor Source Path: /usr/bin/python Port: <Unknown> Host: mydomain.com Source RPM Packages: python-2.5.1-26.fc9 Target RPM Packages: Policy RPM: selinux-policy-3.3.1-118.fc9 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Permissive Plugin Name: spamd_enable_home_dirs Host Name: mydomain.com Platform: Linux mydomain.com 2.6.26.6-79.fc9.i686 #1 SMP Fri Oct 17 14:52:14 EDT 2008 i686 i686 Alert Count: 723 First Seen: Sun Nov 2 01:13:46 2008 Last Seen: Mon Feb 2 14:57:22 2009 Local ID: 22265a4e-86dd-4a61-a314-7c3fc363d5ee Line Numbers:
Raw Audit Messages :
node=mydomain.com type=AVC msg=audit(1233586642.291:4900): avc: denied { getattr } for pid=17929 comm="pyzor" path="/home/mark/.pyzor/servers" dev=sda8 ino=3172618 scontext=unconfined_u:system_r:spamd_t:s0 tcontext=system_u:object_r:user_pyzor_home_t:s0 tclass=file node=mydomain.com type=SYSCALL msg=audit(1233586642.291:4900): arch=40000003 syscall=195 success=yes exit=0 a0=8774db0 a1=bfc5c3c8 a2=cd9ff4 a3=86f01b8 items=0 ppid=9197 pid=17929 auid=0 uid=500 gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=726 comm="pyzor" exe="/usr/bin/python" subj=unconfined_u:system_r:spamd_t:s0 key=(null)
I think, but not sure, that your home space is mislabeled ( especially pyzor_home_t). if my memory serves me correct then labeling for that location has recently changes. It seems that setroubleshoot hasnt been updated to reflect this change yet.
to fix, restorecon -R -v /home, might fix this issue.
hth
On Mon, 2009-02-02 at 15:29 +0000, Arthur Dent wrote:
I am currently trying to tidy up my local modules which have been in place for a number of years and which have probably been superseded by more recent policies. I put SE into permissive mode and removed the relevant local policy module.
One resulting denial suggested allowing access with: setsebool -P spamd_enable_home_dirs=1
This surprised me because I thought I had this set. Sure enough: # getsebool -a | grep spam spamassassin_can_network --> off spamd_enable_home_dirs --> on
Surely SETroubleshoot should realise that this bool is already set?
I can of course recreate a local policy module to deal with this denial, but I just wondered why this came up as a suggested remedy?
The full avc is listed below.
Thank you to all involved in this this great endeavour...
Mark
Summary SELinux is preventing the spamd daemon from reading users' home directories. Detailed Description [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.]
SELinux has denied the spamd daemon access to users' home directories. Someone is attempting to access your home directories via your spamd daemon. If you only setup spamd to share non-home directories, this probably signals a intrusion attempt.
Allowing Access If you want spamd to share home directories you need to turn on the spamd_enable_home_dirs boolean: "setsebool -P spamd_enable_home_dirs=1" Fix Command setsebool -P spamd_enable_home_dirs=1 Additional Information
Source Context: unconfined_u:system_r:spamd_t:s0 Target Context: system_u:object_r:user_pyzor_home_t:s0 Target Objects: /home/mark/.pyzor/servers [ file ] Source: pyzor Source Path: /usr/bin/python Port: <Unknown> Host: mydomain.com Source RPM Packages: python-2.5.1-26.fc9 Target RPM Packages: Policy RPM: selinux-policy-3.3.1-118.fc9 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Permissive Plugin Name: spamd_enable_home_dirs Host Name: mydomain.com Platform: Linux mydomain.com 2.6.26.6-79.fc9.i686 #1 SMP Fri Oct 17 14:52:14 EDT 2008 i686 i686 Alert Count: 723 First Seen: Sun Nov 2 01:13:46 2008 Last Seen: Mon Feb 2 14:57:22 2009 Local ID: 22265a4e-86dd-4a61-a314-7c3fc363d5ee Line Numbers:
Raw Audit Messages :
node=mydomain.com type=AVC msg=audit(1233586642.291:4900): avc: denied { getattr } for pid=17929 comm="pyzor" path="/home/mark/.pyzor/servers" dev=sda8 ino=3172618 scontext=unconfined_u:system_r:spamd_t:s0 tcontext=system_u:object_r:user_pyzor_home_t:s0 tclass=file node=mydomain.com type=SYSCALL msg=audit(1233586642.291:4900): arch=40000003 syscall=195 success=yes exit=0 a0=8774db0 a1=bfc5c3c8 a2=cd9ff4 a3=86f01b8 items=0 ppid=9197 pid=17929 auid=0 uid=500 gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=726 comm="pyzor" exe="/usr/bin/python" subj=unconfined_u:system_r:spamd_t:s0 key=(null)
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Mon, Feb 02, 2009 at 05:34:47PM +0100, Dominick Grift wrote:
I think, but not sure, that your home space is mislabeled ( especially pyzor_home_t). if my memory serves me correct then labeling for that location has recently changes. It seems that setroubleshoot hasnt been updated to reflect this change yet.
to fix, restorecon -R -v /home, might fix this issue.
hth
Thanks for that suggestion. I tried it, and there were indeed some files that got relabelled - but not the pyzor ones. Do you think that the ones that did are significant in this issue? (Output listed below).
I have already created a local policy using audit2allow and this produced the following:
require { type user_pyzor_home_t; type spamd_t; class file { read getattr }; }
#============= spamd_t ============== allow spamd_t user_pyzor_home_t:file { read getattr };
Do you think I still need this local policy?
Thanks for your help...
Mark
Output of the relabelling (apologies for the line-wrap)...
restorecon -R -v /home restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ecrm1200.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ectt1000.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ecbx1200.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ecrm1000.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.spamassassin context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_toks.expire2474 context system_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_journal context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes.lock.troodos.org.uk.20547 context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/user_prefs context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes.lock.troodos.org.uk.23935 context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_seen context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_toks context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.Xauthority context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_xauth_home_t:s0
I think the spamassassin dirs may be significant. not sure. you not try? just uninstall the module and try to reproduce it.
On Mon, 2009-02-02 at 16:52 +0000, Arthur Dent wrote:
On Mon, Feb 02, 2009 at 05:34:47PM +0100, Dominick Grift wrote:
I think, but not sure, that your home space is mislabeled ( especially pyzor_home_t). if my memory serves me correct then labeling for that location has recently changes. It seems that setroubleshoot hasnt been updated to reflect this change yet.
to fix, restorecon -R -v /home, might fix this issue.
hth
Thanks for that suggestion. I tried it, and there were indeed some files that got relabelled - but not the pyzor ones. Do you think that the ones that did are significant in this issue? (Output listed below).
I have already created a local policy using audit2allow and this produced the following:
require { type user_pyzor_home_t; type spamd_t; class file { read getattr }; }
#============= spamd_t ============== allow spamd_t user_pyzor_home_t:file { read getattr };
Do you think I still need this local policy?
Thanks for your help...
Mark
Output of the relabelling (apologies for the line-wrap)...
restorecon -R -v /home restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ecrm1200.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ectt1000.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ecbx1200.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ecrm1000.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.spamassassin context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_toks.expire2474 context system_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_journal context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes.lock.troodos.org.uk.20547 context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/user_prefs context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes.lock.troodos.org.uk.23935 context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_seen context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_toks context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.Xauthority context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_xauth_home_t:s0
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On second thought, no. I do not think spamd_t has access to user_pyzor_home_t.
sesearch --allow -s spamd_t | grep home | less
so i guess your custom module fixes that. consider filing a bug report for this issue.
On Mon, 2009-02-02 at 16:52 +0000, Arthur Dent wrote:
On Mon, Feb 02, 2009 at 05:34:47PM +0100, Dominick Grift wrote:
I think, but not sure, that your home space is mislabeled ( especially pyzor_home_t). if my memory serves me correct then labeling for that location has recently changes. It seems that setroubleshoot hasnt been updated to reflect this change yet.
to fix, restorecon -R -v /home, might fix this issue.
hth
Thanks for that suggestion. I tried it, and there were indeed some files that got relabelled - but not the pyzor ones. Do you think that the ones that did are significant in this issue? (Output listed below).
I have already created a local policy using audit2allow and this produced the following:
require { type user_pyzor_home_t; type spamd_t; class file { read getattr }; }
#============= spamd_t ============== allow spamd_t user_pyzor_home_t:file { read getattr };
Do you think I still need this local policy?
Thanks for your help...
Mark
Output of the relabelling (apologies for the line-wrap)...
restorecon -R -v /home restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ecrm1200.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ectt1000.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ecbx1200.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.texlive2007/texmf-var/fonts/pk/ljfour/jknappen/ec/ecrm1000.600pk context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_home_t:s0 restorecon reset /home/mark/.spamassassin context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_toks.expire2474 context system_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_journal context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes.lock.troodos.org.uk.20547 context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/user_prefs context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes.lock.troodos.org.uk.23935 context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_seen context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.spamassassin/bayes_toks context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_spamassassin_home_t:s0 restorecon reset /home/mark/.Xauthority context unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_xauth_home_t:s0
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Mon, Feb 02, 2009 at 07:01:16PM +0100, Dominick Grift wrote:
On second thought, no. I do not think spamd_t has access to user_pyzor_home_t.
sesearch --allow -s spamd_t | grep home | less
so i guess your custom module fixes that. consider filing a bug report for this issue.
Thanks for your help. I have not yet altered my new local policy, but I thought I would try a reboot to see if that had any affect...
Oh boy! A whole raft of denials...
This is the audit2allow result of this recent batch. It seems quite a lot to me!
require { type user_pyzor_home_t; type admin_home_t; type spamd_t; type procmail_t; class dir { read write add_name remove_name }; class file { read create ioctl write getattr unlink append }; }
#============= procmail_t ============== init_stream_connect_script(procmail_t)
#============= spamd_t ============== allow spamd_t admin_home_t:dir { read write add_name remove_name }; allow spamd_t admin_home_t:file { write getattr read create unlink ioctl append }; allow spamd_t user_pyzor_home_t:file { read getattr }; userdom_read_sysadm_home_content_files(spamd_t)
What do you think?
Thanks again
Mark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Arthur Dent wrote:
On Mon, Feb 02, 2009 at 07:01:16PM +0100, Dominick Grift wrote:
On second thought, no. I do not think spamd_t has access to user_pyzor_home_t.
sesearch --allow -s spamd_t | grep home | less
so i guess your custom module fixes that. consider filing a bug report for this issue.
Thanks for your help. I have not yet altered my new local policy, but I thought I would try a reboot to see if that had any affect...
Oh boy! A whole raft of denials...
This is the audit2allow result of this recent batch. It seems quite a lot to me!
require { type user_pyzor_home_t; type admin_home_t; type spamd_t; type procmail_t; class dir { read write add_name remove_name }; class file { read create ioctl write getattr unlink append }; }
#============= procmail_t ============== init_stream_connect_script(procmail_t)
This looks like you have some process running as initrc_t that procmail needs to talk to. If this is not a domain we have a confinement for this is fine.
#============= spamd_t ============== allow spamd_t admin_home_t:dir { read write add_name remove_name }; allow spamd_t admin_home_t:file { write getattr read create unlink ioctl append };
This is spamd creating stuff in the /root directory. Not sure if you want to actually allow this. Might want to setup the directory with properly lableing to allow spamd to write there. userdom_read_sysadm_home_content_files(spamd_t)
What directory?
You could setup labeling of
# semanage fcontext -a -t spamassassin_home_t '/root/.spamassassin(/.*)?' #restorecon -R -v /root
allow spamd_t user_pyzor_home_t:file { read getattr };
This should be allowed and should be reported as a bug.
What do you think?
Thanks again
Mark
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Mon, Feb 02, 2009 at 01:52:36PM -0500, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Arthur Dent wrote:
On Mon, Feb 02, 2009 at 07:01:16PM +0100, Dominick Grift wrote:
On second thought, no. I do not think spamd_t has access to user_pyzor_home_t.
sesearch --allow -s spamd_t | grep home | less
so i guess your custom module fixes that. consider filing a bug report for this issue.
Thanks for your help. I have not yet altered my new local policy, but I thought I would try a reboot to see if that had any affect...
Oh boy! A whole raft of denials...
This is the audit2allow result of this recent batch. It seems quite a lot to me!
require { type user_pyzor_home_t; type admin_home_t; type spamd_t; type procmail_t; class dir { read write add_name remove_name }; class file { read create ioctl write getattr unlink append }; }
#============= procmail_t ============== init_stream_connect_script(procmail_t)
This looks like you have some process running as initrc_t that procmail needs to talk to. If this is not a domain we have a confinement for this is fine.
Well my mailchain is as follows: fetchmail->procmail->clamassassin(using clamd)->spamassassin->dovecot
clamd and spamd are both started from init.d scripts if that's what this means...
#============= spamd_t ============== allow spamd_t admin_home_t:dir { read write add_name remove_name }; allow spamd_t admin_home_t:file { write getattr read create unlink ioctl append };
This is spamd creating stuff in the /root directory. Not sure if you want to actually allow this. Might want to setup the directory with properly lableing to allow spamd to write there. userdom_read_sysadm_home_content_files(spamd_t)
Hmmm... I was about to say that nothing is run as root WRT spamassassin or spamd, but then I looked at the avcs. It seems that razor is the offender here: avc: denied { getattr } for pid=2200 comm="spamd" path="/root/.razor/razor-agent.conf"
(and several others like it)
I don't know if razor can be installed by a non-root user. If not, can I (should I?) just do what you suggest below?
What directory?
Could this be /root/.razor/ ?
You could setup labeling of
# semanage fcontext -a -t spamassassin_home_t '/root/.spamassassin(/.*)?' #restorecon -R -v /root
Does this make the command: # semanage fcontext -a -t spamassassin_home_t '/root/.razor(/.*)?' # restorecon -R -v /root
?
allow spamd_t user_pyzor_home_t:file { read getattr };
This should be allowed and should be reported as a bug.
I will look into this tomorrow...
Thank you very much for your help so far.
Regards
Mark
On Mon, Feb 02, 2009 at 07:27:25PM +0000, Arthur Dent wrote:
On Mon, Feb 02, 2009 at 01:52:36PM -0500, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Arthur Dent wrote:
On Mon, Feb 02, 2009 at 07:01:16PM +0100, Dominick Grift wrote:
#============= spamd_t ============== allow spamd_t admin_home_t:dir { read write add_name remove_name }; allow spamd_t admin_home_t:file { write getattr read create unlink ioctl append };
This is spamd creating stuff in the /root directory. Not sure if you want to actually allow this. Might want to setup the directory with properly lableing to allow spamd to write there. userdom_read_sysadm_home_content_files(spamd_t)
Hmmm... I was about to say that nothing is run as root WRT spamassassin or spamd, but then I looked at the avcs. It seems that razor is the offender here: avc: denied { getattr } for pid=2200 comm="spamd" path="/root/.razor/razor-agent.conf"
(and several others like it)
I don't know if razor can be installed by a non-root user. If not, can I (should I?) just do what you suggest below?
What directory?
Could this be /root/.razor/ ?
You could setup labeling of
# semanage fcontext -a -t spamassassin_home_t '/root/.spamassassin(/.*)?' #restorecon -R -v /root
Does this make the command: # semanage fcontext -a -t spamassassin_home_t '/root/.razor(/.*)?' # restorecon -R -v /root
OK. Forget this... I poked around my filesystem and found that actually I *did* have razor in my non-privileged user area. However, strangely, I also had it in /root. The odd thing is that it seems that for the most part razor would use the /home/mark/.razor files, but on this occasion (and others clearly) - on a whim - must have used the /root/.razor files to do its stuff.
I have removed the /root/.razor directory and also removed those items from my local policy. So far (touching wood here) it seems OK...
Thanks for your help on this...
Mark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Arthur Dent wrote:
I am currently trying to tidy up my local modules which have been in place for a number of years and which have probably been superseded by more recent policies. I put SE into permissive mode and removed the relevant local policy module.
One resulting denial suggested allowing access with: setsebool -P spamd_enable_home_dirs=1
This surprised me because I thought I had this set. Sure enough: # getsebool -a | grep spam spamassassin_can_network --> off spamd_enable_home_dirs --> on
Surely SETroubleshoot should realise that this bool is already set?
SETroubleshoot is responding to what the kernel tells it. It reads the avc and then tries to report what it believes is the problem. In newer versions of Fedora, setroubleshoot does read the policy and trys out different booleans to see if the access would be allowed. So in a way it does know what booleans are turned on.
I can of course recreate a local policy module to deal with this denial, but I just wondered why this came up as a suggested remedy?
The full avc is listed below.
Thank you to all involved in this this great endeavour...
Mark
Summary SELinux is preventing the spamd daemon from reading users' home directories. Detailed Description [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.]
SELinux has denied the spamd daemon access to users' home directories. Someone is attempting to access your home directories via your spamd daemon. If you only setup spamd to share non-home directories, this probably signals a intrusion attempt.
Allowing Access If you want spamd to share home directories you need to turn on the spamd_enable_home_dirs boolean: "setsebool -P spamd_enable_home_dirs=1" Fix Command setsebool -P spamd_enable_home_dirs=1 Additional Information
Source Context: unconfined_u:system_r:spamd_t:s0 Target Context: system_u:object_r:user_pyzor_home_t:s0 Target Objects: /home/mark/.pyzor/servers [ file ] Source: pyzor Source Path: /usr/bin/python Port: <Unknown> Host: mydomain.com Source RPM Packages: python-2.5.1-26.fc9 Target RPM Packages: Policy RPM: selinux-policy-3.3.1-118.fc9 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Permissive Plugin Name: spamd_enable_home_dirs Host Name: mydomain.com Platform: Linux mydomain.com 2.6.26.6-79.fc9.i686 #1 SMP Fri Oct 17 14:52:14 EDT 2008 i686 i686 Alert Count: 723 First Seen: Sun Nov 2 01:13:46 2008 Last Seen: Mon Feb 2 14:57:22 2009 Local ID: 22265a4e-86dd-4a61-a314-7c3fc363d5ee Line Numbers:
Raw Audit Messages :
node=mydomain.com type=AVC msg=audit(1233586642.291:4900): avc: denied { getattr } for pid=17929 comm="pyzor" path="/home/mark/.pyzor/servers" dev=sda8 ino=3172618 scontext=unconfined_u:system_r:spamd_t:s0 tcontext=system_u:object_r:user_pyzor_home_t:s0 tclass=file node=mydomain.com type=SYSCALL msg=audit(1233586642.291:4900): arch=40000003 syscall=195 success=yes exit=0 a0=8774db0 a1=bfc5c3c8 a2=cd9ff4 a3=86f01b8 items=0 ppid=9197 pid=17929 auid=0 uid=500 gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=726 comm="pyzor" exe="/usr/bin/python" subj=unconfined_u:system_r:spamd_t:s0 key=(null)
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org
-
Arthur Dent -
Daniel J Walsh -
Dominick Grift