Trouble sending mail from PHP scripts

[Scott Gifford]

Hello,

I'm having some trouble with an SELinux policy to allow sending mail from a
PHP script run from our Web server with a local installation of qmail on a
CentOS 5 system.  We send mail using php's mail() function, which calls
/usr/bin/sendmail, which in turn calls /var/qmail/bin/qmail-inject, then
/var/qmail/bin/qmail-queue, which actually puts the message in the queue.

SELinux comes with some default qmail policies, but out-of-the-box we had
AVC denials when qmail-queue would try to write the message into the queue,
since the Web script context was not permitted to do this.

I decided to take this opportunity to learn about writing SELinux policies.
 I know qmail very well, so thought I would write a policy for qmail.  The
policy would transition to a new type mail_qmail_queue_t when qmail-queue
was run, and then allow this type to write into the queue.

I think I have the basics working, but I'm running into some snags, and I
don't have enough experience to know what sorts of solutions are likely to
work out.

First, I am seeing some denials that seem to be related to file descriptors
passed by Apache to qmail-queue.  When qmail-queue is run, stderr is
connected to the Web server log, and stdout is connected to the HTTP socket.
 This is a pretty normal setup, which will cause any output to show up in
the user's browser and errors to show up in the Web server log.  However I
get these AVC denials:

   - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
    denied  { read } for  pid=9643 comm="qmail-queue"
path="pipe:[4937510]"
   dev=pipefs ino=4937510 scontext=system_u:system_r:mail_qmail_queue_t:s0
   tcontext=system_u:system_r:httpd_t:s0 tclass=fifo_file
   - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
    denied  { append } for  pid=9643 comm="qmail-queue"
   path="/var/log/httpd/error_log" dev=md2 ino=24183170
   scontext=system_u:system_r:mail_qmail_queue_t:s0
   tcontext=user_u:object_r:httpd_log_t:s0 tclass=file
   - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
    denied  { read write } for  pid=9643 comm="qmail-queue"
   path="socket:[13964]" dev=sockfs ino=13964
   scontext=system_u:system_r:mail_qmail_queue_t:s0
   tcontext=system_u:system_r:httpd_t:s0 tclass=tcp_socket

I could write policy to allow mail_qmail_queue access to these httpd_t
resources, but in general it should not have that access; only when it is
run from Apache.  I could create a special type for "qmail-queue run from
Apache", but that quickly gets out-of-hand if I create custom policies for
each program that sends mail.  What is the normal way to deal with these
sorts of situations?

Second, I am having some trouble getting file contexts set up.  I have
several qmail installations with different policies, so I wrote a rule in my
fc file like this:

/var/qmail(-.*)?/bin/qmail-queue --
gen_context(system_u:object_r:mail_qmail_queue_exec_t,s0)


When I use that rule, qmail-queue gets labeled bin_t, I think because of
another rule saying anything in a directory named "bin" is "bin_t". 
How can
I tell it my rule is more specific or higher priority than the default rule?
 For that matter, how can I figure out what rule is overriding mine?

Third, is there a useful guide for troubleshooting SELinux policy execution?
 When things don't work as I expect them to, it's hard to find the reason if
it's not obvious from the audit.log.

Finally, can anybody recommend a good book or other resource for learning
SELinux?  I have *SELinux by Example*, but it seems that conventions for
policy files have changed a great deal since it was written.

Thanks!

