So just where is procmail_t allowed to write/create/rename etc?

[Robert Nichols]

Actually, let me ask that another way.  How should I go about finding
the contexts where procmail_t is allowed to create/delete/rename files?
I'm getting a flood of AVCs like the ones below and need to figure out
an appropriate context for some directories that, FWIW, are deep down
under /srv.


node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  { 
write } for  pid=3017 comm="decode64" name="Received-0305" dev=sda8
ino=7442469 
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0 
tclass=dir

node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  { 
add_name } for  pid=3017 comm="decode64" name="jARhqK" 
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0 
tclass=dir

node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  { 
create } for  pid=3017 comm="decode64" name="jARhqK" 
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0 
tclass=file

node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  { 
read write open } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8

ino=5347353 scontext=system_u:system_r:procmail_t:s0 
tcontext=system_u:object_r:var_t:s0 tclass=file

node=omega-3x.local type=AVC msg=audit(1267778517.645:30181): avc:  denied  { 
setattr } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
ino=5347353 
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0 
tclass=file

node=omega-3x.local type=AVC msg=audit(1267778517.725:30183): avc:  denied  { 
link } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
ino=5347353 
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0 
tclass=file

node=omega-3x.local type=AVC msg=audit(1267778517.726:30184): avc:  denied  { 
remove_name } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
ino=5347353 
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0 
tclass=dir

node=omega-3x.local type=AVC msg=audit(1267778517.726:30184): avc:  denied  { 
unlink } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
ino=5347353 
scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0 
tclass=file

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

[Daniel J Walsh]

On 03/05/2010 01:04 PM, Robert Nichols wrote:
>  Actually, let me ask that another way.  How should I go about
> finding
>  the contexts where procmail_t is allowed to create/delete/rename files?
>  I'm getting a flood of AVCs like the ones below and need to figure out
>  an appropriate context for some directories that, FWIW, are deep down
>  under /srv.
>
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
>  write } for  pid=3017 comm="decode64" name="Received-0305" dev=sda8
> ino=7442469
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=dir
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
>  add_name } for  pid=3017 comm="decode64" name="jARhqK"
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=dir
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
>  create } for  pid=3017 comm="decode64" name="jARhqK"
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=file
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
>  read write open } for  pid=3017 comm="decode64" name="jARhqK"
> dev=sda8
>  ino=5347353 scontext=system_u:system_r:procmail_t:s0
>  tcontext=system_u:object_r:var_t:s0 tclass=file
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.645:30181): avc:  denied  {
>  setattr } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
> ino=5347353
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=file
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.725:30183): avc:  denied  {
>  link } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
> ino=5347353
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=file
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.726:30184): avc:  denied  {
>  remove_name } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
> ino=5347353
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=dir
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.726:30184): avc:  denied  {
>  unlink } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
> ino=5347353
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=file
>
>      
sesearch -A -s procmail_t -c file -p write
Found 8 semantic av rules:
    allow procmail_t user_home_t : file { ioctl read write create 
getattr setattr lock append unlink link rename open } ;
    allow procmail_t procmail_t : file { ioctl read write getattr lock 
append open } ;
    allow procmail_t anon_inodefs_t : file { ioctl read write getattr 
lock append open } ;
    allow domain afs_cache_t : file { read write } ;
    allow procmail_t procmail_tmp_t : file { ioctl read write create 
getattr setattr lock append unlink link rename open } ;
    allow procmail_t mail_spool_t : file { ioctl read write create 
getattr setattr lock append unlink link rename open } ;
    allow procmail_t cifs_t : file { ioctl read write create getattr 
setattr lock append unlink link rename open } ;
    allow procmail_t nfs_t : file { ioctl read write create getattr 
setattr lock append unlink link rename open } ;



Did setroubleshoot tell you something like this?

[Dominick Grift]

On 03/05/2010 07:04 PM, Robert Nichols wrote:
>  Actually, let me ask that another way.  How should I go about
> finding
>  the contexts where procmail_t is allowed to create/delete/rename files?
>  I'm getting a flood of AVCs like the ones below and need to figure out
>  an appropriate context for some directories that, FWIW, are deep down
>  under /srv. 
# sesearch --allow -s procmail_t -c file -p create
Found 6 semantic av rules:
   allow procmail_t procmail_log_t : file { ioctl create getattr lock
append open } ;
   allow procmail_t procmail_tmp_t : file { ioctl read write create
getattr setattr lock append unlink link rename open } ;
   allow procmail_t mail_spool_t : file { ioctl read write create
getattr setattr lock append unlink link rename open } ;
   allow procmail_t user_home_t : file { ioctl read write create getattr
setattr lock append unlink link rename open } ;
   allow procmail_t cifs_t : file { ioctl read write create getattr
setattr lock append unlink link rename open } ;
   allow procmail_t nfs_t : file { ioctl read write create getattr
setattr lock append unlink link rename open } ;

