Bug 738118 - something wrong with exim + selinux + no unconfined
Summary: something wrong with exim + selinux + no unconfined
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-14 02:43 UTC by Robin Powell
Modified: 2011-12-04 02:35 UTC (History)
3 users (show)

Fixed In Version: selinux-policy-3.9.16-48.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-04 02:35:36 UTC


Attachments (Terms of Use)

Description Robin Powell 2011-09-14 02:43:37 UTC
My apologies in advance if this turns out to be pebkac; I haven't investigated yet to my usual level of thoroughness.  I wanted to get this out because I think it's fairly important, and to others the fix may be obvious.

I've got two fairly identical F15 machines with the unconfined module disabled.  One uses the default sendmail, the other uses exim.  With sendmail, staff_u can send email with no problem.  In fact, so can user_u.  With exim, staff_u gets these:


 type=AVC msg=audit(1315968105.961:104340): avc:  denied  { setuid } for  pid=19806 comm="exim" capability=7  scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability
type=AVC msg=audit(1315968105.969:104341): avc:  denied  { dac_override } for  pid=19806 comm="exim" capability=1  scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability
type=AVC msg=audit(1315968105.969:104341): avc:  denied  { dac_read_search } for  pid=19806 comm="exim" capability=2  scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability
type=AVC msg=audit(1315968105.977:104343): avc:  denied  { setuid } for  pid=19809 comm="exim" capability=7  scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability
type=AVC msg=audit(1315968105.991:104345): avc:  denied  { dac_override } for  pid=19806 comm="exim" capability=1  scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability
type=AVC msg=audit(1315968105.991:104345): avc:  denied  { dac_read_search } for  pid=19806 comm="exim" capability=2  scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability
type=AVC msg=audit(1315968105.994:104346): avc:  denied  { setuid } for  pid=19810 comm="exim" capability=7  scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability


That's with setenforce 1.  With setenforce 0:



type=AVC msg=audit(1315968165.404:104359): avc:  denied  { setuid } for  pid=19817 comm="exim" capability=7  scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability
type=AVC msg=audit(1315968165.411:104360): avc:  denied  { dac_override } for  pid=19817 comm="exim" capability=1  scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=capability
type=AVC msg=audit(1315968165.411:104360): avc:  denied  { append } for  pid=19817 comm="exim" name="main.log" dev=vda2 ino=10422 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_log_t:s0 tclass=file
type=AVC msg=audit(1315968165.411:104360): avc:  denied  { open } for  pid=19817 comm="exim" name="main.log" dev=vda2 ino=10422 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_log_t:s0 tclass=file
type=AVC msg=audit(1315968167.232:104363): avc:  denied  { write } for  pid=19817 comm="exim" name="input" dev=vda2 ino=6255 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=dir
type=AVC msg=audit(1315968167.232:104363): avc:  denied  { add_name } for  pid=19817 comm="exim" name="1R3fQz-00059d-DV-D" scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=dir
type=AVC msg=audit(1315968167.232:104363): avc:  denied  { create } for  pid=19817 comm="exim" name="1R3fQz-00059d-DV-D" scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file
type=AVC msg=audit(1315968167.232:104363): avc:  denied  { read write open } for  pid=19817 comm="exim" name="1R3fQz-00059d-DV-D" dev=vda2 ino=3622 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file
type=AVC msg=audit(1315968167.232:104364): avc:  denied  { setattr } for  pid=19817 comm="exim" name="1R3fQz-00059d-DV-D" dev=vda2 ino=3622 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file
type=AVC msg=audit(1315968167.232:104365): avc:  denied  { lock } for  pid=19817 comm="exim" path="/var/spool/exim/input/1R3fQz-00059d-DV-D" dev=vda2 ino=3622 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file
type=AVC msg=audit(1315968167.582:104366): avc:  denied  { remove_name } for  pid=19817 comm="exim" name="hdr.19817" dev=vda2 ino=10464 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=dir
type=AVC msg=audit(1315968167.582:104366): avc:  denied  { rename } for  pid=19817 comm="exim" name="hdr.19817" dev=vda2 ino=10464 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file
type=AVC msg=audit(1315968167.647:104367): avc:  denied  { append } for  pid=19817 comm="exim" name="1R3fQz-00059d-DV" dev=vda2 ino=10465 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file
type=AVC msg=audit(1315968167.737:104369): avc:  denied  { read write } for  pid=19820 comm="exim" name="retry.lockfile" dev=vda2 ino=6311 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=file
type=AVC msg=audit(1315968167.737:104369): avc:  denied  { open } for  pid=19820 comm="exim" name="retry.lockfile" dev=vda2 ino=6311 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=file
type=AVC msg=audit(1315968167.737:104370): avc:  denied  { lock } for  pid=19820 comm="exim" path="/var/spool/exim/db/retry.lockfile" dev=vda2 ino=6311 scontext=staff_u:staff_r:staff_t:s0 tcontext=system_u:object_r:exim_spool_t:s0 tclass=file
type=AVC msg=audit(1315968170.217:104371): avc:  denied  { unlink } for  pid=19820 comm="exim" name="1R3fQz-00059d-DV" dev=vda2 ino=10465 scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:object_r:exim_spool_t:s0 tclass=file

