SELinux is preventing /bin/gawk "execute" access on /var/home/rnichols/mail/spamstrings.awk
by Robert Nichols
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.
14 years, 1 month
Boolean resets don't stick
by Temlakos
Why is it that when I changed some SELinux variables to allow certain
processes, the allowances did not persist with the next shutdown and
reboot cycle?
I had occasion to set allow_execmod and several Samba-related Booleans.
And then this morning, it was as if I hadn't customized anything.
I had to revert and reset every one of those custom variables, and
/then/ I did a complete relabel. Once I did that, a certain application
that needed execmod allowed, would run. Samba runs as well, though I
probably discovered another issue--failure to turn on the nmb service as
well as the smb service.
But when I change a part of the Samba policy, I thought that should hold
for good. Why doesn't it? Or did the relabeling finally make the issue
go away?
I just don't want that issue to come back, that's all--but I don't want
to disable SELinux in order to do that.
Temlakos
14 years, 1 month
F12: "mac_admin"
by Dan Thurman
I have no idea what this is, but it is new:
================================================
Summary:
SELinux is preventing /usr/bin/chcon "mac_admin" access .
Detailed Description:
SELinux denied access requested by chcon. It is not expected that this
access is
required by chcon 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
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
023
Target Context
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
023
Target Objects None [ capability2 ]
Source chcon
Source Path /usr/bin/chcon
Port <Unknown>
Host host.domain.com
Source RPM Packages coreutils-7.6-9.fc12
Target RPM Packages
Policy RPM selinux-policy-3.6.32-92.fc12
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Plugin Name catchall
Host Name host.domain.com
Platform Linux host.domain.com
2.6.31.12-174.2.22.fc12.i686
#1 SMP Fri Feb 19 19:26:06 UTC 2010 i686 i686
Alert Count 1
First Seen Fri 05 Mar 2010 11:24:27 AM PST
Last Seen Fri 05 Mar 2010 11:24:27 AM PST
Local ID 73c77171-b9bb-44f9-98bb-68a6d3ee1e96
Line Numbers
Raw Audit Messages
node=host.domain.com type=AVC msg=audit(1267817067.517:43791): avc:
denied { mac_admin } for pid=28356 comm="chcon" capability=33
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=capability2
node=host.domain.com type=SYSCALL msg=audit(1267817067.517:43791):
arch=40000003 syscall=226 success=no exit=-22 a0=834b8d0 a1=7fd69ed
a2=834cc90 a3=23 items=0 ppid=28098 pid=28356 auid=500 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts10 ses=1 comm="chcon"
exe="/usr/bin/chcon"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
14 years, 1 month
minor change to httpd_selinux.8
by Dominick Grift
http://diegobz.net/2010/03/07/enabling-apache-userdir-public_html-with-se...
Fix should also be propagated to:
http://fedoraproject.org/wiki/SELinux/apache
--- httpd_selinux.8.old 2010-03-05 23:15:46.000000000 +0100
+++ httpd_selinux.8 2010-03-08 14:12:52.545589476 +0100
@@ -70,7 +70,7 @@
.EX
setsebool -P httpd_enable_homedirs 1
-chcon -R -t httpd_sys_content_t ~user/public_html
+restorecon -R ~user/public_html
.EE
.PP
@@ -115,6 +115,6 @@
This manual page was written by Dan Walsh <dwalsh(a)redhat.com>.
.SH "SEE ALSO"
-selinux(8), httpd(8), chcon(1), setsebool(8)
+selinux(8), httpd(8), chcon(1), setsebool(8), restorecon(8)
14 years, 1 month
Dear Fedora-Selinux-List, If you can't find in google, try JUSTDIAL.COM
by Rashmi
Dear Fedora-Selinux-List,I strongly recommend this website www.justdial.com. It's a world class local search service & I've always found anything I've ever wanted.You can find info on any company, product, or service in over 240 cities in India.You can also call them up 24x7, on phone (69999999), a local call in 240 Indian cities.Ask for anything, you'll get the info on the phone and/or by SMS within 30 secs, and this service is at no cost!For a change, it's an original Indian idea and an Indian company with world class service, and with a vision to spread all over the world.Be a proud Indian and forward this to every Indian you know.Best Wishes,RashmiClick Here to unsubscribe.
14 years, 1 month
Samba problems
by Jouni Viikari
Hi,
I noticed that my samba server has suddenly stopped sharing directories
after some updates. Printers seems to be ok. I have not changed any
configurations. When I restart samba I get following SELinux error:
"SELinux is preventing /usr/sbin/smbd "search" access to /.
Detailed Description
SELinux denied access requested by smbd. / may be a mislabeled. /
default SELinux type is root_t, but its current type is etc_runtime_t.
Changing this file back to the default type, may fix your problem."...
...but as expected:
#ls -ldZ /.
dr-xr-xr-x. root root system_u:object_r:root_t:s0 /.
BR,
Jouni
14 years, 1 month
Apparent memory leak in libselinux
by Ed Swierk
When I run the following on a F12 system booted with selinux=0, the
tcmalloc heap checker complains about a leak somewhere in libselinux:
$ HEAPCHECK=normal LD_PRELOAD=/usr/lib64/libtcmalloc.so.0
/usr/bin/python -c 'import _ssl'
Leak check _main_ detected leaks of 120 bytes in 1 objects
The 1 largest leaks:
Leak of 120 bytes in 1 objects allocated from:
@ 0x3bf9866589 _IO_getdelim
@ 0x3bfb40ca53 set_selinuxmnt
@ 0x3bfb414fe6 string_to_security_class
@ 0x3bfb404cdb _init
@ 0x7fff4bdfa8ed 0x00007fff4bdfa8ed
No leak is detected when I run this with selinux enabled. My system
has libselinux-2.0.87-1.fc12 installed.
--Ed
14 years, 1 month
F12: SeLinux reports illegal httpd access to .index files?
by Dan Thurman
Seems to me, that httpd should not be looking at /usr/share/snmp/.../.index
files? Notice that the .index file appears and for some reason httpd thinks
it should be looking at it!?!? I don't know what to make of it.
Here is what I got from selinuxtool:
================================================
Summary:
SELinux is preventing /usr/sbin/httpd "write" access to
/usr/share/snmp/mibs/.index.
Detailed Description:
SELinux denied access requested by httpd. /usr/share/snmp/mibs/.index
may be a
mislabeled. /usr/share/snmp/mibs/.index default SELinux type is
snmpd_var_lib_t,
but its current type is usr_t. Changing this file back to the default
type, may
fix your problem.
File contexts can be assigned to a file in the following ways.
* Files created in a directory receive the file context of the parent
directory by default.
* The SELinux policy might override the default label inherited from the
parent directory by specifying a process running in context A which
creates
a file in a directory labeled B will instead create the file with
label C.
An example of this would be the dhcp client running with the
dhclient_t type
and creating a file in the directory /etc. This file would normally
receive
the etc_t type due to parental inheritance but instead the file is
labeled
with the net_conf_t type because the SELinux policy specifies this.
* Users can change the file context on a file using tools such as
chcon, or
restorecon.
This file could have been mislabeled either by user error, or if an normally
confined application was run under the wrong domain.
However, this might also indicate a bug in SELinux because the file
should not
have been labeled with this type.
If you believe this is a bug, please file a bug report against this package.
Allowing Access:
You can restore the default system context to this file by executing the
restorecon command. restorecon '/usr/share/snmp/mibs/.index', if this
file is a
directory, you can recursively restore using restorecon -R
'/usr/share/snmp/mibs/.index'.
Fix Command:
/sbin/restorecon '/usr/share/snmp/mibs/.index'
Additional Information:
Source Context system_u:system_r:httpd_t:s0
Target Context unconfined_u:object_r:usr_t:s0
Target Objects /usr/share/snmp/mibs/.index [ file ]
Source httpd
Source Path /usr/sbin/httpd
Port <Unknown>
Host gold.cdkkt.com
Source RPM Packages httpd-2.2.14-1.fc12
Target RPM Packages
Policy RPM selinux-policy-3.6.32-89.fc12
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Plugin Name restorecon
Host Name gold.cdkkt.com
Platform Linux gold.cdkkt.com
2.6.31.12-174.2.22.fc12.i686
#1 SMP Fri Feb 19 19:26:06 UTC 2010 i686 i686
Alert Count 1
First Seen Tue 02 Mar 2010 02:35:14 PM PST
Last Seen Tue 02 Mar 2010 02:35:14 PM PST
Local ID 985d0293-7cc2-401b-85b0-d8273b14364e
Line Numbers
Raw Audit Messages
node=gold.cdkkt.com type=AVC msg=audit(1267569314.169:39991): avc:
denied { write } for pid=2133 comm="httpd" name=".index" dev=sdb8
ino=520318 scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:usr_t:s0 tclass=file
node=gold.cdkkt.com type=SYSCALL msg=audit(1267569314.169:39991):
arch=40000003 syscall=5 success=no exit=-13 a0=bfe6fa10 a1=8241 a2=1b6
a3=b7181e7f items=0 ppid=1 pid=2133 auid=4294967295 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295
comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0
key=(null)
14 years, 1 month
Re: So just where is procmail_t allowed to write/create/rename etc?
by Dominick Grift
On 03/05/2010 07:41 PM, Daniel B. Thurman wrote:
> Not sure what you mean by going into permissive mode.. you
> mean: setenforce=0?
setenforce 0
< reproduce issue >
paste avc denials here.
setenforce 1
>> We know it wants to write to the mqueue dir, question is: for what
>> purpose. Does it want to create something there and why?
>>
> Beats me! Not enough information to go on...
>>> =================================================
>>>
>>> Summary:
>>>
>>> SELinux is preventing /usr/bin/procmail "write" access on
>>> /var/spool/mqueue.
>>>
>>> Detailed Description:
>>>
>>> SELinux denied access requested by procmail. It is not expected that
>>> this access
>>> is required by procmail 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 system_u:object_r:mqueue_spool_t:s0
>>> Target Objects /var/spool/mqueue [ dir ]
>>> Source procmail
>>> Source Path /usr/bin/procmail
>>> Port<Unknown>
>>> Host host.domain.com
>>> Source RPM Packages procmail-3.22-25.fc12
>>> Target RPM Packages sendmail-8.14.3-8.fc12
>>> Policy RPM selinux-policy-3.6.32-89.fc12
>>> Selinux Enabled True
>>> Policy Type targeted
>>> Enforcing Mode Enforcing
>>> Plugin Name catchall
>>> Host Name host.domain.com
>>> Platform Linux host.domain.com
>>> 2.6.31.12-174.2.22.fc12.i686
>>> #1 SMP Fri Feb 19 19:26:06 UTC 2010
>>> i686 i686
>>> Alert Count 9
>>> First Seen Tue 02 Mar 2010 03:12:16 AM PST
>>> Last Seen Tue 02 Mar 2010 05:13:03 AM PST
>>> Local ID 5c68ab75-d7e0-4e2d-b380-857eb7e33c68
>>> Line Numbers
>>>
>>> Raw Audit Messages
>>>
>>> node=host.domain.com type=AVC msg=audit(1267535583.841:38780): avc:
>>> denied { write } for pid=12554 comm="procmail" name="mqueue" dev=sdb8
>>> ino=29627 scontext=system_u:system_r:procmail_t:s0
>>> tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=dir
>>>
>>> node=host.domain.com type=SYSCALL msg=audit(1267535583.841:38780):
>>> arch=40000003 syscall=5 success=no exit=-13 a0=92f6d68 a1=8441 a2=1b7
>>> a3=1b7 items=0 ppid=12553 pid=12554 auid=4294967295 uid=0 gid=12 euid=0
>>> suid=0 fsuid=0 egid=12 sgid=12 fsgid=12 tty=(none) ses=4294967295
>>> comm="procmail" exe="/usr/bin/procmail"
>>> subj=system_u:system_r:procmail_t:s0 key=(null)
>>>
>
14 years, 1 month
So just where is procmail_t allowed to write/create/rename etc?
by Robert Nichols
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
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
14 years, 1 month