Try /tmp.

[Dan Thurman]

On 03/05/2010 10:04 AM, Robert Nichols wrote:
>  Actually, let me ask that another way.  How should I go about
> finding
>  the contexts where procmail_t is allowed to create/delete/rename files?
>  I'm getting a flood of AVCs like the ones below and need to figure out
>  an appropriate context for some directories that, FWIW, are deep down
>  under /srv.
>
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
>  write } for  pid=3017 comm="decode64" name="Received-0305" dev=sda8
> ino=7442469
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=dir
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
>  add_name } for  pid=3017 comm="decode64" name="jARhqK"
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=dir
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
>  create } for  pid=3017 comm="decode64" name="jARhqK"
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=file
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
>  read write open } for  pid=3017 comm="decode64" name="jARhqK"
> dev=sda8
>  ino=5347353 scontext=system_u:system_r:procmail_t:s0
>  tcontext=system_u:object_r:var_t:s0 tclass=file
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.645:30181): avc:  denied  {
>  setattr } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
> ino=5347353
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=file
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.725:30183): avc:  denied  {
>  link } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
> ino=5347353
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=file
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.726:30184): avc:  denied  {
>  remove_name } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
> ino=5347353
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=dir
>
>  node=omega-3x.local type=AVC msg=audit(1267778517.726:30184): avc:  denied  {
>  unlink } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
> ino=5347353
>  scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
>  tclass=fil 
I get all sorts of procmail selinux issues (not to hijack this thread, 
but might
be related?).  Here is one of many:

=================================================

Summary:

SELinux is preventing /usr/bin/procmail "write" access on /var/spool/mqueue.

Detailed Description:

SELinux denied access requested by procmail. It is not expected that 
this access
is required by procmail and this access may signal an intrusion attempt. 
It is
also possible that the specific version or configuration of the 
application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context                system_u:system_r:procmail_t:s0
Target Context                system_u:object_r:mqueue_spool_t:s0
Target Objects                /var/spool/mqueue [ dir ]
Source                        procmail
Source Path                   /usr/bin/procmail
Port <Unknown>
Host                          host.domain.com
Source RPM Packages           procmail-3.22-25.fc12
Target RPM Packages           sendmail-8.14.3-8.fc12
Policy RPM                    selinux-policy-3.6.32-89.fc12
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     host.domain.com
Platform                      Linux host.domain.com 
2.6.31.12-174.2.22.fc12.i686
                               #1 SMP Fri Feb 19 19:26:06 UTC 2010 i686 i686
Alert Count                   9
First Seen                    Tue 02 Mar 2010 03:12:16 AM PST
Last Seen                     Tue 02 Mar 2010 05:13:03 AM PST
Local ID                      5c68ab75-d7e0-4e2d-b380-857eb7e33c68
Line Numbers

Raw Audit Messages

node=host.domain.com type=AVC msg=audit(1267535583.841:38780): avc: 
denied  { write } for  pid=12554 comm="procmail" name="mqueue"
dev=sdb8 
ino=29627 scontext=system_u:system_r:procmail_t:s0 
tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=dir

node=host.domain.com type=SYSCALL msg=audit(1267535583.841:38780): 
arch=40000003 syscall=5 success=no exit=-13 a0=92f6d68 a1=8441 a2=1b7 
a3=1b7 items=0 ppid=12553 pid=12554 auid=4294967295 uid=0 gid=12 euid=0 
suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none) ses=4294967295 
comm="procmail" exe="/usr/bin/procmail" 
subj=system_u:system_r:procmail_t:s0 key=(null)

[Dominick Grift]

On 03/05/2010 07:20 PM, Daniel B. Thurman wrote:

>  I get all sorts of procmail selinux issues (not to hijack this
> thread, 
>  but might
>  be related?).  Here is one of many: 
This indicates to me that procmail may want to create objects in the
mqueue directory.

Can you reproduce this? Would be even better if you could do in
permissive mode so that we can see what else it wants.