-----Scott.

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/30/2010 08:27 AM, Scott Gifford wrote:
>  Hello,
>  
>  I'm having some trouble with an SELinux policy to allow sending mail from a
>  PHP script run from our Web server with a local installation of qmail on a
>  CentOS 5 system.  We send mail using php's mail() function, which calls
>  /usr/bin/sendmail, which in turn calls /var/qmail/bin/qmail-inject, then
>  /var/qmail/bin/qmail-queue, which actually puts the message in the queue.
>  
>  SELinux comes with some default qmail policies, but out-of-the-box we had
>  AVC denials when qmail-queue would try to write the message into the queue,
>  since the Web script context was not permitted to do this.
>  
>  I decided to take this opportunity to learn about writing SELinux policies.
>   I know qmail very well, so thought I would write a policy for qmail.  The
>  policy would transition to a new type mail_qmail_queue_t when qmail-queue
>  was run, and then allow this type to write into the queue.
>  
>  I think I have the basics working, but I'm running into some snags, and I
>  don't have enough experience to know what sorts of solutions are likely to
>  work out.
>  
>  First, I am seeing some denials that seem to be related to file descriptors
>  passed by Apache to qmail-queue.  When qmail-queue is run, stderr is
>  connected to the Web server log, and stdout is connected to the HTTP socket.
>   This is a pretty normal setup, which will cause any output to show up in
>  the user's browser and errors to show up in the Web server log.  However I
>  get these AVC denials:
>  
>     - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
>      denied  { read } for  pid=9643 comm="qmail-queue"
> path="pipe:[4937510]"
>     dev=pipefs ino=4937510 scontext=system_u:system_r:mail_qmail_queue_t:s0
>     tcontext=system_u:system_r:httpd_t:s0 tclass=fifo_file
>     - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
>      denied  { append } for  pid=9643 comm="qmail-queue"
>     path="/var/log/httpd/error_log" dev=md2 ino=24183170
>     scontext=system_u:system_r:mail_qmail_queue_t:s0
>     tcontext=user_u:object_r:httpd_log_t:s0 tclass=file
>     - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
>      denied  { read write } for  pid=9643 comm="qmail-queue"
>     path="socket:[13964]" dev=sockfs ino=13964
>     scontext=system_u:system_r:mail_qmail_queue_t:s0
>     tcontext=system_u:system_r:httpd_t:s0 tclass=tcp_socket
>  
>  I could write policy to allow mail_qmail_queue access to these httpd_t
>  resources, but in general it should not have that access; only when it is
>  run from Apache.  I could create a special type for "qmail-queue run from
>  Apache", but that quickly gets out-of-hand if I create custom policies for
>  each program that sends mail.  What is the normal way to deal with these
>  sorts of situations? 
You can silently deny access vectors. So if you know that denying this
access does not cause any loss in functionality then consider silently
denying some of this.

Anything else, i guess,  will just have to be allowed.

>  Second, I am having some trouble getting file contexts set up.  I
> have
>  several qmail installations with different policies, so I wrote a rule in my
>  fc file like this:
>  
>  /var/qmail(-.*)?/bin/qmail-queue --
>  gen_context(system_u:object_r:mail_qmail_queue_exec_t,s0)
>  
>  
>  When I use that rule, qmail-queue gets labeled bin_t, I think because of
>  another rule saying anything in a directory named "bin" is "bin_t". 
> How can
>  I tell it my rule is more specific or higher priority than the default rule?
>   For that matter, how can I figure out what rule is overriding mine? 
This is a similar el5 issue i encountered just yesterday and upto now i
havent found the cause and solution to the issue, other then setting the
file context manually with the chcon command.


>  Third, is there a useful guide for troubleshooting SELinux policy
> execution?
>   When things don't work as I expect them to, it's hard to find the reason if
>  it's not obvious from the audit.log. 
Examples?

It usually boils down to analyzing AVC denials.

>  
>  Finally, can anybody recommend a good book or other resource for learning
>  SELinux?  I have *SELinux by Example*, but it seems that conventions for
>  policy files have changed a great deal since it was written. 
Me and another guy had started to write a document about just that but
it just did not take off unfortunately, and now i am no longer sure if i
will have time for it in the future for it due to other responsibilities.

So i cannot recommend anything other then selinyxbyexample and the
actual reference policy source policy.

I will try however to answer any specific questions you may have.

>  Thanks!
>  
>  -----Scott.
>  
>  
>  
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0cSQcACgkQMlxVo39jgT+8DQCg1mQ4EqPeDcsn6+X1wRV/5Nyn
> o0wAn0U9ypYJFboq54HVJcbaA70jQVD1
> =rh62
> -----END PGP SIGNATURE-----

[Scott Gifford]

On Thu, Dec 30, 2010 at 3:55 AM, Dominick Grift <domg472(a)gmail.com&gt; wrote:

>  On 12/30/2010 08:27 AM, Scott Gifford wrote:
>
>  > I could write policy to allow mail_qmail_queue access to these httpd_t
>  > resources, but in general it should not have that access; only when it is
>  > run from Apache.  I could create a special type for "qmail-queue run from
>  > Apache", but that quickly gets out-of-hand if I create custom policies
>  for
>  > each program that sends mail.  What is the normal way to deal with these
>  > sorts of situations?
>
>  You can silently deny access vectors. So if you know that denying this
>  access does not cause any loss in functionality then consider silently
>  denying some of this. 

