Bug 131188 - Stunnel does not work with strict SELinux policy
Stunnel does not work with strict SELinux policy
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: stunnel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Russell Coker
: Reopened
Depends On:
Blocks: 133471
  Show dependency treegraph
 
Reported: 2004-08-28 13:21 EDT by W. Michael Petullo
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-01 21:44:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Will this work? (880 bytes, text/plain)
2005-01-03 14:59 EST, Daniel Walsh
no flags Details
Patch to implement "stunnel_is_daemon" boolean (621 bytes, patch)
2005-01-03 15:04 EST, W. Michael Petullo
no flags Details | Diff
Patch to configure "stunnel_is_daemon" boolean (306 bytes, patch)
2005-01-03 15:07 EST, W. Michael Petullo
no flags Details | Diff

  None (edit)
Description W. Michael Petullo 2004-08-28 13:21:09 EDT
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:
Comment 1 W. Michael Petullo 2004-10-03 18:02:57 EDT
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
Comment 2 W. Michael Petullo 2004-10-20 22:26:00 EDT
Seems to be fixed in selinux-policy-strict-1.17.30-2.
Comment 3 W. Michael Petullo 2004-11-16 13:14:31 EST
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.
Comment 4 Daniel Walsh 2004-11-16 13:29:11 EST
inetd.te:   allow inet_d smtp_port_t:tcp_socket name_bind;

What is requisting this?

Dan
Comment 5 W. Michael Petullo 2004-11-16 13:44:36 EST
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?
Comment 6 Daniel Walsh 2004-11-16 14:02:16 EST
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 

Comment 7 W. Michael Petullo 2004-11-20 14:21:50 EST
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 };
Comment 8 Daniel Walsh 2004-11-20 23:12:59 EST
> 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()
Comment 9 W. Michael Petullo 2004-11-21 13:27:51 EST
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?
Comment 10 Daniel Walsh 2004-11-21 14:53:00 EST
The gentoo guys want to put in an
ifelse(`dist-gentoo', `', `
'. `
')
Comment 11 W. Michael Petullo 2004-11-28 00:09:21 EST
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.
Comment 12 W. Michael Petullo 2004-12-30 12:12:09 EST
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_*?
Comment 13 Daniel Walsh 2005-01-03 13:53:25 EST
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?
Comment 14 Daniel Walsh 2005-01-03 14:05:06 EST
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
Comment 15 W. Michael Petullo 2005-01-03 14:48:57 EST
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.
Comment 16 Daniel Walsh 2005-01-03 14:59:09 EST
Created attachment 109269 [details]
Will this work?
Comment 17 W. Michael Petullo 2005-01-03 15:04:21 EST
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.
Comment 18 W. Michael Petullo 2005-01-03 15:07:36 EST
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.
Comment 19 W. Michael Petullo 2005-01-03 15:42:47 EST
The proposal in comment #16 seems to work for me as well.  So we have
two potential solutions (#16 and #17/#18).
Comment 20 Daniel Walsh 2005-01-03 15:49:53 EST
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
Comment 21 W. Michael Petullo 2005-01-12 22:14:34 EST
Looks like the required changes are in selinux-policy-strict-1.20.1-3.
 This version seems to work.
Comment 22 W. Michael Petullo 2006-08-19 15:19:15 EDT
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
Comment 23 W. Michael Petullo 2006-09-01 21:44:14 EDT
Seems fixed by selinux-policy-2.3.9-5.

Note You need to log in before you can comment on or make changes to this bug.