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

[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.