>  Anything else, i guess,  will just have to be allowed.
>  
I do want to allow them, so that errors and other output will end up
somewhere.

I'm having a hard time seeing how this process can be reasonably managed.
 It is probably impossible for me to predict in advance the types of all of
the things that could end up connected to the qmail-queue's filehandles.  A
message could be created in a temporary file and sent that way, or sent from
a pipe in a cronjob, etc.  Similarly its output could be sent to a temp
file, log file, etc.  There are hundreds of possible combinations that
should be allowed.  It seems that I would have to monitor the audit log,
carefully investigate exceptions, and modify the policy periodically.  But
this is very high-risk for mail, since a new combination of events that
triggers a new AVC denial and blocks the message could be some exceptional
event I want an email about, like smartd trying to send me a message saying
my hard drives are failing.

It seems like sendmail would have to deal with these same sorts of issues,
but I don't see anything in sendmail.if that seems to address them.

Is there some better way to manage this process or write policies that are a
bit more flexible, like a wildcard?  Or is some educated guesswork and
long-term monitoring of the AVC denials my only option?

Maybe it makes sense to run the mail server backend in unconfined_t?  That
seems risky in its own way.

[ ... ]

>  Third, is there a useful guide for troubleshooting SELinux policy
>  execution?
>  >  When things don't work as I expect them to, it's hard to find the reason
>  if
>  > it's not obvious from the audit.log.
>
>  Examples?
>
>  It usually boils down to analyzing AVC denials.
>  
I may be able to find what I need in the AVC logs.  I think I'm just not yet
confident enough that my policies work as they should, and it would be
reassuring to see the domain transitions as they run.

I have had some problems with failed assertions, which have far too little
debug information to troubleshoot them with anything but guesswork, but
that's probably a separate issue.

[ ... ]

>  I will try however to answer any specific questions you may have.
>  
Thanks, I appreciate your help and your offer of more help in the future!
 :-)

-----Scott.

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/31/2010 06:41 AM, Scott Gifford wrote:
>  On Thu, Dec 30, 2010 at 3:55 AM, Dominick Grift
> <domg472(a)gmail.com&gt; wrote:
>  
> >
> > On 12/30/2010 08:27 AM, Scott Gifford wrote:
> >
> >> I could write policy to allow mail_qmail_queue access to these httpd_t
> >> resources, but in general it should not have that access; only when it is
> >> run from Apache.  I could create a special type for "qmail-queue run from
> >> Apache", but that quickly gets out-of-hand if I create custom policies
> > for
> >> each program that sends mail.  What is the normal way to deal with these
> >> sorts of situations?
> >
> > You can silently deny access vectors. So if you know that denying this
> > access does not cause any loss in functionality then consider silently
> > denying some of this.
>  
>  
> > Anything else, i guess,  will just have to be allowed.
> >
>  
>  I do want to allow them, so that errors and other output will end up
>  somewhere.
>  
>  I'm having a hard time seeing how this process can be reasonably managed.
>   It is probably impossible for me to predict in advance the types of all of
>  the things that could end up connected to the qmail-queue's filehandles.  A
>  message could be created in a temporary file and sent that way, or sent from
>  a pipe in a cronjob, etc.  Similarly its output could be sent to a temp
>  file, log file, etc.  There are hundreds of possible combinations that
>  should be allowed.  It seems that I would have to monitor the audit log,
>  carefully investigate exceptions, and modify the policy periodically.  But
>  this is very high-risk for mail, since a new combination of events that
>  triggers a new AVC denial and blocks the message could be some exceptional
>  event I want an email about, like smartd trying to send me a message saying
>  my hard drives are failing.
>  
>  It seems like sendmail would have to deal with these same sorts of issues,
>  but I don't see anything in sendmail.if that seems to address them.
>  
>  Is there some better way to manage this process or write policies that are a
>  bit more flexible, like a wildcard?  Or is some educated guesswork and
>  long-term monitoring of the AVC denials my only option?
>  
>  Maybe it makes sense to run the mail server backend in unconfined_t?  That
>  seems risky in its own way. 
Why not use the mta module policy for your qmail other mtas also run in
this domain. i guess yoou could simply label qmail executable file
sendmail_exec_t?

