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.