Inetd and the Rutils

  • Article

Operating System

Services for Unix/Interix 3.0 Technical Note

Abstract

This document summarizes the use of the Interix inetd "super server" daemon and the related daemons that can be started with inetd. Complete information about each daemon can be found on its reference “man” page (for example, man inetd).

This document is specific to the Microsoft Windows Services For UNIX 3.0 product.

On This Page

Inetd and the Rutils Inetd and the Rutils
For More Information For More Information

Inetd and the Rutils

The Services for UNIX 3.0 product includes the Interix subsystem and utilities which provide a UNIX environment on Windows. One of the utilities distributed with Interix is the inetd “super server” daemon and the related networking daemons that it can control. This paper provides some general information about these daemons. Complete information on each daemon can be found in its reference (or “man”) page that is distributed with Interix (e.g. man inetd).

The following "daemons" are controlled by inetd:

/usr/sbin/in.fingerd
/usr/sbin/in.ftpd
/usr/sbin/in.ntalkd
/usr/sbin/in.rexecd
/usr/sbin/in.rlogind
/usr/sbin/in.rshd
/usr/sbin/in.telnetd
/usr/sbin/in.tftpd
/usr/sbin/popper

Note that all of the daemons are in the subdirectory /usr/sbin. Users with a BSD background may be surprised by the daemon names, which conform to the System V convention. Man pages are available under their "generic" name (i.e., man telnetd instead of man in.telnetd).

What is Inetd?

Inetd is a "super server" daemon used to manage many different networking services such as telnetd, rshd, and ftpd. This daemon reduces system load by invoking other daemons only when they are needed and by providing several simple network services internally without invoking other daemons. Inetd may be thought of as a doorman: when someone knocks at the door inetd answers the door and then gets the program that the caller is seeking.

In more technical terms, inetd listens for remote connections to TCP/IP sockets with well-known addresses. Each well-known address is associated with a specific service (e.g. ftpd is associated with port 21, telnetd with port 23). Once a remote request is detected, inetd starts the appropriate service for that well-known port. The freshly-started service then picks up the socket connection(s) and performs the entire protocol/data-exchange specific to that service.

The Inetd Configuration File

The services that inetd can start are specified in the configuration file /etc/inetd.conf. The default installed inetd.conf file contains a list of services but each service is commented out which disables all these daemons. To enable one or more daemons you will need to edit the /etc/inetd.conf file. (See Enabling and Disabling a Daemon, below).

It is important that the correct ownerships and permissions are maintained on this configuration file. It must have the group ownership of +Administrators and it must be group writeable. So we suggest a mode of 664 (or rw-rw-r-- ).

On Windows systems the first 1024 TCP/IP network ports are reserved or protected for privileged processes like they are on UNIX systems. This is a security problem on Windows because an untrusted, unprivileged user process could acquire the port of a well known network service (i.e, telnetd, rshd or ftpd) and masquerade as that service in order to obtain secret information from unsuspecting users. For enhanced security an extension to Interix 3.0 inetd was added called camping. This camping feature is port specific and can be enabled via the configuration file /etc/inetd.conf Camping tells inetd to acquire a network port and hold onto it so that no other process can use it. More information about this feature can be found in the inetd configuration file /etc/inetd.conf.

Security and Inetd

In Services for Unix 3.0, the Interix inetd daemon is started by the init process, and runs in the security context of the local Administrator. The init process is started automatically when the Interix subsystem starts. The Interix subsystem starts up automatically when the first Interix application is invoked.

If the inetd daemon is running as local Administrator then all the daemons or servers it starts will also run in the security context of local Administrator. This is necessary for several daemons because they depend on running in a privileged context. Daemons such as in.ftpd (anonymous access only), in.rshd and in.rlogind all may create new processes that are impersonating other users without the use a password1. Or they may require the use of privileged system calls. Or there may be daemons such as in.talkd which require specific access rights to device files in order to work properly.