The current mta policy probably has been tested well.

Or you could use that and other examples to get inspired for yuor own
policy (study how mta deals with similar issues)

>  [ ... ]
>  
>   > Third, is there a useful guide for troubleshooting SELinux policy
> > execution?
> >>  When things don't work as I expect them to, it's hard to find the
> reason
> > if
> >> it's not obvious from the audit.log.
> >
> > Examples?
> >
> > It usually boils down to analyzing AVC denials.
> >
>  
>  I may be able to find what I need in the AVC logs.  I think I'm just not yet
>  confident enough that my policies work as they should, and it would be
>  reassuring to see the domain transitions as they run. 
stuff only transitions if you tell it to transition.

you can also use sesearch to see where your domain is allowed to transition:

example:

sesearch --allow -SC -s ntpd_t -t domain -c process -p transition

<nothing resturned>

means that ntpd_t cannot domain transition

or:

sesearch --allow -SC -s staff_irssi_t -t domain -c process -p transition
 Found 1 semantic av rules:
    allow staff_irssi_t staff_t : process { transition sigchld } ;

means that staff_irss_t can transition to staff

then you can see what it can execute (file transitions happen on exec:

sesearch --allow -SC -s staff_irssi_t -t exec_type -c file -p execute
 Found 3 semantic av rules:
    allow staff_irssi_t bin_t : file { read getattr execute open } ;
    allow staff_irssi_t irssi_exec_t : file { ioctl read getattr lock
execute entrypoint open } ;
    allow staff_irssi_t shell_exec_t : file { read getattr execute open } ;

then you can narrow it down even further:

sesearch --allow -SC -s staff_irssi_t -t bin_t --type
 Found 3 semantic av rules:
    allow staff_irssi_t bin_t : file { read getattr execute open } ;
    allow staff_irssi_t bin_t : dir { ioctl read getattr lock search
open } ;
    allow staff_irssi_t bin_t : lnk_file { read getattr } ;

 Found 1 semantic te rules:
    type_transition staff_irssi_t bin_t : process staff_t;

Means that if staff_irssi_t runs a file with bin_t it transitions to
staff_t.

You could check this for irssi_exec_t, and shell_exec_t.


>  
>  I have had some problems with failed assertions, which have far too little
>  debug information to troubleshoot them with anything but guesswork, but
>  that's probably a separate issue. 
examples?

>  [ ... ]
>  
> > I will try however to answer any specific questions you may have.
> >
>  
>  Thanks, I appreciate your help and your offer of more help in the future!
>   :-)
>  
>  -----Scott.
>  
>  
>  
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0doAoACgkQMlxVo39jgT/SNwCgyyRMRVJhb1T7tg2jxy6DMZ/Z
> 5v0An2FB6UosUbAUb7Kykk3CL/eBIO29
> =8J1N
> -----END PGP SIGNATURE-----

[Scott Gifford]

On Fri, Dec 31, 2010 at 4:19 AM, Dominick Grift <domg472(a)gmail.com&gt; wrote:
[ ... ]

>   > Maybe it makes sense to run the mail server backend in
> unconfined_t?
>   That
>  > seems risky in its own way.
>
>  Why not use the mta module policy for your qmail other mtas also run in
>  this domain. i guess yoou could simply label qmail executable file
>  sendmail_exec_t?
>  
Thanks, that is a good idea, I tried it out and am not getting so many
warnings in my audit.log.  I am concerned they may just be suppressed
though; when I look at policies for system_mail_t by running:

sesearch -a -s system_mail_t


I see lines like this:

dontaudit system_mail_t httpd_t : file { ioctl read getattr lock };
dontaudit system_mail_t httpd_t : tcp_socket { read write };


Since I am currently running in permissive mode, those lines seem like they
would mask the problem without solving it.  Maybe I will need to set up a
dev server to test this.

[ ... ]