In both cases, what I'm actually running, as staff_u, is /usr/sbin/exim robin@teddyb.org ; in the second case , I enter date and hit ctrl-d, in the former case it just errors out.

-Robin

Comment 1 Robin Powell 2011-09-14 05:51:14 UTC
Something else that exim needs, apparently to run pipe aliases properly:


type=AVC msg=audit(1315979065.075:125464): avc:  denied  { read } for  pid=29926 comm="exim" name="stat" dev=proc ino=4026532009 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
type=AVC msg=audit(1315979065.075:125464): avc:  denied  { open } for  pid=29926 comm="exim" name="stat" dev=proc ino=4026532009 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file

I can stick that in a separate ticket if you like.

-Robin

Comment 2 Miroslav Grepl 2011-09-14 06:04:32 UTC
No, that's fine.

So you added a local policy looks like


# cat myexim.te 
policy_module(myexim, 1.0)

require{
 type staff_t;
 role staff_r;
}

exim_domtrans(staff_t)
role staff_r types exim_t;




# make -f /usr/share/selinux/devel/Makefile myexim.pp
# semodule -i myexim.pp

Comment 3 Robin Powell 2011-09-14 06:11:24 UTC
I'm confused, you're asking me to do that, yes?  For testing, or do you expect me to leave that in forever?  If the latter, why do I need to do that for exim, but not sendmail?

-Robni

Comment 4 Robin Powell 2011-09-14 06:21:35 UTC
OK, that seems to fix the basic problem for staff_u.  It doesn't fix it for anybody else (obviously), nor does it fix the pipe problem (which there may be a more general problem there; I'm posting to the mailing list about that).

-Robin

Comment 5 Miroslav Grepl 2011-09-14 07:44:56 UTC
(In reply to comment #3)
> I'm confused, you're asking me to do that, yes?  For testing, or do you expect
> me to leave that in forever?  If the latter, why do I need to do that for exim,
> but not sendmail?
> 
> -Robni

It is for testing and if this looks good, we will add it to the default policy. 

Also I haven't read a sendmail bugzilla yet.

Comment 6 Robin Powell 2011-09-14 08:22:11 UTC
That was my point: sendmail doesn't need this fix, when everything else is exactly the same.  That strikes me as odd, and worth investigating.

Anyways, the fix seems to work, as far as it goes.  Do you want me to split the pipe issues out into a separate bug, since it doesn't fix those?

-Robin

Comment 7 Miroslav Grepl 2011-09-14 08:32:36 UTC
A new bug is not necessary.

Comment 8 Robin Powell 2011-09-17 07:19:38 UTC
I found something else: procmail under exim can't send mail, but sendmail works.  I don't really understand sesearch :), so here's my lame search for the rules in question:

rlpowell@stodi> sh -c "sesearch -SC --allow | grep procmail | grep sendmail | grep -i trans"    
   allow procmail_t sendmail_t : process { transition sigchld signal } ;
   allow sendmail_t procmail_t : process { transition sigchld } ;
rlpowell@stodi> sh -c "sesearch -SC --allow | grep procmail | grep exim | grep -i trans"        
   allow exim_t procmail_t : process transition ;

Bizarrely, it seems that when procmail runs /usr/sbin/sendmail on my system, it ends up at sendmail_t instead of exim_t 0.o, which then tries to read/write exim directories, since it's actually exim.

I've now got the following module to fix exim issues:

- -------------------------

policy_module(myexim738118, 1.0)

require{
  type staff_t;
  role staff_r;
  type user_t;
  role user_r;
  type procmail_t;
  type proc_t;
  class file { read open };
}

exim_domtrans(staff_t)
role staff_r types exim_t;
exim_domtrans(user_t)
role user_r types exim_t;
exim_domtrans(procmail_t)

allow exim_t proc_t:file { read open };

- -------------------------

and it compiles fine, but when I try to install it:

rlpowell@stodi> sudo semodule -i myexim738118.pp 
libsepol.expand_terule_helper: conflicting TE rule for (procmail_t, exim_exec_t:process):  old was exim_t, new is sendmail_t
libsepol.expand_module: Error during expand
libsemanage.semanage_expand_sandbox: Expand module failed
/usr/sbin/semodule:  Failed!

Which I am quite confused by; does it have "old" and "new" reversed?

