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.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
