From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.2) Gecko/20040809 Epiphany/1.3.5 Description of problem: Stunnel does not work when executed by xinetd in an environment where SELinux is enforcing Fedora's strict policy. Adding the following line to the selinux policy fixes this: allow inetd_child_t urandom_device_t:chr_file { ioctl }; Is this safe? See also the thread at (there has been progress made since this): https://listman.redhat.com/archives/fedora-selinux-list/2004-July/msg00118.html Version-Release number of selected component (if applicable): stunnel-4.05-3 How reproducible: Always Steps to Reproduce: Try to configure stunnel to be run by xinetd. The following example shows how to tunnel SMTPS traffic from localhost to a remote SMTPS server. /etc/xinetd.d/smtps: service smtps { disable = no socket_type = stream wait = no user = postfix server = /usr/sbin/stunnel log_on_success += USERID log_on_failure += USERID } /etc/stunnel/stunnel.conf: client=yes verify=0 connect = 192.168.0.100:465 TIMEOUTclose = 0 Additional info:
Using selinux-policy-strict-1.17.26-1, I now get: Oct 3 17:02:54 imp kernel: audit(1096840974.886:0): avc: denied { read write } for pid=5593 exe=/usr/sbin/stunnel path=socket:[12019] dev=sockfs ino=12019 scontext=system_u:system_r:inetd_child_t tcontext=system_u:system_r:inetd_t tclass=tcp_socket Oct 3 17:02:55 imp kernel: audit(1096840975.199:0): avc: denied { ioctl } for pid=5593 exe=/usr/sbin/stunnel path=/dev/urandom dev=tmpfs ino=876 scontext=system_u:system_r:inetd_child_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file
Seems to be fixed in selinux-policy-strict-1.17.30-2.
At some point, the SELinux policy was changed, making this an issue again. The following is now required for outgoing mail when I use the configuration documented above: postfix.te: allow postfix_smtp_t postfix_smtp_t:tcp_socket connect; inetd.te: allow inet_d smtp_port_t:tcp_socket name_bind; With the above two additions outgoing mail is processed. I still get these errors, though they don't seem to stop mail: Nov 15 12:15:22 imp kernel: audit(1100542522.770:0): avc: denied { connect } for pid=7270 exe=/usr/sbin/xinetd laddr=127.0.0.1 lport=32822 scontext=root:system_r:inetd_t tcontext=root:system_r:inetd_t tclass=tcp_socket Nov 15 12:15:23 imp kernel: audit(1100542523.480:0): avc: denied { ioctl } for pid=7273 exe=/usr/sbin/stunnel path=/dev/urandom dev=tmpfs ino=1881 scontext=root:system_r:inetd_child_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file As I said, these errors don't stop mail, but I am a little concerned about the one related to /dev/urandom. I wonder if the cryptographic subsystem is initialized properly if the ioctl on /dev/urandom is not allowed. If xinetd is not allowed to open certain ports then how are people supposed to execute daemons that Red Hat does not anticipate? Are end users going to need to modify their SELinux policies by hand? I like the idea of restricting specific ports from xinetd with SELinux but wonder what the solution to this dilemma will be.
inetd.te: allow inet_d smtp_port_t:tcp_socket name_bind; What is requisting this? Dan
Xinetd spawns stunnel when a process connects to port 465 on my machine. Stunnel makes a tunnel to my ISP's mail server. So this is a custom configuration (see the original comment) but I am interested in having it run under the strict policy. My larger question is how is one to implement custom solutions that play nicely with xinetd and the strict policy. When SELinux is enforcing its strict policy, xinetd can't listen on port 465. This is the problem "allow inet_d smtp_port_t:tcp_socket name_bind;" addresses. Does this answer your question?
In order to create custom policy you should create it in the domains/misc directory Say domains/misc/stunnel.te Same goes for file_contexts file_contexts/misc/stunnel.fc You could also add a file containing your inetd change domains/misc/misc.te All of your other policy will be sucked into strict. selinux-policy-strict-1.19.1-11 Once you have your policy running you might want to submit it to the selinux-list. Thanks
It looks like some changes have been made in the strict policy with respect to stunnel. I'm now using selinux-policy-strict-1.19.3-1. This should probably go in inetd.te: allow inetd_t smtp_port_t:tcp_socket name_bind; domain_auto_trans(inetd_t, stunnel_exec_t, stunnel_t) This should probably go in postfix.te: allow postfix_smtp_t postfix_smtp_t:tcp_socket connect; These should probably go in stunnel.te: allow stunnel_t inetd_t:tcp_socket { read write getattr setopt }; allow stunnel_t stunnel_t:udp_socket connect; allow stunnel_t stunnel_t:unix_dgram_socket { create connect write }; allow stunnel_t stunnel_t:tcp_socket { create connect }; allow stunnel_t urandom_device_t:chr_file { getattr read ioctl };
> This should probably go in inetd.te: > allow inetd_t smtp_port_t:tcp_socket name_bind; What requires this? > domain_auto_trans(inetd_t, stunnel_exec_t, stunnel_t) Changin stunnel to be inetd_child_domain(stunnel) fixes this. > This should probably go in postfix.te: > allow postfix_smtp_t postfix_smtp_t:tcp_socket connect; Already in there via postfix_server_domain > These should probably go in stunnel.te: > allow stunnel_t inetd_t:tcp_socket { read write getattr setopt }; > allow stunnel_t stunnel_t:udp_socket connect; > allow stunnel_t stunnel_t:unix_dgram_socket { create connect write }; > allow stunnel_t stunnel_t:tcp_socket { create connect }; > allow stunnel_t urandom_device_t:chr_file { getattr read ioctl }; All added by changing to inetd_child_domain()
Thanks for pointing out the inetd_child_domain macro. As it turns out, only inetd_child_domain(stunnel) is required. However, this requires commenting out many lines from stunnel.te. Several definitions in stunnel.te conflict with inetd_child_domain. In fact, I left only the following lines: type stunnel_etc_t, file_type, sysadmfile; r_dir_file(stunnel_t, stunnel_etc_t) r_dir_file(stunnel_t, etc_t) Is there a way to avoid this conflict?
The gentoo guys want to put in an ifelse(`dist-gentoo', `', ` '. ` ')
selinux-policy-strict-1.19.4-4 seems to fix the issues in comment #9. Now the ONLY local addition I need for my stunnel/smtps configuration is this: allow inetd_t smtp_port_t:tcp_socket name_bind; This allows xinetd to bind to port 465 so that it may listen for smtps connections that should be passed on to stunnel. This bug may probably be closed unless someone thinks the rule above could go in inetd.te.
Would it be possible to wrap this in something besides dist_gentoo? I would like to be able to have xinetd execute stunnel but certainly do not want to diverge from distro_redhat too much. Would it make more sence to allow people to define something like "inetd_stunnel" in tunable.te instead basing things of the coarse grained dist_*?
How about if we add a boolean? bool stunnel_is_daemon false; if (stunnel_is_daemon) { allow inetd_t smtp_port_t:tcp_socket name_bind; } Does that work for you?
Ignore the last comment. What privs are you seeing that you need when you want to run stunnel outside of inetd? I might could add them under a boolean. Could you send the AVC messages. Dan
This combination of lines from selinux-policy-strict-sources-1.19.15-10's stunnel.te allows inetd to execute stunnel: # From distro_gentoo: inetd_child_domain(stunnel, tcp) allow stunnel_t self:capability sys_chroot; # From ! distro_gentoo: type stunnel_etc_t, file_type, sysadmfile; r_dir_file(stunnel_t, stunnel_etc_t) In addition, inetd must be granted access to specific ports but I think this may belong in local policy modifications.
Created attachment 109269 [details] Will this work?
Created attachment 109272 [details] Patch to implement "stunnel_is_daemon" boolean This patch changes this: if distro_gentoo allow inetd to run stunnel else don't to this: if stunnel_is_daemon don't else allow inetd to run stunnel This way I can allow inetd to execute stunnel without enabling all of the gentoo-specific configurations.
Created attachment 109273 [details] Patch to configure "stunnel_is_daemon" boolean This adds a "stunnel_is_daemon" boolean to tunable.tun. Gentoo can enable this, Red Hat can disable it.
The proposal in comment #16 seems to work for me as well. So we have two potential solutions (#16 and #17/#18).
I will pass #16 upstream. I prefer booleans to tunables, because they give the admin greater flexability without requiring him to install policy sources. Dan
Looks like the required changes are in selinux-policy-strict-1.20.1-3. This version seems to work.
I just started having problems with this again. I am using selinux-policy-targeted-2.3.7-1. As before, xinetd uses stunnel to tunnel to my real smtps server when something opens localhost:465. With SELinux in enforcing mode: type=AVC msg=audit(1156014998.743:262): avc: denied { create } for pid=30394 comm="stunnel" scontext=system_u:system_r:stunnel_t:s0 tcontext=system_u:system_r:stunnel_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1156014998.743:262): arch=14 syscall=102 success=yes exit=-13 a0=1 a1=7ff3c564 a2=0 a3=7ff3c5d4 items=0 pid=30394 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 comm="stunnel" exe="/usr/sbin/stunnel" type=SOCKETCALL msg=audit(1156014998.743:262): nargs=3 a0=10 a1=3 a2=0 type=AVC msg=audit(1156014998.775:263): avc: denied { name_connect } for pid=30394 comm="stunnel" dest=465 scontext=system_u:system_r:stunnel_t:s0 tcontext=system_u:object_r:smtp_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1156014998.775:263): arch=14 syscall=102 success=yes exit=-13 a0=3 a1=7ff3ff44 a2=10 a3=8038c14 items=0 pid=30394 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 comm="stunnel" exe="/usr/sbin/stunnel" type=SOCKADDR msg=audit(1156014998.775:263): saddr=000201D14509BF060000000000000000 type=SOCKETCALL msg=audit(1156014998.775:263): nargs=3 a0=4 a1=7ff40134 a2=10 With SELinux in permissive mode: type=AVC msg=audit(1156015282.045:268): avc: denied { create } for pid=30458 comm="stunnel" scontext=system_u:system_r:stunnel_t:s0 tcontext=system_u:system_r:stunnel_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1156015282.045:268): arch=14 syscall=102 success=yes exit=4 a0=1 a1=7fe9d564 a2=0 a3=7fe9d5d4 items=0 pid=30458 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 comm="stunnel" exe="/usr/sbin/stunnel" type=SOCKETCALL msg=audit(1156015282.045:268): nargs=3 a0=10 a1=3 a2=0 type=AVC msg=audit(1156015282.049:269): avc: denied { bind } for pid=30458 comm="stunnel" scontext=system_u:system_r:stunnel_t:s0 tcontext=system_u:system_r:stunnel_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1156015282.049:269): arch=14 syscall=102 success=yes exit=0 a0=2 a1=7fe9d564 a2=c a3=7fe9d5d4 items=0 pid=30458 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 comm="stunnel" exe="/usr/sbin/stunnel" type=SOCKADDR msg=audit(1156015282.049:269): saddr=001000000000000000000000 type=SOCKETCALL msg=audit(1156015282.049:269): nargs=3 a0=4 a1=7fe9d58c a2=c type=AVC msg=audit(1156015282.049:270): avc: denied { getattr } for pid=30458 comm="stunnel" scontext=system_u:system_r:stunnel_t:s0 tcontext=system_u:system_r:stunnel_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1156015282.049:270): arch=14 syscall=102 success=yes exit=0 a0=6 a1=7fe9d564 a2=7fe9d588 a3=7fe9d5d4 items=0 pid=30458 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 comm="stunnel" exe="/usr/sbin/stunnel" type=SOCKETCALL msg=audit(1156015282.049:270): nargs=3 a0=4 a1=7fe9d58c a2=7fe9d588 type=AVC msg=audit(1156015282.049:271): avc: denied { write } for pid=30458 comm="stunnel" scontext=system_u:system_r:stunnel_t:s0 tcontext=system_u:system_r:stunnel_t:s0 tclass=netlink_route_socket type=AVC msg=audit(1156015282.049:271): avc: denied { nlmsg_read } for pid=30458 comm="stunnel" scontext=system_u:system_r:stunnel_t:s0 tcontext=system_u:system_r:stunnel_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1156015282.049:271): arch=14 syscall=102 success=yes exit=20 a0=b a1=7fe9c4c4 a2=14 a3=0 items=0 pid=30458 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 comm="stunnel" exe="/usr/sbin/stunnel" type=SOCKADDR msg=audit(1156015282.049:271): saddr=001000000000000000000000 type=SOCKETCALL msg=audit(1156015282.049:271): nargs=6 a0=4 a1=7fe9c4fc a2=14 a3=0 a4=7fe9c4f0 a5=c type=AVC msg=audit(1156015282.049:272): avc: denied { read } for pid=30458 comm="stunnel" scontext=system_u:system_r:stunnel_t:s0 tcontext=system_u:system_r:stunnel_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1156015282.049:272): arch=14 syscall=102 success=yes exit=128 a0=11 a1=7fe9c4c4 a2=0 a3=0 items=0 pid=30458 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 comm="stunnel" exe="/usr/sbin/stunnel" type=SOCKETCALL msg=audit(1156015282.049:272): nargs=3 a0=4 a1=7fe9c510 a2=0 type=AVC msg=audit(1156015282.057:273): avc: denied { name_connect } for pid=30458 comm="stunnel" dest=465 scontext=system_u:system_r:stunnel_t:s0 tcontext=system_u:object_r:smtp_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1156015282.057:273): arch=14 syscall=102 success=yes exit=-115 a0=3 a1=7fea0f44 a2=10 a3=8038c2c items=0 pid=30458 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 comm="stunnel" exe="/usr/sbin/stunnel" type=SOCKADDR msg=audit(1156015282.057:273): saddr=000201D14509BF060000000000000000 type=SOCKETCALL msg=audit(1156015282.057:273): nargs=3 a0=4 a1=7fea1134 a2=10
Seems fixed by selinux-policy-2.3.9-5.