-Robin

Comment 9 Daniel Walsh 2011-09-18 02:46:38 UTC
This is because we have a rule that says if procmail executes an mta_exec_type it will transition to sendmail_t.  Really we should start to eliminate some of the additional domains that we have for different mailers and combine them into one domain.

Comment 10 Robin Powell 2011-09-18 04:20:47 UTC
OK, so what do I do to make my server work?  My whole Fedora transition project is now hanging on this. :(

-Robin

Comment 11 Robin Powell 2011-09-18 20:04:18 UTC
OK, here's what I've got that seems to have things working for me:


policy_module(myexim738118, 1.0)

require{
  type staff_t;
  role staff_r;
  type user_t;
  role user_r;
  type procmail_t;
  type proc_t;
  class file { read open };
  type sendmail_t;
  type exim_log_t;
  type exim_spool_t;
}

exim_domtrans(staff_t)
role staff_r types exim_t;
exim_domtrans(user_t)
role user_r types exim_t;

allow exim_t proc_t:file { read open };

read_files_pattern(sendmail_t, exim_log_t, exim_log_t)
manage_files_pattern(sendmail_t, exim_spool_t, exim_spool_t)
manage_dirs_pattern(sendmail_t, exim_spool_t, exim_spool_t)


Probably a better way to do that, but there it is.

I really like that unified mail domain plan, fwiw.

-Robin

Comment 12 Robin Powell 2011-09-18 20:29:29 UTC
One more I had to add:


files_read_usr_files(exim_t)


That's because exim was running mhonarc, which needs access to perl stuff:


type=AVC msg=audit(09/18/2011 13:21:28.379:72299) : avc:  denied  { getattr } for  pid=17195 comm=mhonarc path=/usr/share/perl5/strict.pm dev=vda2 ino=397745 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=AVC msg=audit(09/18/2011 13:21:28.380:72300) : avc:  denied  { open } for  pid=17195 comm=mhonarc name=strict.pm dev=vda2 ino=397745 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=AVC msg=audit(09/18/2011 13:21:28.380:72300) : avc:  denied  { read } for  pid=17195 comm=mhonarc name=strict.pm dev=vda2 ino=397745 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=AVC msg=audit(09/18/2011 13:21:28.380:72301) : avc:  denied  { ioctl } for  pid=17195 comm=mhonarc path=/usr/share/perl5/strict.pm dev=vda2 ino=397745 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file

which exim doesn't have.  I'm not sure, again, whether that should be a separate ticket or not; let me know.

-Robin

Comment 13 Miroslav Grepl 2011-09-19 13:28:37 UTC
Ok, I am adding fixes for Fedora16 and I will start with combining of domains in Fedora17.

Comment 14 Miroslav Grepl 2011-09-19 13:29:08 UTC
(In reply to comment #13)
> Ok, I am adding fixes for Fedora16 and 

Of course these fixes I am also adding to F15.

Comment 15 Miroslav Grepl 2011-09-22 11:58:54 UTC
Fixed in -41.fc15 release which I will build today.

Comment 16 Robin Powell 2011-10-08 00:44:46 UTC
This seems to be mostly working.  The only thing I'm getting now is:


type=AVC msg=audit(10/07/2011 17:35:42.110:342760) : avc:  denied  { read } for  pid=19409 comm=sendmail path=/tmp/RsWNhBkN (deleted) dev=vda2 ino=137054 scontext=staff_u:staff_r:exim_t:s0 tcontext=staff_u:object_r:user_mail_tmp_t:s0 tclass=file
type=AVC msg=audit(10/07/2011 17:35:42.471:342763) : avc:  denied  { read write } for  pid=19412 comm=procmail name=4 dev=devpts ino=7 scontext=staff_u:staff_r:procmail_t:s0 tcontext=staff_u:object_r:user_devpts_t:s0 tclass=chr_file

That was from a manual run of mailx -v; I'm guessing the second was procmail trying to talk back to me for some reason.

-Robin

Comment 17 Miroslav Grepl 2011-10-10 11:22:19 UTC
Ok, could you reproduce this latest AVC msgs and add me output of 

# ausearch -m avc -ts recent

Comment 18 Fedora Update System 2011-11-16 16:17:24 UTC
selinux-policy-3.9.16-48.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-48.fc15

Comment 19 Fedora Update System 2011-11-17 23:35:46 UTC
Package selinux-policy-3.9.16-48.fc15:
* should fix your issue,
* was pushed to the Fedora 15 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.9.16-48.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-16023/selinux-policy-3.9.16-48.fc15
then log in and leave karma (feedback).

Comment 20 Fedora Update System 2011-12-04 02:35:36 UTC
selinux-policy-3.9.16-48.fc15 has been pushed to the Fedora 15 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.