Re: [ITA] inetutils-1.5-1

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Feb 24 22:07, Charles Wilson wrote:
> As suggested by Corinna here:
>   http://cygwin.com/ml/cygwin-apps/2008-02/msg00097.html
>> I won't update inetutils anymore, except for tiny fixes and packaging
>> stuff.  Actually I'd rather OBSOLETE it entirely.  syslogd is replaced
>> by syslog-ng and all other tools in inetutils are security holes all in
>> itself.  Barring that, I could create a new inetutils package which
>> doesn't install logger.  Logger has not even a single Cygwin specific
>> patch in it.
>> So, here's the choice:
>> 1. Remove logger from inetutils.
>> 2. Remove inetutils from the distro.
>> 3. Another maintainer creates a new inetutils package using the latest
>>    upstream sources.
>
> I'm tossing my hat in for #3.  It's basically a new port, using the 
> previous patches (1.3.2-37 vs. upstream 1.3.2) as a guide, because none of 
> the patches seemed to apply cleanly, and there were other issues as well.

Yippee!  Charles, there is no number of gold stars in the known universe
to express my gratitude :)))

> Actually, I /agree/ with Corinna that none of these tools (with the 
> possible exception of inetd itself, and syslogd [1]) should be used in a 
> security-conscious installation.  However, we live in the real world

Uh, that... Well, the real world is just *one* tiny place, no?

> telnet/rsh are not going away...and if cygwin lacks these tools, it will be 
> viewed as a bug, not a feature.
>
> [1] which can be replaced by xinetd (although that is unmaintained) and 
> syslog-ng
>
> http://cygwin.cwilson.fastmail.fm/ITP/inetutils-1.5-1.tar.bz2
> http://cygwin.cwilson.fastmail.fm/ITP/inetutils-1.5-1-src.tar.bz2
>
>[...]
> But that shouldn't stop you from d/l them, checking out the packaging, 
> maybe testing individual .exe's, etc.  When I /do/ upload these, they will 
> be in test: for a good long while...

For a start, maybe you should change the default motd.  I just couldn't
think of something better way back when, but the message is rather
boring, isn't it?

And, maybe it's time to start to be more cautious by default and
disable all service entries in /etc/defaults/etc/inetd.conf?

A few minutes ago I found a security problem with rshd.c which I just
fixed by uploading 1.3.2-40, and which you copied verbatim into the 1.5
rshd.c:

@@ -763,8 +799,12 @@
        exit (1);
       }

+#ifdef __CYGWIN__
+  seteuid(getuid());
+#endif
+

If seteuid fails, rshd should bail out.  In 1.3.2-40 I changed that to

#ifdef __CYGWIN__
        if (seteuid((uid_t)pwd->pw_uid)) {
                error("Switching to user %s failed!\n", remuser);
                exit(1);
        }
#endif

This problem does not occur when you install inetd on NT4/2000/XP.
However, here's the awkward truth:  rsh and rcp won't work anymore when
you're running inetd under SYSTEM starting with Windows 2003.  The
reason is that services under SYSTEM don't have the "Create a process
token" user right anymore starting with 2K3.  That's the whole reason I
intruduced the "sshd_server" user in the ssh-host-config script.
What's especially embarrassing with this is, that it *never* occured to
me until today, that this is also a problem for rshd :-P

Since the check if seteuid fails is missing so far, you will run rsh
commands under the SYSTEM account for every user on 2003 upwards!

In -40 I changed the description in inetutils-1.3.2.README substantially
to explain this problem.

> (3) Added a new option to inetd: -T/--traditional-daemon, which does the 
> regular fork/daemonize behavior.  This is used with the (also provided) 
> sysvinit-style startup script, so that inetd can be run under the control 
> of the sysvinit package's init daemon.  So now, there are THREE ways to run 
> inetd as a service:
>   a) install as a service using cygrunsrv (with the -D option)
>   b) installed as a service under its own power
>   c) as a slave to the init service, using /etc/rc.d/init.d/inetd (which
>      uses the -T option when invoking inetd)

Given the problem with the SYSTEM account, maybe we should deprecate 
usage b.  Maybe an install script (iu-config?) could do something
along the lines of the ssh-host-config script.  I would be willing
to switch the ssh-host-config script from the "sshd_server" user name
to something like "cygwin_svc" or so.  And maybe the iu-config script
could re-use the sshd_server user if it already exists...


Thanks again for doing this,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat