Selinux and mailman via postfix pipe
by Geert Janssens
Hi,
I'm setting up a new server based on CentOS 6.2. It is meant to replace
a CentOS 5 server. The old server had selinux running in permissive
mode, but I figured it would be a good thing to enforce it on the new
server. This has revealed some selinux violations in my old
configurations. Most of them I managed to fix so far, with one exception:
Part of the setup involves a mailman based mailing list service. This is
configured using a postfix pipe into a python script called
postfix-to-mailman.py [1]. This is convenient, as it saves our admins
the hassle of managing the aliases required for each list. The problem
is though that this doesn't seem to work with selinux enabled.
Here are the relevant error messages:
In the maillog:
pipe[11266]: fatal: pipe_command: execvp
/usr/lib/mailman/bin/postfix-to-mailman.py: Permission denied
And the SELinux AVC:
type=AVC msg=audit(1334239608.305:371794): avc: denied { search } for
pid=10858 comm="python" name="mailman" dev=xvda ino=5833449
scontext=unconfined_u:system_r:postfix_pipe_t:s
0 tcontext=system_u:object_r:mailman_data_t:s0 tclass=dir
type=SYSCALL msg=audit(1334239608.305:371794): arch=c000003e syscall=80
success=no exit=-13 a0=12a8f00 a1=1 a2=34ae5b3dc8 a3=20 items=0
ppid=10857 pid=10858 auid=501 uid=41 gid=41
euid=41 suid=41 fsuid=41 egid=41 sgid=41 fsgid=41 tty=(none) ses=6491
comm="python" exe="/usr/bin/python"
subj=unconfined_u:system_r:postfix_pipe_t:s0 key=(null)
SELinux is preventing /usr/bin/python from search access on the
directory /var/lib/mailman.
***** Plugin catchall (100. confidence) suggests
***************************
If you believe that python should be allowed search access on the
mailman directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep python /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
I am not sure how to proceed here. I already tried to change the
fcontext for postfix-to-mailman.py to mailman_mail_exec_t or
mailman_data_t, but that simply results in a denial that prevents
postfix' pipe to execute postfix-to-mailman.py.
I searched the web, but the closest I came is an old bugreport against
Fedora [2] suggesting this should have been fixed. Perhaps it is for
Fedora, but it's not for CentOS 6 at least.
What should I do to get this running ?
Geert
[1] http://www.gurulabs.com/downloads/postfix-to-mailman-2.1.py
[2] https://bugzilla.redhat.com/show_bug.cgi?id=183928
12 years
SELinux preventing login (Fedora 16)
by Braden McDaniel
[I posted this first to the users list by mistake; but I meant for it to
go here.]
I have a Fedora 16 box where something seems to have gone sideways with
SELinux. I am unable to log into the box with SELinux enabled. I see
messages in /var/log/messages that look like this:
Apr 11 02:40:06 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:06 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:07 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:10 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:26 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:58 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:02 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:02 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:02 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:06 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:14 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:30 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:43:02 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
I tried doing a full relabel; but that had no noticeable effect. If I
boot to single user mode and disable SELinux (via /etc/selinux/config),
I'm able to log in and things appear to be functional. Well, with the
caveat that the suggestion in the message to run sealert yields this:
# sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Opps, sealert hit an error!
Traceback (most recent call last):
File "/usr/bin/sealert", line 668, in <module>
proxy_obj = bus.get_object(dbus_system_bus_name, dbus_system_object_path)
File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 244, in get_object
follow_name_owner_changes=follow_name_owner_changes)
File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 241, in __init__
self._named_service = conn.activate_name_owner(bus_name)
File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 183, in activate_name_owner
self.start_service_by_name(bus_name)
File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 281, in start_service_by_name
'su', (bus_name, flags)))
File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, in call_blocking
message, timeout)
DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 3
Any idea what happened here and how I might actually fix it?
--
Braden McDaniel <braden(a)endoframe.com>
12 years
Permission denied to cgi-script when enforcing selinux on RHEL6
by darksinclair＠gmail.com
Greetings all,
I've set up a simple apache webserver with cgi-script executing
python code on RHEL6. With selinux disabled, the script returns
output fine to a browser but with selinux enforced I receive a 500
Internal Server error and permission denied in ssl_error_log with
nothing logged to audit.log even though don't audit rules is disabled.
audit2allow -a -l is clean as well. I am able to successfully
execute the script on the command line under apache's context httpd_t,
so it's only when returning the content to the browser that the 500
Internal Server error occurs. Anyone have any idea to help
troubleshoot?
Pertinent information below, any help is greatly appreciated.
Thanks in advance,
>> ssl_error_log when accessing through the browser:
[Tue Apr 10 09:37:43 2012] [error] (13)Permission denied: exec of
'/var/www/cgi-bin/index.py' failed
[Tue Apr 10 09:37:43 2012] [error] Premature end of script headers: index.py
>> Apache is running under context httpd_t:
# /bin/ps axZ | grep http
unconfined_u:system_r:httpd_t:s0 12716 ? Ss 0:00 /usr/sbin/httpd
unconfined_u:system_r:httpd_t:s0 12719 ? S 0:00 /usr/sbin/httpd
unconfined_u:system_r:httpd_t:s0 12720 ? S 0:00 /usr/sbin/httpd
unconfined_u:system_r:httpd_t:s0 12721 ? S 0:00 /usr/sbin/httpd
unconfined_u:system_r:httpd_t:s0 12722 ? S 0:00 /usr/sbin/httpd
unconfined_u:system_r:httpd_t:s0 12723 ? S 0:00 /usr/sbin/httpd
unconfined_u:system_r:httpd_t:s0 12724 ? S 0:00 /usr/sbin/httpd
unconfined_u:system_r:httpd_t:s0 12725 ? S 0:00 /usr/sbin/httpd
unconfined_u:system_r:httpd_t:s0 12726 ? S 0:00 /usr/sbin/httpd
>> Able to execute the script successfully under apache with context httpd_t:
# sudo -u apache -t httpd_t ./index.py
Content-Type: text/plain;charset=utf-8
Hello World!
>> sebool's have at least httpd_enable_cgi:
# getsebool -a | grep http | grep "\-\-> on"
httpd_builtin_scripting --> on
httpd_dbus_avahi --> on
httpd_enable_cgi --> on
httpd_execmem --> on
httpd_tty_comm --> on
httpd_unified --> on
>> All contexts, importantly httpd_sys_script_exec_t for cgi-bin and index.py within:
# ls -lZd /var/www/
drwxr-xr-x. root apache system_u:object_r:httpd_sys_content_t:s0 /var/www/
# ls -lZd /var/www/*
drwxr-xr-x. root apache system_u:object_r:httpd_sys_script_exec_t:s0
/var/www/cgi-bin
drwxr-xr-x. root apache system_u:object_r:httpd_sys_content_t:s0 /var/www/html
# ls -lZd /var/www/cgi-bin/*
-rwxr-xr-x. root apache system_u:object_r:httpd_sys_script_exec_t:s0
/var/www/cgi-bin/index.py
12 years
How to get a .te file from an existing .pp file?
by Gabriele Pohl
Hi all,
I've installed a software from the sources on a CentOS 6.2 box
and would like to setup a SELinux policy for it.
As I already use the software on my Fedora 15 server
Source RPM : BackupPC-3.2.1-7.fc15.src.rpm
I would like to use the wisdom from the existing policy module:
/usr/share/selinux/packages/BackupPC/BackupPC.pp
I found this forum thread:
http://www.linuxquestions.org/questions/showthread.php?p=4548316#post4548316
which ended with the hint:
"Use the tools from the setools package."
I tried this, but wasn't successful.
All the time running into errors telling me,
that these cannot open the policy file,
as it is no "base policy"
Can you help with instructions?
Or tell me, where to find the .te file of the Fedora package?
Thanks in advance and kind regards
Gabriele
PS: I found this instruction on how to generate the .pp
from the audit messages. So if there is really no way
to /decompile/ the .pp I will go this way:
http://www.advisorbits.com/2011/03/backuppc_on_centos_5_selinux_fix.html
12 years
denied despite allow rule
by Maria Iano
I'm confused about a situation where I'm getting denied avc messages
even though there is an allow rule in place. What am I missing?
This is on RHEL 5.8 using the targeted policy. Here's an example. I
have this avc message from this morning:
type=AVC msg=audit(1333372681.227:20002): avc: denied { append }
for pid=3480 comm="vsftpd" path="/LTS/eng-ng/snip/2012/03/20/
STORY_Letters_for_Sun._3-4_1_66_610389Z/
IMG_Cartoon_for_3-4.jpg_1_1_8F1363GR/
IMG_Cartoon_for_3-4.jpg_1_1_8F1363GR.xml" dev=dm-8 ino=227640612
scontext=system_u:system_r:ftpd_t:s0
tcontext=system_u:object_r:public_content_t:s0 tclass=file
but when I do sesearch it shows a matching allow rule:
# sesearch -s ftpd_t -t public_content_t -c file -p append -a
Found 1 av rules:
allow ftpd_t public_content_t : file { ioctl read write create
getattr setattr lock append unlink link rename };
Found 5 role allow rules:
allow system_r sysadm_r ;
allow user_r sysadm_r ;
allow user_r system_r ;
allow sysadm_r user_r ;
allow sysadm_r system_r ;
Thanks for any help you can give,
Maria
12 years
Would the F17 policy have problems with a 3.2.7 kernel?
by Göran Uddeborg
I would like to move on towards an F17 system. I'm stuck, however
with an 3.2.7 kernel because of bugzilla 795141. (The test kernel
that was provided in the bugzilla works for me, but so far the fix
doesn't seem to have been included in any released kernel package.)
And the standard F17 kernel is 3.3.0.
Most things won't actually depend on the newer kernel in F17, but from
experience I've learned that the selinux-policy is one of the more
sensitive parts. Are you aware of any reason it will fail with the
slightly older kernel? Or is there a chance it might work? At least
reasonably well?
I'm of course not asking for any kind of official support. Whatever
that would mean for an alpha of Fedora. :-) But before I do the
attempt I wanted to check if you saw any obvious reasons things would
crash completely if I tried the combination.
12 years
audit avc F16
by Frank Murphy
Currently auditd fails to start on a particular guest.
service auditd restart
Redirecting to /bin/systemctl restart auditd.service
[ 199.986682] type=1400 audit(1333285442.114:6): avc: denied {
dac_override } for pid=1409 comm="auditd" capability=1
scontext=system_u:system_r:auditd_t:s0
tcontext=system_u:system_r:auditd_t:s0 tclass=capability
[ 199.988842] type=1400 audit(1333285442.116:7): avc: denied {
dac_read_search } for pid=1409 comm="auditd" capability=2
scontext=system_u:system_r:auditd_t:s0
tcontext=system_u:system_r:auditd_t:s0 tclass=capability
Job failed. See system logs and 'systemctl status' for details.
systemctl status auditd.service
gives nothing extra to above.
--
Regards,
Frank
"Jack of all, fubars"
12 years
