Running fully updated Fedora 8, trying to start stunnel from xinetd, and getting a couple of denials:
type=AVC msg=audit(1205149512.996:2338): avc: denied { write } for pid=14322 comm="stunnel" name="random_seed" dev=md1 ino=819429 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:stunnel_etc_t:s0 tclass=file
type=AVC msg=audit(1205149512.998:2339): avc: denied { name_bind } for pid=14322 comm="stunnel" src=2873 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
Aren't these things that stunnel should be expected to do?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ian Pilcher wrote:
Running fully updated Fedora 8, trying to start stunnel from xinetd, and getting a couple of denials:
type=AVC msg=audit(1205149512.996:2338): avc: denied { write } for pid=14322 comm="stunnel" name="random_seed" dev=md1 ino=819429 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:stunnel_etc_t:s0 tclass=file
Confined apps writing to /etc is frowned upon. /etc/ should be considered R/O. If you move this file to /var/run/stunnel and change the config, it should work.
type=AVC msg=audit(1205149512.998:2339): avc: denied { name_bind } for pid=14322 comm="stunnel" src=2873 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
Aren't these things that stunnel should be expected to do?
You have to define ports that stunnel can listen to.
semanage port -a -t stunnel_port_t -P tcp 2873
Daniel J Walsh wrote:
Confined apps writing to /etc is frowned upon. /etc/ should be considered R/O. If you move this file to /var/run/stunnel and change the config, it should work.
Nope.
type=AVC msg=audit(1205188277.824:2538): avc: denied { getattr } for pid=1696 comm="stunnel" path="/var/run/stunnel/random_seed" dev=md1 ino=36907 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file
(And shouldn't it really go under /var/lib/stunnel, since it's supposed to survive a reboot?)
You have to define ports that stunnel can listen to.
semanage port -a -t stunnel_port_t -P tcp 2873
OK, that got me past the bind denial. Unfortunately, it looks like stunnel isn't allowed to access /usr/bin, so it can't start the rsync daemon:
type=AVC msg=audit(1205188277.890:2539): avc: denied { search } for pid=1698 comm="stunnel" name="bin" dev=md1 ino=2686986 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=dir
Thanks!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ian Pilcher wrote:
Daniel J Walsh wrote:
Confined apps writing to /etc is frowned upon. /etc/ should be considered R/O. If you move this file to /var/run/stunnel and change the config, it should work.
Nope.
type=AVC msg=audit(1205188277.824:2538): avc: denied { getattr } for pid=1696 comm="stunnel" path="/var/run/stunnel/random_seed" dev=md1 ino=36907 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file
(And shouldn't it really go under /var/lib/stunnel, since it's supposed to survive a reboot?)
You have to define ports that stunnel can listen to.
semanage port -a -t stunnel_port_t -P tcp 2873
OK, that got me past the bind denial. Unfortunately, it looks like stunnel isn't allowed to access /usr/bin, so it can't start the rsync daemon:
type=AVC msg=audit(1205188277.890:2539): avc: denied { search } for pid=1698 comm="stunnel" name="bin" dev=md1 ino=2686986 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=dir
Thanks!
Ok, I have been avoiding this. I have never used stunnel. Is it common for stunnel to start the application that is going to run within the tunnel? Or do you just setup the tunnel and the user then runs tools like rsync or telnet?
So do we need a rsync_domtrans(stunnel_t) to start the rsync server or does it just need to execute the client?
Daniel J Walsh wrote:
Ok, I have been avoiding this. I have never used stunnel. Is it common for stunnel to start the application that is going to run within the tunnel? Or do you just setup the tunnel and the user then runs tools like rsync or telnet?
On the server side, stunnel can start the application in the same manner as [x]inetd. So my rsync over SSL setup works like this:
1. Client - rsync connects to localhost:2873 2. Client - xinetd accepts connection on port 2873 and execs stunnel 3. Client - stunnel makes SSL connection to server:2873 4. Server - xinetd accepts connection on port 2873 and execs stunnel 5. Server - stunnel does SSL handshake with client and execs "rsync --daemon"
So do we need a rsync_domtrans(stunnel_t) to start the rsync server or does it just need to execute the client?
Here's what I think is needed (from the administrator's point of view):
1. A stunnel_var_lib_t for /var/lib/stunnel. FHS says that persistent state like a random seed goes in /var/lib. (This probably applies to most or all of the applications that use the OpenSSL libraries.)
2. A bunch of per-daemon booleans, stunnel_exec_foo. Each of these would enable filesystem access (/usr/bin or /usr/sbin) and execing the appropriate file type. The daemons should presumably run with the same context that they would if started by xinetd.
To get a complete(?) list of the xinetd daemons in Fedora 8, I've done the following:
yum install `yum provides '/etc/xinetd.d/*' | awk '{ print $1 }'` grep 'socket_type.*=.*stream' /etc/xinetd.d/* | awk '{ print $1 }' \ | sort -u
I get:
/etc/xinetd.d/apgd: /etc/xinetd.d/auth: /etc/xinetd.d/bitlbee: /etc/xinetd.d/chargen-stream: /etc/xinetd.d/cups-lpd: /etc/xinetd.d/cvs: /etc/xinetd.d/daytime-stream: /etc/xinetd.d/discard-stream: /etc/xinetd.d/echo-stream: /etc/xinetd.d/eklogin: /etc/xinetd.d/ekrb5-telnet: /etc/xinetd.d/finger: /etc/xinetd.d/git: /etc/xinetd.d/gssftp: /etc/xinetd.d/identtestd: /etc/xinetd.d/imap: /etc/xinetd.d/imaps: /etc/xinetd.d/ipop2: /etc/xinetd.d/ipop3: /etc/xinetd.d/klogin: /etc/xinetd.d/krb5-telnet: /etc/xinetd.d/kshell: /etc/xinetd.d/leafnode: /etc/xinetd.d/nuttcp: /etc/xinetd.d/pop3s: /etc/xinetd.d/pure-ftpd: /etc/xinetd.d/rexec: /etc/xinetd.d/rlogin: /etc/xinetd.d/rsh: /etc/xinetd.d/rsync: /etc/xinetd.d/swat: /etc/xinetd.d/tcpmux-server: /etc/xinetd.d/telnet: /etc/xinetd.d/time-stream: /etc/xinetd.d/uucp: /etc/xinetd.d/vncts: /etc/xinetd.d/xproftpd:
Some of these can be ignored -- the Kerberized services and those that already provide SSL capability.
I'm actually looking at doing this myself. If what I've said above makes sense, and you're willing to answer the occasional question (via this list), I'll take it on as a project. (Should be good practice for 429.)
Thanks!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ian Pilcher wrote:
Daniel J Walsh wrote:
Ok, I have been avoiding this. I have never used stunnel. Is it common for stunnel to start the application that is going to run within the tunnel? Or do you just setup the tunnel and the user then runs tools like rsync or telnet?
On the server side, stunnel can start the application in the same manner as [x]inetd. So my rsync over SSL setup works like this:
- Client - rsync connects to localhost:2873
- Client - xinetd accepts connection on port 2873 and execs stunnel
- Client - stunnel makes SSL connection to server:2873
- Server - xinetd accepts connection on port 2873 and execs stunnel
- Server - stunnel does SSL handshake with client and execs "rsync --daemon"
So do we need a rsync_domtrans(stunnel_t) to start the rsync server or does it just need to execute the client?
Here's what I think is needed (from the administrator's point of view):
A stunnel_var_lib_t for /var/lib/stunnel. FHS says that persistent state like a random seed goes in /var/lib. (This probably applies to most or all of the applications that use the OpenSSL libraries.)
A bunch of per-daemon booleans, stunnel_exec_foo. Each of these would enable filesystem access (/usr/bin or /usr/sbin) and execing the appropriate file type. The daemons should presumably run with the same context that they would if started by xinetd.
To get a complete(?) list of the xinetd daemons in Fedora 8, I've done the following:
yum install `yum provides '/etc/xinetd.d/*' | awk '{ print $1 }'` grep 'socket_type.*=.*stream' /etc/xinetd.d/* | awk '{ print $1 }' \ | sort -u
I get:
/etc/xinetd.d/apgd: /etc/xinetd.d/auth: /etc/xinetd.d/bitlbee: /etc/xinetd.d/chargen-stream: /etc/xinetd.d/cups-lpd: /etc/xinetd.d/cvs: /etc/xinetd.d/daytime-stream: /etc/xinetd.d/discard-stream: /etc/xinetd.d/echo-stream: /etc/xinetd.d/eklogin: /etc/xinetd.d/ekrb5-telnet: /etc/xinetd.d/finger: /etc/xinetd.d/git: /etc/xinetd.d/gssftp: /etc/xinetd.d/identtestd: /etc/xinetd.d/imap: /etc/xinetd.d/imaps: /etc/xinetd.d/ipop2: /etc/xinetd.d/ipop3: /etc/xinetd.d/klogin: /etc/xinetd.d/krb5-telnet: /etc/xinetd.d/kshell: /etc/xinetd.d/leafnode: /etc/xinetd.d/nuttcp: /etc/xinetd.d/pop3s: /etc/xinetd.d/pure-ftpd: /etc/xinetd.d/rexec: /etc/xinetd.d/rlogin: /etc/xinetd.d/rsh: /etc/xinetd.d/rsync: /etc/xinetd.d/swat: /etc/xinetd.d/tcpmux-server: /etc/xinetd.d/telnet: /etc/xinetd.d/time-stream: /etc/xinetd.d/uucp: /etc/xinetd.d/vncts: /etc/xinetd.d/xproftpd:
Some of these can be ignored -- the Kerberized services and those that already provide SSL capability.
I'm actually looking at doing this myself. If what I've said above makes sense, and you're willing to answer the occasional question (via this list), I'll take it on as a project. (Should be good practice for 429.)
Thanks!
Ok so stunnel needs to be able to exec and transition to everything that inetd can.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ian Pilcher wrote:
Running fully updated Fedora 8, trying to start stunnel from xinetd, and getting a couple of denials:
type=AVC msg=audit(1205149512.996:2338): avc: denied { write } for pid=14322 comm="stunnel" name="random_seed" dev=md1 ino=819429 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:stunnel_etc_t:s0 tclass=file
type=AVC msg=audit(1205149512.998:2339): avc: denied { name_bind } for pid=14322 comm="stunnel" src=2873 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
Aren't these things that stunnel should be expected to do?
selinux-policy-3.0.8-95.fc8.src.rpm
Adds stunnel_system_domain to inetd_system_domain, which will allow stunnel to transition to every domain that is defined as an inetd_system_domain.
Daniel J Walsh wrote:
selinux-policy-3.0.8-95.fc8.src.rpm
Adds stunnel_system_domain to inetd_system_domain, which will allow stunnel to transition to every domain that is defined as an inetd_system_domain.
Progress. Now getting a denial when rsync tries to read/write to the socket it gets from stunnel:
host=f8.example.com type=AVC msg=audit(1206311825.570:66): avc: denied { read write } for pid=2962 comm="rsync" name="[11108]" dev=sockfs ino=11108 scontext=system_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:system_r:stunnel_t:s0-s0:c0.c1023 tclass=tcp_socket
Thanks!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ian Pilcher wrote:
Daniel J Walsh wrote:
selinux-policy-3.0.8-95.fc8.src.rpm
Adds stunnel_system_domain to inetd_system_domain, which will allow stunnel to transition to every domain that is defined as an inetd_system_domain.
Progress. Now getting a denial when rsync tries to read/write to the socket it gets from stunnel:
host=f8.example.com type=AVC msg=audit(1206311825.570:66): avc: denied { read write } for pid=2962 comm="rsync" name="[11108]" dev=sockfs ino=11108 scontext=system_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:system_r:stunnel_t:s0-s0:c0.c1023 tclass=tcp_socket
Thanks!
Added in selinux-policy-3.0.8-97.
Daniel J Walsh wrote:
Ian Pilcher wrote:
host=f8.example.com type=AVC msg=audit(1206311825.570:66): avc: denied { read write } for pid=2962 comm="rsync" name="[11108]" dev=sockfs ino=11108 scontext=system_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:system_r:stunnel_t:s0-s0:c0.c1023 tclass=tcp_socket
Added in selinux-policy-3.0.8-97.
Finally had a chance to test this. Working now. Thanks!
selinux@lists.fedoraproject.org