SELinux is preventing /bin/gawk "execute" access on /var/home/rnichols/mail/spamstrings.awk

[Robert Nichols]

On 03/05/2010 07:48 AM, Daniel J Walsh wrote:
> On 03/04/2010 10:25 PM, Robert Nichols wrote:
>> This occurs as the result of a procmail rule.  Hopefully, the result
>> from audit2allow is the right thing here:
>>
>>         allow procmail_t user_home_t:file execute_no_trans;
>>
>> Am I going to have to jump through SELinux hoops every time I want to use
>> a bit of my own code???  Right now I'm spending far more time fighting
>> with SELinux than I would _ever_ have to spend cleaning up from an
>> unlikely breakin.  With little hope of ever getting to enforcing mode,
>> perhaps it would be best just to disable entirely.
>>
>> Summary:
>>
>> SELinux is preventing /bin/gawk "execute" access on
>> /var/home/rnichols/mail/spamstrings.sh.
>>
>> Detailed Description:
>>
>> [SELinux is in permissive mode. This access was not denied.]
>>
>> SELinux denied access requested by spamstrings.sh. It is not expected that this
>> access is required by spamstrings.sh 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                unconfined_u:object_r:user_home_t:s0
>> Target Objects                /var/home/rnichols/mail/spamstrings.sh [ file ]
>> Source                        spamstrings.sh
>> Source Path                   /bin/gawk
>> Port<Unknown>
>> Host                          omega-3x.local
>> Source RPM Packages           gawk-3.1.7-1.fc12
>> Target RPM Packages
>> Policy RPM                    selinux-policy-3.6.32-89.fc12
>> Selinux Enabled               True
>> Policy Type                   targeted
>> Enforcing Mode                Permissive
>> Plugin Name                   catchall
>> Host Name                     omega-3x.local
>> Platform                      Linux omega-3x.local
>>                                  2.6.31.12-174.2.22.fc12.x86_64 #1 SMP Fri Feb 19
>>                                  18:55:03 UTC 2010 x86_64 x86_64
>> Alert Count                   2
>> First Seen                    Thu 04 Mar 2010 08:49:24 PM CST
>> Last Seen                     Thu 04 Mar 2010 08:49:24 PM CST
>> Local ID                      d067376f-66e5-49b7-8fa7-e22aa5388dae
>> Line Numbers
>>
>> Raw Audit Messages
>>
>> node=omega-3x.local type=AVC msg=audit(1267757364.768:30045): avc:  denied  {
>> execute } for  pid=19477 comm="procmail" name="spamstrings.sh" dev=sda6
>> ino=351952 scontext=system_u:system_r:procmail_t:s0
>> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
>>
>> node=omega-3x.local type=AVC msg=audit(1267757364.768:30045): avc:  denied  {
>> execute_no_trans } for  pid=19477 comm="procmail"
>> path="/home/rnichols/mail/spamstrings.sh" dev=sda6 ino=351952
>> scontext=system_u:system_r:procmail_t:s0
>> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
>>
>> node=omega-3x.local type=SYSCALL msg=audit(1267757364.768:30045): arch=c000003e
>> syscall=59 success=yes exit=0 a0=95e320 a1=95fa40 a2=95fee0 a3=8 items=0
>> ppid=19476 pid=19477 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500
>> egid=500 sgid=500 fsgid=500 tty=(none) ses=4294967295 comm="spamstrings.sh"
>> exe="/bin/gawk" subj=system_u:system_r:procmail_t:s0 key=(null)
>>
>>
>>
>>
>>
> Simplest fix would be to change the context to bin_t
>
> chcon -t bin_t /home/rnichols/mail/spamstrings.sh
>
>
> Will make this work.   Is this a normal behavour to have procmail
> executing content in the homedir?

If the user's .procmailrc file asks for such execution, then yes, completely
normal.

I can see I have a huge administrative nightmare coming up if I want to keep
SELinux enabled.  Where I have executables that are related only to specific
groups of files, I prefer to keep the executable content grouped with the
files rather than lumping all those executables in my $HOME/bin directory.
Some of those programs are going to be invoked by confined services.  So,
I'm going to have multiple pigeonholes for which I need to set bin_t context
and have to keep track of that if stuff gets moved around.  And most likely
all of that is going to break horribly when the next major upgrade (FC12 ->
FC13) comes along.

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