>  >  > Third, is there a useful guide for troubleshooting SELinux
> policy
>  >> execution?
>  >>>  When things don't work as I expect them to, it's hard to find the
>  reason
>  >> if
>  >>> it's not obvious from the audit.log.
>  >>
>  >> Examples?
>  >>
>  >> It usually boils down to analyzing AVC denials.
>  >>
>  >
>  > I may be able to find what I need in the AVC logs.  I think I'm just not
>  yet
>  > confident enough that my policies work as they should, and it would be
>  > reassuring to see the domain transitions as they run.
>
>  stuff only transitions if you tell it to transition.
>
>  you can also use sesearch to see where your domain is allowed to
>  transition:
>
>  example:
>
>  sesearch --allow -SC -s ntpd_t -t domain -c process -p transition
>  
Thanks, that is a great tool I did not know about!

So here then is an example I am not sure how to troubleshoot.

I don't understand how the mail backend is able to send messages without
generating AVC denials.  "ps -efZ" shows qmail-send, qmail's main backend
process, and qmail-rspawn, which handles remote messages, as running with
type "init_t".  That makes sense, since they are started by a sequence that
begins with init(8) and don't transition to any other context.  To send the
mail, it needs to read the configuration files, which are labeled
"etc_mail_t", and read and write queue files labeled "mqueue_spool_t".
 It
shouldn't have permission to do anything with those files:

$ sesearch -a -s init_t |egrep 'etc_mail|mqueue'
$


But somehow it does, or at least seems to to it without generating any AVC
denials.

Since this is succeeding, there's nothing in the audit.log, and from my own
inspection the contexts shouldn't allow this.  If I were programming I would
use a debugger or strace(1) to figure out exactly what is going on, but I'm
not sure if there is an equivalent tool here, or what my options are apart
from staring at the same information and hoping for insight.

 [ ... ]

>  > I have had some problems with failed assertions, which have far
> too
>  little
>  > debug information to troubleshoot them with anything but guesswork, but
>  > that's probably a separate issue.
>
>  examples?
>  
For example, early on in trying out a qmail policy, I forgot this line:

domain_type(mail_qmail_queue_t)

The policy compiled fine, but when I tried to load it I got these errors:

   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   mail_qmail_queue_t sendmail_t:process { sigchld };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   mail_qmail_queue_t httpd_sys_script_t:process { sigchld };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   mail_qmail_queue_t httpd_t:process { sigchld };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   mail_qmail_queue_t mail_qmail_queue_t:process { transition sigchld };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   mail_qmail_queue_t unconfined_t:process { sigchld };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   sendmail_t mail_qmail_queue_t:process { transition sigchld };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   httpd_sys_script_t mail_qmail_queue_t:process { transition sigchld };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   httpd_t mail_qmail_queue_t:process { transition sigchld };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   unconfined_t mail_qmail_queue_t:process { transition sigchld };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   sendmail_t mail_qmail_queue_t:process { transition };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   httpd_sys_script_t mail_qmail_queue_t:process { transition };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   httpd_t mail_qmail_queue_t:process { transition };
   - libsepol.check_assertion_helper: assertion on line 0 violated by allow
   unconfined_t mail_qmail_queue_t:process { transition };
   - libsepol.check_assertions: 13 assertion violations occured
   - libsemanage.semanage_expand_sandbox: Expand module failed
   - semodule:  Failed!

Eventually after staring at it awhile, a bit of googling, and some lucky
guesses I was able to figure it out.

Are there any tools or guidelines that can help with these sorts of things?

Thanks again for all of your help!

-----Scott.

[Dominick Grift]

On Sun, Jan 02, 2011 at 01:01:11AM -0500, Scott Gifford wrote:
>  On Fri, Dec 31, 2010 at 4:19 AM, Dominick Grift
> <domg472(a)gmail.com&gt; wrote:
>  [ ... ]
>  
>  >  > Maybe it makes sense to run the mail server backend in unconfined_t?
>  >  That
>  > > seems risky in its own way.
>  >
>  > Why not use the mta module policy for your qmail other mtas also run in
>  > this domain. i guess yoou could simply label qmail executable file
>  > sendmail_exec_t?
>  >
>  
>  Thanks, that is a good idea, I tried it out and am not getting so many
>  warnings in my audit.log.  I am concerned they may just be suppressed
>  though; when I look at policies for system_mail_t by running:
>  
>  sesearch -a -s system_mail_t
>  
>  
>  I see lines like this:
>  
>  dontaudit system_mail_t httpd_t : file { ioctl read getattr lock };
>  dontaudit system_mail_t httpd_t : tcp_socket { read write }; 
That is true. The dontaudit rules silently hide denials. This is usually done for good
reason. Hide bugs and/ or leaked file descriptors. You can however unload these hidden
denials by running "semodule -DB" This command will rebuild the policy with all
the "dontaudit" rules removed. You can re-insert the dontaudit rules by running
"semodule -B" 

