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

On 03/04/2010 11:52 PM, Chuck Anderson wrote:
> On Thu, Mar 04, 2010 at 09:29:14PM -0600, Robert Nichols wrote:
>> And, it appears that I have to remember to re-install all local policy
>> modules every time there is a policy update, right?? :-((
>
> I don't have either of these problems, and I've been using procmail on
> (admittedly older) Fedora for years.

I think I know what happened to make it appear that the local policy
module got dropped. A simple mistake on my part that just happened to
occur at the time an update got installed.

As for the execute permission problem, you probably aren't executing any
user-written scripts from within your home directory. In fact, I know
you're not -- SELinux won't allow that.

I'm once again finding SELinux to be absolutely hopeless, and I'm barely
getting started with the things I want this system to do. Right now I'm
trying to set up my mail processing. I do quite a bit of processing on
my personal incoming mail. Messages get classified (partly by that awk
filter that prompted this thread), and then processed in a variety of
ways. Files get decoded and stored where I want them. Processes get
started to evaluate incoming data based on information in a local
database. That sort of thing. SELinux wants to block all of that. The
only alternative I can see is to start a continuously running background
process that runs audit2allow on every AVC that shows up in the log and
let that continue for a few months, and I probably still won't dare go
into enforcing mode for fear that some rare but important event will
cause yet another denial and leave me with a mess to clean up.

SELinux works well and unobtrusively if you use only the software that
comes with your distribution and don't go much beyond clicking on icons
in your use of it. My laptop falls into that category. I'm trying to
bring up a server right now, where SELinux would actually be useful,
but dealing with SELinux there is looking to be way beyond what I can
undertake.

--
Bob Nichols RNichols42@comcast.net
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

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

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?


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

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

On 05/03/10 13:55, Robert Nichols wrote:
> On 03/05/2010 03:09 AM, Dominick Grift wrote:
>> On 03/05/2010 04:29 AM, Robert Nichols wrote:
>>> And, it appears that I have to remember to re-install all local policy
>>> modules every time there is a policy update, right?? :-((
>>
>> Not in all cases but in the case where user domains are involved that
>> may be true. semodule -B may also do the trick.
>>
>> It may be a better idea to label /var/home/rnichols/mail/spamstrings.sh
>> type bin_t
>>
>> semanage fcontext -a -t bin_t /var/home/rnichols/mail/spamstrings.sh
>> restorecon -R -v /var/home/rnichols/mail/spamstrings.sh
>
> So, if I move that file to my $HOME/bin directory and make that whole
> directory type bin_t, that should take care of it??

Should do. In fact I have a local policy module that makes all user home
directories bin_t:

localmisc.fc:
# Need to be able to run scripts from procmail, cron etc.
HOME_DIR/bin(/.*)? gen_context(unconfined_u:object_r:bin_t,s0)

Paul.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

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

On 03/05/2010 08:38 AM, Robert Nichols wrote:
> SELinux works well and unobtrusively if you use only the software that
> comes with your distribution and don't go much beyond clicking on icons
> in your use of it. My laptop falls into that category. I'm trying to
> bring up a server right now, where SELinux would actually be useful,
> but dealing with SELinux there is looking to be way beyond what I can
> undertake.
>

That is because the user domain by default is for the most part exempt.
Some system services are targeted, and managing this requires some
knowledge/awareness about the matter.

Its like Fedora default iptables/netfilter configuration. As long as you
do not have any exotic services listening on the network or have any
nat/routing requirements, things just work.

Else you are required to have some knowledge about iptables or whatever
you use to configure netfilter.

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

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

Yes I think labeling the bin directory in your homedir as bin_t will
allow almost all confined applications on your system to execute them.

The problem with SELinux is people think first of adding allow rules
rather then fixing the labeling.
In this case you want to treat files in your homedir as binraries that
system processes can execute, so you can need to label them bin_t. If
you set up ~/bin to be labeled bin_t, all files copied to that directory
or created in that directory will be labeled bin_t. If you mv a file to
this directory you might have to run restorecon on it. restorecon -R -v
~/bin

procmail_t can currently write to your home dir, so this should not be a
problem.

You can set the labeling of ~/bin to bin_t using the method Paul Howarth
suggested or just use the semanage command


# semanage fcontext -a -t bin_t '/home/rnichols/bin(/.*)?'
# restorecon -R -v /home/rnichols/bin

If you do not want to change the labeling at all you can use the
audit2allow method you first described
# grep procmail_t /var/log/audit/audit.log | audit2allow -M myprocmail
# semodule -i myprocmail.pp

Which would then allow procmail_t to execute user_home_t.

This rules says procmail_t can execute almost any file in your homedir,
since this is the default label for the homedir. You should not have to
add more rules to handle this problem.

http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf

This docment explains the four things SELinux is trying to tell you.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

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

On 05/03/10 14:16, Stephen Smalley wrote:
> On Fri, 2010-03-05 at 15:04 +0100, Dominick Grift wrote:
>> On 03/05/2010 02:53 PM, Stephen Smalley wrote:
>>> On Fri, 2010-03-05 at 10:09 +0100, Dominick Grift wrote:
>>>> On 03/05/2010 04:29 AM, Robert Nichols wrote:
>>>>> And, it appears that I have to remember to re-install all local policy
>>>>> modules every time there is a policy update, right?? :-((
>>>>
>>>> Not in all cases but in the case where user domains are involved that
>>>> may be true. semodule -B may also do the trick.
>>>
>>> What's an example where that is required, and why?
>>>
>>
>> Well i dont remember exactly but i use to have a custom user domain, and
>> when fedora's selinux-policy had an update that affected interfaces in
>> the userdomain, that my custom user domain calls. Then this change would
>> not reflect in my custom user domain.
>>
>> I had to reinstall my custom user domain after fedora selinux policy
>> updates that made relevant changes to the userdomain.
>>
>> I think the explanation was that its works like static libraries and not
>> like dynamic libraries.
>
> Ah, yes - refpolicy interfaces are merely m4 macros presently and thus
> are expanded at module compilation time. So if your module uses a
> refpolicy interface and the internals of that interface definition
> change and you want to pick up those changes, you might have to
> recompile your module (merely re-inserting the already compiled one or
> merely running semodule -B won't help). But I don't think that is
> commonly needed for local modules, particularly ones that are
> audit2allow-generated.

I had an issue with this last week, where the update from -89 to -92 on
Fedora 12 appeared to remove the "etcfile" attribute, an "ABI change"
that broke at least two of my local modules despite there being no "API
change" (a recompile of the modules worked without problems).

These were hand-written modules as it happens but the problem could as
easily come up for people using "audit2allow -R", which is what I
usually do.

The full details are a bit long-winded to post here but I documented my
experience in the hope it would prove useful to someone:

http://www.city-fan.org/tips/PaulHowarth/Blog/2010-03-04

Cheers, Paul.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux