selinux March 2010

selinux@lists.fedoraproject.org

34 participants
38 discussions

SELinux is preventing /bin/gawk "execute" access on /var/home/rnichols/mail/spamstrings.awk
by Robert Nichols 09 Mar '10

09 Mar '10

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.

6 19

Boolean resets don't stick
by Temlakos 08 Mar '10

08 Mar '10

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

3 6

F12: "mac_admin"
by Dan Thurman 08 Mar '10

08 Mar '10

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)

3 2

minor change to httpd_selinux.8
by Dominick Grift 08 Mar '10

08 Mar '10

http://diegobz.net/2010/03/07/enabling-apache-userdir-public_html-with-seli… 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)

1 0

Dear Fedora-Selinux-List, If you can't find in google, try JUSTDIAL.COM
by Rashmi 07 Mar '10

07 Mar '10

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.

1 0

Samba problems
by Jouni Viikari 07 Mar '10

07 Mar '10

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

2 2

Apparent memory leak in libselinux
by Ed Swierk 06 Mar '10

06 Mar '10

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

3 3

F12: SeLinux reports illegal httpd access to .index files?
by Dan Thurman 05 Mar '10

05 Mar '10

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)

3 6

Re: So just where is procmail_t allowed to write/create/rename etc?
by Dominick Grift 05 Mar '10

05 Mar '10

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) >>> >

1 0

So just where is procmail_t allowed to write/create/rename etc?
by Robert Nichols 05 Mar '10

05 Mar '10

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.

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux March 2010