We know it wants to write to the mqueue dir, question is: for what
purpose. Does it want to create something there and why?

>  =================================================
>  
>  Summary:
>  
>  SELinux is preventing /usr/bin/procmail "write" access on /var/spool/mqueue.
>  
>  Detailed Description:
>  
>  SELinux denied access requested by procmail. It is not expected that 
>  this access
>  is required by procmail and this access may signal an intrusion attempt. 
>  It is
>  also possible that the specific version or configuration of the 
>  application is
>  causing it to require additional access.
>  
>  Allowing Access:
>  
>  You can generate a local policy module to allow this access - see FAQ
>  (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
>  report.
>  
>  Additional Information:
>  
>  Source Context                system_u:system_r:procmail_t:s0
>  Target Context                system_u:object_r:mqueue_spool_t:s0
>  Target Objects                /var/spool/mqueue [ dir ]
>  Source                        procmail
>  Source Path                   /usr/bin/procmail
>  Port <Unknown>
>  Host                          host.domain.com
>  Source RPM Packages           procmail-3.22-25.fc12
>  Target RPM Packages           sendmail-8.14.3-8.fc12
>  Policy RPM                    selinux-policy-3.6.32-89.fc12
>  Selinux Enabled               True
>  Policy Type                   targeted
>  Enforcing Mode                Enforcing
>  Plugin Name                   catchall
>  Host Name                     host.domain.com
>  Platform                      Linux host.domain.com 
>  2.6.31.12-174.2.22.fc12.i686
>                                 #1 SMP Fri Feb 19 19:26:06 UTC 2010 i686 i686
>  Alert Count                   9
>  First Seen                    Tue 02 Mar 2010 03:12:16 AM PST
>  Last Seen                     Tue 02 Mar 2010 05:13:03 AM PST
>  Local ID                      5c68ab75-d7e0-4e2d-b380-857eb7e33c68
>  Line Numbers
>  
>  Raw Audit Messages
>  
>  node=host.domain.com type=AVC msg=audit(1267535583.841:38780): avc: 
>  denied  { write } for  pid=12554 comm="procmail" name="mqueue"
> dev=sdb8 
>  ino=29627 scontext=system_u:system_r:procmail_t:s0 
>  tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=dir
>  
>  node=host.domain.com type=SYSCALL msg=audit(1267535583.841:38780): 
>  arch=40000003 syscall=5 success=no exit=-13 a0=92f6d68 a1=8441 a2=1b7 
>  a3=1b7 items=0 ppid=12553 pid=12554 auid=4294967295 uid=0 gid=12 euid=0 
>  suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none) ses=4294967295 
>  comm="procmail" exe="/usr/bin/procmail" 
>  subj=system_u:system_r:procmail_t:s0 key=(null)
>  
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Robert Nichols]

On 03/05/2010 12:07 PM, Dominick Grift wrote:
>  On 03/05/2010 07:04 PM, Robert Nichols wrote:
> > Actually, let me ask that another way.  How should I go about finding
> > the contexts where procmail_t is allowed to create/delete/rename files?
> > I'm getting a flood of AVCs like the ones below and need to figure out
> > an appropriate context for some directories that, FWIW, are deep down
> > under /srv.
>
>  # sesearch --allow -s procmail_t -c file -p create
>  Found 6 semantic av rules:
>      allow procmail_t procmail_log_t : file { ioctl create getattr lock
>  append open } ;
>      allow procmail_t procmail_tmp_t : file { ioctl read write create
>  getattr setattr lock append unlink link rename open } ;
>      allow procmail_t mail_spool_t : file { ioctl read write create
>  getattr setattr lock append unlink link rename open } ;
>      allow procmail_t user_home_t : file { ioctl read write create getattr
>  setattr lock append unlink link rename open } ;
>      allow procmail_t cifs_t : file { ioctl read write create getattr
>  setattr lock append unlink link rename open } ;
>      allow procmail_t nfs_t : file { ioctl read write create getattr
>  setattr lock append unlink link rename open } ;
>
>  Try /tmp. 
Wrong answer.  Those files are not moving.  Nor are they going to
labeled tmp_t.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

[Dominick Grift]

On 03/05/2010 07:26 PM, Robert Nichols wrote:

>  Wrong answer.  Those files are not moving.  Nor are they going to
>  labeled tmp_t.
>   
I do not know the specific path but assuming:

/srv/mymail