>  
>  
>  Since I am currently running in permissive mode, those lines seem like they
>  would mask the problem without solving it.  Maybe I will need to set up a
>  dev server to test this. 
That may well be. Just build policy without the "dontaudits" to test, Do not
forget to re-insert the "dontaudits after you are done testing.

>  [ ... ]
>  
>  > >  > Third, is there a useful guide for troubleshooting SELinux policy
>  > >> execution?
>  > >>>  When things don't work as I expect them to, it's hard to find
> the
>  > reason
>  > >> if
>  > >>> it's not obvious from the audit.log.
>  > >>
>  > >> Examples?
>  > >>
>  > >> It usually boils down to analyzing AVC denials.
>  > >>
>  > >
>  > > I may be able to find what I need in the AVC logs.  I think I'm just not
>  > yet
>  > > confident enough that my policies work as they should, and it would be
>  > > reassuring to see the domain transitions as they run.
>  >
>  > stuff only transitions if you tell it to transition.
>  >
>  > you can also use sesearch to see where your domain is allowed to
>  > transition:
>  >
>  > example:
>  >
>  > sesearch --allow -SC -s ntpd_t -t domain -c process -p transition
>  >
>  
>  Thanks, that is a great tool I did not know about!
>  
>  So here then is an example I am not sure how to troubleshoot.
>  
>  I don't understand how the mail backend is able to send messages without
>  generating AVC denials.  "ps -efZ" shows qmail-send, qmail's main backend
>  process, and qmail-rspawn, which handles remote messages, as running with
>  type "init_t".  That makes sense, since they are started by a sequence that
>  begins with init(8) and don't transition to any other context.  To send the
>  mail, it needs to read the configuration files, which are labeled
>  "etc_mail_t", and read and write queue files labeled
> "mqueue_spool_t".  It
>  shouldn't have permission to do anything with those files:
>  
>  $ sesearch -a -s init_t |egrep 'etc_mail|mqueue'
>  $
>  
>  
>  But somehow it does, or at least seems to to it without generating any AVC
>  denials.
>  
>  Since this is succeeding, there's nothing in the audit.log, and from my own
>  inspection the contexts shouldn't allow this.  If I were programming I would
>  use a debugger or strace(1) to figure out exactly what is going on, but I'm
>  not sure if there is an equivalent tool here, or what my options are apart
>  from staring at the same information and hoping for insight.
>   
Welcome to the concept of attributes. Attribute are strings that group types. By grouping
types you can define policy that applies to a group of types instead of a single type.

you can see to what types a attribute is assigned with the seinfo command:

seinfo -x -adomain

You can also use sesearch and attributes

sesearch -SC --allow -s domain -t file_type

In your example above you are probably egrepping for the wrong things. Maybe any of the
types you were grepping for themselves arent allowed but attributes they have assigned
are.

>   [ ... ]
>  
>  > > I have had some problems with failed assertions, which have far too
>  > little
>  > > debug information to troubleshoot them with anything but guesswork, but
>  > > that's probably a separate issue.
>  >
>  > examples?
>  >
>  
>  For example, early on in trying out a qmail policy, I forgot this line:
>  
>  domain_type(mail_qmail_queue_t) 
Same idea. This interface assigns the domain attribute to the given parameter
(mail_qmail_queue_t).

policy is defined that applies to the domain attribute (all types that have the domain
attribute assigned)

This could such an related rule (not sure though:) (from
policy/modules/kernel/domain.te):

>  The policy compiled fine, but when I tried to load it I got these
> errors:
>  
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     mail_qmail_queue_t sendmail_t:process { sigchld }; 
neverallow ~{ domain unlabeled_t } *:process *;

basically it says that everything that is not a "domain" or unlabeled_t is not
allowed to interact with any process

And so if your mail_qmail_queue_t (which isnt a domain and neither unlabelled_t) tries to
send a chld singal to some "process" (sendmail:process) then there a violation
because theres a rule that says to never allow it. (basically a way to force you to use
the domain attribute.)