In earlier versions of Interix, for example Interix 2.2, many daemons, such as inetd, cron and syslogd, were installed as Windows services because there was no mechanism to automatically start them. In Interix 3.0, with the implementation of the init process this is no longer necessary. When upgrading Interix 2.2 to Interix 3.0 these old services are automatically disabled.

In Interix 2.2 it was also possible to run the inetd daemon in the context of an unprivileged user account. Daemons such as in.rlogind and in.rshd were implemented differently in Interix 2.2 due to the limited privilege and security features in that older release. For example a user could store their password in a personal .password file in their home directory and as long as the daemons had read access to this file they could successfully impersonate the user by using this password. In Interix 3.0 the .password file is no longer used. User passwords are now stored in a secure place in the Windows registry and only privileged processes can save and retrieve them. Saving this password is done using the regpwd utility.

In Interix 3.0 it is no longer recommended to install the inetd utility as a Windows service or execute as a non-privileged user. Many of the daemons that inetd starts require local Administrator privileges in order to work properly.

Enabling and Disabling a Daemon

You may wish to enable (“turn on”) or disable ("turn off") one or more of the daemons. To do this, login as local Administrator and edit the configuration file, /etc/inetd.conf. To disable the daemon place the comment character "#" at the beginning of the line listing the daemon you wish to turn off. To enable the daemon just remove this comment character. Then save the file. Remember to check that file permissions are correct for security reasons (mode 644, "rw-r--r--").

Now stop and restart the inetd process by typing the following commands still logged in as the local Administrator:

cd /etc/init.d
sh inet stop
sh net start

Specific Daemon Notes

The utilities and daemons in this package are ported from traditional Berkeley sources, so they pretty much behave as you might expect. There are some differences, described here.

Ftpd

Starting in Interix 3.0 ftpd supports "anonymous" access. To enable it you must create a user account with the name “ftp”. If the system is a member of a Windows Domain then this account must be a Domain account. Otherwise this account must be a local user account. Note that in a Domain environment, creating the “ftp” Domain account will automatically enable anonymous ftp access on all Domain member systems that have enabled ftpd2.

Inetd

The inetd process starts up automatically via the /usr/sbin/init process that gets started when the Interix subsystem boots. The inetd process will be run in the context of the local “Administrator” which is a requirement in order for many of the Internet daemons to work properly; such as the in.rshd, in.rlogind and anonymous access using in.ftpd.

Note that in the inetd.conf file the "user" column has "NULL" in it. Interix inetd ignores this column for security reasons. This column is maintained in the configuration file for portability.

Ntalkd

The protocol for talk is that user names are at maximum 11 characters long followed by a terminating "\0" (NULL). The protocol cannot be extended for longer names. Long character names which are not unique until after the 11th character present problems—both "Administrator" and "administrator3" will match. In this case, specify the tty argument with your talk request.

Ntalkd matches usernames in a case-independent manner since the canonical user name may not be in the case expected by the caller. This is similar to mail protocols and should therefore be more like what the user expects.

Rcp, Rlogin, Rsh, In.rlogind, In.rshd

By default, the supplied inetd.conf configuration file has in.rlogind and in.rshd start up with the -a option. This option directs the daemons to perform additional checks on the caller’s hostname in order to validate and verify that the hostname matches the caller’s IP address.

These daemons examine the files /etc/hosts.equiv and .rhosts to determine if requests can be authenticated without a password. If the ownerships or permissions on these files are not correct, the programs will not use the contents of the files.

Both in.rshd and in.rlogind support the –l option which will cause the authentication lookups in the user’s .rhosts files to be skipped. This does not affect the lookups in the /etc/hosts.equiv

When Interix is installed the file /etc/hosts.equiv is not created automatically. If you want a hosts.equiv file, you must create it yourself. The file must be a regular file with write permissions granted only to those that require it – like the owner and maybe the group. The recommended owner and group would be local Administrator and group Administrators..

