9:25 p.m.
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)
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
9:29 p.m.
And, it appears that I have to remember to re-install all local policy
modules every time there is a policy update, right?? :-((
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
11:52 p.m.
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.
1:38 a.m.
New subject: 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(a)comcast.net
8:36 a.m.
New subject: 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.
10:07 a.m.
On 03/05/2010 08:36 AM, Dominick Grift wrote:
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.
With iptables I am not faced with the task of understanding a huge and
complex base policy, let alone one that is constantly changing, plus
understanding a bunch of minimally documented commands before I can
set up my custom configuration.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
3:09 a.m.
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
7:53 a.m.
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?
--
Stephen Smalley
National Security Agency
8:04 a.m.
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.
Unfortunately my memory might be wrong. Also i cannot find the
particular discussion i had with dwalsh about the issue on the mail
lists on short notice.
Also i do not know whether this is even related to this issue.
8:16 a.m.
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.
Unfortunately my memory might be wrong. Also i cannot find the
particular discussion i had with dwalsh about the issue on the mail
lists on short notice.
Also i do not know whether this is even related to this issue.
--
Stephen Smalley
National Security Agency
8:59 a.m.
New subject: 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.
7:55 a.m.
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??
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
8:15 a.m.
On 03/05/2010 02:55 PM, 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??
Unconfined users (like you) are able to execute any files. Confined
services are not allowed to execute user home content (generic files in
your home directory).
However many confined services can run files in /bin or /usr/bin that
are labelled with the generic type (bin_t) for that location.
You can either copy the spamstring.sh file to /usr/bin or label it type
bin_t in your home directory. If the confined service even has
sufficient permissions to get to the file, then it should be allowed to
run it there.
If you have executable files that should be run by confined services,
then you could label them bin_t. But remember that this only works if
the confined service can get to the file.
You do not have to label executable files bin_t if you (the unconfined
user) need to run it.
i hope this helps.
8:20 a.m.
New subject: 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.
7:44 a.m.
On Thu, 2010-03-04 at 21:29 -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?? :-((
No, that shouldn't be necessary - once you've installed a policy module,
it stays in the policy store and should get re-linked into the final
policy on subsequent transactions unless/until it gets explicitly
removed (via semodule -r). Have you encountered a particular situation
where this hasn't been true?
--
Stephen Smalley
National Security Agency
10:12 a.m.
On 03/05/2010 07:44 AM, Stephen Smalley wrote:
On Thu, 2010-03-04 at 21:29 -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?? :-((
No, that shouldn't be necessary - once you've installed a policy module,
it stays in the policy store and should get re-linked into the final
policy on subsequent transactions unless/until it gets explicitly
removed (via semodule -r). Have you encountered a particular situation
where this hasn't been true?
False alarm. It was an error I made running audit2allow on 2 instances
of the same AVC rather than one each of 2 very similar AVCs. The policy
update that occurred at about that same time was a red herring.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
7:48 a.m.
New subject: 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?
8:58 a.m.
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.
9:13 a.m.
New subject: 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_fou...
This docment explains the four things SELinux is trying to tell you.
9:51 a.m.
On 03/05/2010 09:13 AM, Daniel J Walsh wrote:
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 defense of those just struggling to get by, that is generally what
setroubleshoot suggests. Plus, while the audit2allow route is fairly
obvious, it take a significantly deeper understanding of the base
policy to know which of the source or target types might wrong and
just what the proper labeling should be.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
5159
days inactive
5163
days old
selinux@lists.fedoraproject.org
19 comments
6 participants
participants (6)
-
Chuck Anderson -
Daniel J Walsh -
Dominick Grift -
Paul Howarth -
Robert Nichols -
Stephen Smalley