>     - libsepol.check_assertion_helper: assertion on line 0 violated by
> allow
>     mail_qmail_queue_t httpd_sys_script_t:process { sigchld };
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     mail_qmail_queue_t httpd_t:process { sigchld };
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     mail_qmail_queue_t mail_qmail_queue_t:process { transition sigchld };
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     mail_qmail_queue_t unconfined_t:process { sigchld };
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     sendmail_t mail_qmail_queue_t:process { transition sigchld };
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     httpd_sys_script_t mail_qmail_queue_t:process { transition sigchld };
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     httpd_t mail_qmail_queue_t:process { transition sigchld };
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     unconfined_t mail_qmail_queue_t:process { transition sigchld };
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     sendmail_t mail_qmail_queue_t:process { transition };
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     httpd_sys_script_t mail_qmail_queue_t:process { transition };
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     httpd_t mail_qmail_queue_t:process { transition };
>     - libsepol.check_assertion_helper: assertion on line 0 violated by allow
>     unconfined_t mail_qmail_queue_t:process { transition };
>     - libsepol.check_assertions: 13 assertion violations occured
>     - libsemanage.semanage_expand_sandbox: Expand module failed
>     - semodule:  Failed!
>  
>  Eventually after staring at it awhile, a bit of googling, and some lucky
>  guesses I was able to figure it out. 
I above explained the concept of attributes. we discussed the dontaudit statement and i
quickly showed you the neverallow statement. These are pretty important concepts. 

Try to understand these by keeping in mind what i said, and studying the reference polic
source policy. See if you can translate some of what i showed above into some thing that
makes sense by stuying the actual policy.

And ofcourse if anything is not clear feel free to ask for clarification.

>  Are there any tools or guidelines that can help with these sorts of
> things?
>  
>  Thanks again for all of your help!
>  
>  -----Scott.

[Scott Gifford]

On Sun, Jan 2, 2011 at 5:08 AM, Dominick Grift <domg472(a)gmail.com&gt; wrote:
[ ... ]

>  Try to understand these by keeping in mind what i said, and studying
> the
>  reference polic source policy. See if you can translate some of what i
>  showed above into some thing that makes sense by stuying the actual policy.
>
>  And ofcourse if anything is not clear feel free to ask for clarification.
>  
Thanks for the help and excellent advice.  I'm going to spend a little more
time learning and experimenting before I take another crack at policy
writing.  In the meantime I'll keep my eye on the list and see what I can
learn, and I'll be back with questions soon.  :)