When using the client programs rlogin, rsh or rcp, the usernames that are sent to the remote server are the user’s basename, such as “john” and not the fully qualified name such as domain1+john. How this basename is treated on the remote server will depend on whether it is a UNIX or Windows system. On a Windows system it will be treated in the usual way that Interix treats all other basenames on that system and that will depend on the Interix “principal domain” and whether the remote system is a member of the same domain or not. When connecting with another Interix system, the fully qualified user name is useful, especially if you're using .rhosts files and you want to be absolutely sure that you’ve granted the correct user access. Therefore the clients have been extended to support a -D option, which ensures that fully qualified names are transmitted to the remote server. If you also use the -l command line option, the argument to -l always takes precedence as the remote username.

For the password-free authentication mechanism to work both the rshd and rlogind daemons must be able to read the target user’s .rhosts file and must be able to impersonate or create a security context for that target user. To facilitate this the target user is supposed to register their password on the target system in a secured area where they can be retrieved by the privileged daemons. This is done via the regpwd utility. Every time the user changes their password this regpwd utility must be executed. The daemons use the password to switch to the target user’s security context and then they examine the user’s .rhosts file to perform the password-free authentication checks. By switching contexts there is a better chance the daemon can access the user’s .rhosts file especially if the user’s home directory is on a network file system.

The .rhost file must be located in the user’s home directory. If the user’s home directory is on a network file system it is important that the user’s home directory (in the Windows account database) is not specified using a drive letter – it must be specified using a Windows UNC path (\\machine1\share1\path) which Interix will convert into its own network format (i.e. /net/machine1/share1/path). The reason that network drive letters do not work is because in.rshd and in.rlogind do not mount any driver letters during the login process.

There are some caveats with the SFU/Interix 3.0 distributions3. Both in.rshd and in.rlogind have a bug where the stored passwords from regpwd can never be properly retrieved. This means that

  • A fully validated, Windows authorized security token for the target user can never be created unless the rlogind daemon prompts for the password explicitly.

  • Interix provides a mechanism where user contexts can be created without a password. But the security token created in this case has some limitations. For instance on some systems a security token cannot be created for Domain accounts but should be successful for all local accounts. And the security token created will not be suitable for access to some or all network resources.

  • the user’s home directory must be on a local file system for the rhosts mechanism to work.

Rexecd

The rexecd daemon services network requests using the rexec protocol.

In the SFU/Interix 3.0 distributions (build 7.0.1701.1 and 7.0.1859.1) this daemon has a bug such that it doesn’t implement the protocol properly and service requests may appear to freeze or “hang”. This will occur if the caller makes a request to establish an auxillary communication channel. All other requests are successful.

Talk

Talk ensures that the requesting user's username is all in lower case. The target user's username is left as written on the command line. This is done to ensure maximum compatibility with other talk daemons and makes users on other systems happier when they connect for the talk session.

Telnetd

In earlier versions of Interix (Interix 2.2) the default behavior of telnetd was to run as a Windows service not as a daemon. Starting with Interix 3.0, in.telnetd was changed to support a -i option ("inetd"). This allows it to be started from inetd. If you make changes to the inetd.conf file, ensure that the -i option accompanies telnetd in the last column, as specified on the telnetd man page.

Also in earlier versions of Interix there was a copy of the telnet daemon in /bin/telnetd. This file is no longer present. The daemon is now located only in /usr/sbin/in.telnetd.

Tftpd

By default, in.tftpd is disabled in the inetd.conf file. If you want to activate in.tftpd, read the reference page first. There are security concerns.

For More Information

For more information about Interix, see the following Web sites:
https://www.microsoft.com/technet/interopmigration/unix.mspx
https://www.microsoft.com/technet/interopmigration/default.mspx

1 For in.rlogind and in.rshd, they use the files /etc/hosts.equiv and personal .rhosts to authenticate access rather than passwords.

2 As of August 2003, versions 7.0.1701.1 and 7.0.1859.1 of in.ftpd require a Domain ftp account when in a Domain environment. It is possible that newer versions may be changed to look only for a local ftp account.

3 These caveats are valid for at least SFU 3.0 ENG (version 7.0.1701.1) and SFU 3.0 JPN (7.0.1859.1)