than you could for example try to label the mymail directory with type
mail_spool_t:

semanage fcontext -a -t mail_spool_t "/srv/mymail(/.*)?"
restorecon -R -v /srv/mymail

That should allow procmail_t to create files and dirs in /srv/mymail.

Assuming that it has access to search type var_t dirs (/srv), which i
think it does:

sesearch --allow -s procmail_t -t var_t -c dir -p search
Found 5 semantic av rules:
   allow procmail_t var_t : dir { getattr search open } ;
   allow domain var_t : dir { getattr search open } ;
   allow procmail_t var_t : dir { getattr search open } ;
   allow procmail_t var_t : dir { getattr search open } ;
   allow procmail_t var_t : dir { getattr search open } ;

[Robert Nichols]

On 03/05/2010 12:06 PM, Daniel J Walsh wrote:
>  On 03/05/2010 01:04 PM, Robert Nichols wrote:
> > Actually, let me ask that another way.  How should I go about finding
> > the contexts where procmail_t is allowed to create/delete/rename files?
> > I'm getting a flood of AVCs like the ones below and need to figure out
> > an appropriate context for some directories that, FWIW, are deep down
> > under /srv.
> >
> >
> > node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
> > write } for  pid=3017 comm="decode64" name="Received-0305"
> dev=sda8 ino=7442469
> > scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
> > tclass=dir
> >
> > node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
> > add_name } for  pid=3017 comm="decode64" name="jARhqK"
> > scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
> > tclass=dir
> >
> > node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
> > create } for  pid=3017 comm="decode64" name="jARhqK"
> > scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
> > tclass=file
> >
> > node=omega-3x.local type=AVC msg=audit(1267778517.644:30180): avc:  denied  {
> > read write open } for  pid=3017 comm="decode64" name="jARhqK"
> dev=sda8
> > ino=5347353 scontext=system_u:system_r:procmail_t:s0
> > tcontext=system_u:object_r:var_t:s0 tclass=file
> >
> > node=omega-3x.local type=AVC msg=audit(1267778517.645:30181): avc:  denied  {
> > setattr } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
> ino=5347353
> > scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
> > tclass=file
> >
> > node=omega-3x.local type=AVC msg=audit(1267778517.725:30183): avc:  denied  {
> > link } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
> ino=5347353
> > scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
> > tclass=file
> >
> > node=omega-3x.local type=AVC msg=audit(1267778517.726:30184): avc:  denied  {
> > remove_name } for  pid=3017 comm="decode64" name="jARhqK"
> dev=sda8 ino=5347353
> > scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
> > tclass=dir
> >
> > node=omega-3x.local type=AVC msg=audit(1267778517.726:30184): avc:  denied  {
> > unlink } for  pid=3017 comm="decode64" name="jARhqK" dev=sda8
> ino=5347353
> > scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:var_t:s0
> > tclass=file
> >
> >
>  sesearch -A -s procmail_t -c file -p write
>  Found 8 semantic av rules:
>       allow procmail_t user_home_t : file { ioctl read write create
>  getattr setattr lock append unlink link rename open } ;
>       allow procmail_t procmail_t : file { ioctl read write getattr lock
>  append open } ;
>       allow procmail_t anon_inodefs_t : file { ioctl read write getattr
>  lock append open } ;
>       allow domain afs_cache_t : file { read write } ;
>       allow procmail_t procmail_tmp_t : file { ioctl read write create
>  getattr setattr lock append unlink link rename open } ;
>       allow procmail_t mail_spool_t : file { ioctl read write create
>  getattr setattr lock append unlink link rename open } ;
>       allow procmail_t cifs_t : file { ioctl read write create getattr
>  setattr lock append unlink link rename open } ;
>       allow procmail_t nfs_t : file { ioctl read write create getattr
>  setattr lock append unlink link rename open } ;
>
>
>
>  Did setroubleshoot tell you something like this? 
-bash: setroubleshoot: command not found
The popup from setroubleshootd has been dismissed and there is no
apparent way to get it back until the next violation.

The display from "sealert -s" just refers me to the FAQ.

The only type that looks vaguely appropriate from your list above is
mail_spool_t.  I'll give that a try for the parent of the
"Received-mmdd" directories.  Opening up that parent directory seems
wrong, but since the "Received-mmdd" subdirectories get created on
demand I don't have much choice without getting deeper into policy
writing than I am comfortable with.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.