Starting stunnel from xinetd

[Daniel J Walsh]

-----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:
> 
> 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!
> 
Ok so stunnel needs to be able to exec and transition to everything that
inetd can.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfgCE8ACgkQrlYvE4MpobPmeQCgtLiVSWV0sjPktQQOYuUhVxtV
ZTEAn0ogmiO7A9dtLbImLANAVihx1CdR
=oAJo
-----END PGP SIGNATURE-----