Starting stunnel from xinetd

[Ian Pilcher]

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!

-- 
========================================================================
Ian Pilcher                                         arequipeno at gmail.com
========================================================================