-----Scott.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/30/2010 03:55 AM, Dominick Grift wrote:
>  On 12/30/2010 08:27 AM, Scott Gifford wrote:
> > Hello,
>  
> > I'm having some trouble with an SELinux policy to allow sending mail from a
> > PHP script run from our Web server with a local installation of qmail on a
> > CentOS 5 system.  We send mail using php's mail() function, which calls
> > /usr/bin/sendmail, which in turn calls /var/qmail/bin/qmail-inject, then
> > /var/qmail/bin/qmail-queue, which actually puts the message in the queue.
>  
> > SELinux comes with some default qmail policies, but out-of-the-box we had
> > AVC denials when qmail-queue would try to write the message into the queue,
> > since the Web script context was not permitted to do this.
>  
> > I decided to take this opportunity to learn about writing SELinux policies.
> >  I know qmail very well, so thought I would write a policy for qmail.  The
> > policy would transition to a new type mail_qmail_queue_t when qmail-queue
> > was run, and then allow this type to write into the queue.
>  
> > I think I have the basics working, but I'm running into some snags, and I
> > don't have enough experience to know what sorts of solutions are likely to
> > work out.
>  
> > First, I am seeing some denials that seem to be related to file descriptors
> > passed by Apache to qmail-queue.  When qmail-queue is run, stderr is
> > connected to the Web server log, and stdout is connected to the HTTP socket.
> >  This is a pretty normal setup, which will cause any output to show up in
> > the user's browser and errors to show up in the Web server log.  However I
> > get these AVC denials:
>  
> >    - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
> >     denied  { read } for  pid=9643 comm="qmail-queue"
> path="pipe:[4937510]"
> >    dev=pipefs ino=4937510 scontext=system_u:system_r:mail_qmail_queue_t:s0
> >    tcontext=system_u:system_r:httpd_t:s0 tclass=fifo_file
> >    - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
> >     denied  { append } for  pid=9643 comm="qmail-queue"
> >    path="/var/log/httpd/error_log" dev=md2 ino=24183170
> >    scontext=system_u:system_r:mail_qmail_queue_t:s0
> >    tcontext=user_u:object_r:httpd_log_t:s0 tclass=file
> >    - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
> >     denied  { read write } for  pid=9643 comm="qmail-queue"
> >    path="socket:[13964]" dev=sockfs ino=13964
> >    scontext=system_u:system_r:mail_qmail_queue_t:s0
> >    tcontext=system_u:system_r:httpd_t:s0 tclass=tcp_socket
>  
> > I could write policy to allow mail_qmail_queue access to these httpd_t
> > resources, but in general it should not have that access; only when it is
> > run from Apache.  I could create a special type for "qmail-queue run from
> > Apache", but that quickly gets out-of-hand if I create custom policies for
> > each program that sends mail.  What is the normal way to deal with these
> > sorts of situations?
>  
>  You can silently deny access vectors. So if you know that denying this
>  access does not cause any loss in functionality then consider silently
>  denying some of this.
>  
>  Anything else, i guess,  will just have to be allowed.
>   
In RHEL6 you can allow this via inheritence.  IE Deny the open rule.  So
you tool could append to the httpd_log_t but not open it.
> > Second, I am having some trouble getting file contexts set up.  I
> have
> > several qmail installations with different policies, so I wrote a rule in my
> > fc file like this:
>  
> > /var/qmail(-.*)?/bin/qmail-queue --
> > gen_context(system_u:object_r:mail_qmail_queue_exec_t,s0)
>  
>  
> > When I use that rule, qmail-queue gets labeled bin_t, I think because of
> > another rule saying anything in a directory named "bin" is
> "bin_t".  How can
> > I tell it my rule is more specific or higher priority than the default rule?
> >  For that matter, how can I figure out what rule is overriding mine?
>  
>  This is a similar el5 issue i encountered just yesterday and upto now i
>  havent found the cause and solution to the issue, other then setting the
>  file context manually with the chcon command.
>   
The rules for file context come down to specifity.  I would search for
rules about /var.*bin_t And see which rule is being matched.  one trick
is that if your rule is longer it will get chosen.

On F15 I see

grep /var.*bin_t /etc/selinux/targeted/contexts/files/file_contexts
/var/ftp/bin(/.*)?	system_u:object_r:bin_t:s0
/var/qmail/bin(/.*)?	system_u:object_r:bin_t:s0
/var/mailman/bin(/.*)?	system_u:object_r:bin_t:s0
/var/lib/asterisk/agi-bin(/.*)?	system_u:object_r:bin_t:s0
/var/qmail/rc	--	system_u:object_r:bin_t:s0
/var/qmail/bin	-d	system_u:object_r:bin_t:s0


Not sure what you have on RHEL5.

>  
> > Third, is there a useful guide for troubleshooting SELinux policy execution?
> >  When things don't work as I expect them to, it's hard to find the reason if
> > it's not obvious from the audit.log.
>  
>  Examples?
>  
>  It usually boils down to analyzing AVC denials.
>  
>  
> > Finally, can anybody recommend a good book or other resource for learning
> > SELinux?  I have *SELinux by Example*, but it seems that conventions for
> > policy files have changed a great deal since it was written.
>  
>  Me and another guy had started to write a document about just that but
>  it just did not take off unfortunately, and now i am no longer sure if i
>  will have time for it in the future for it due to other responsibilities.
>  
>  So i cannot recommend anything other then selinyxbyexample and the
>  actual reference policy source policy.
>  
>  I will try however to answer any specific questions you may have.
>  
> > Thanks!
>  
> > -----Scott.
>  
>   

>  
>  
> > --
> > selinux mailing list
> > selinux(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
- --
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0iSy0ACgkQrlYvE4MpobO9+wCfUnItW/A3sjAkgppuvkbbBUAv
> WOsAoIoGgsUl5t0LtvXK/6OBOOj6+eSo
> =m5ie
> -----END PGP SIGNATURE-----