|
|
telnetd and inetd on Windows NT with OpenNT
by Rodney Ruddock Rodney Ruddock is a developer of OpenNT at Softway Systems.Several years in the UNIX and POSIX/XPG realm have pulled him deeper into the kernel far away from his degree in Human-Computer Interaction.
and Stephen Walli Stephen Walli is vice-president of R&D at Softway Systems and author of Go Solo: How to Implement and Go Solo with the Single UNIX Specification (1995). He has been USENIX's Standards Report Editor and Institutional Rep to the IEEE POSIX committees.
Currently, businesses are faced with the decision to deploy Windows NT. This new operating system promises a robust environment to solve many business application problems, as well as provides a platform to run the many Win32-based packages they count on, all on a price-competitive platform. Organizations are then faced with a set of problems:
This article takes a look at one approach to the overall problem, briefly presenting the technology (OpenNT) and its application to providing telnetd and inetd. OpenNT In September 1995, Softway Systems Inc. entered into a long-term agreement with Microsoft to extend the Microsoft POSIX environment subsystem into a complete traditional UNIX systems environment. The Windows NT operating system is structured in a microkernel-like design with subsystems layered on top of the kernel. Some subsystems are functional subsystems (e.g., the security subsystem); others provide programming and user interface environments. The Win32 user interface and programming environment are provided through the Win32 subsystem. Softway System's technology is provided under the name OpenNT. The OpenNT environment subsystem replaces the less functional, restricted Microsoft POSIX subsystem and provides the user interface and programming environment found on traditional UNIX systems. With the release of OpenNT 2.0 in May 1996, the OpenNT subsystem provides the following functionality:
The OpenNT subsystem is structured to use the same high-speed facilities for communications between subsystems and the kernel and processes and their subsystems as the Win32 subsystem, so there is no appreciable performance penalty. OpenNT has been designed to ensure it does not in any way compromise the integrity of Windows NT (e.g., security). The architecture of OpenNT allows it to integrate cleanly with the Win32 subsystem. The two subsystems integrate through the desktop, filesystems, IPC mechanisms such as pipes and sockets, and the ability of OpenNT processes to exec Win32 processes (allowing easy access to Windows NT specific functions via shell-scripted interfaces). One of the early daemons requested by customers was a "better" telnet service than those available on the market. This drove the integration of pseudoterminals into the OpenNT subsystem. The telnet "service" had to work cleanly as a Windows NT service. Once this work was finished, the next question was "why not inetd?" The next sections describe the effort to bring traditional UNIX daemons over to Windows NT using OpenNT, running them as OpenNT processes, and managing them as services in the Windows NT world. Porting telnetd to OpenNT Telnetd is a system daemon that allows a user from a remote location to connect to the system. Telnetd does this in a couple of steps. First it handles the authentication of the user being allowed to login to the system. While doing this, telnetd does a certain amount of perturbation against users who are attempting to break into the system with an iterative attempt password-guessing algorithm. Once the user is authenticated, a shell is started with a controlling terminal for the user. Finally, telnetd provides the communications pathway for the remote user to communicate with the shell. It continues to provide this step until the user's session ends. OpenNT derives its telnetd from the 4.4BSD source code. The code has seen a number of years of actual use and is very stable and complete in its functionality. The port of the telnetd code began while pseudoterminal support was being developed in the system. Pseudoterminals, or ptys, are a requirement for telnetd to work with the correct semantics. It was known a priori that certain APIs called from the telnetd source code were not going to be immediately supported for OpenNT 2.0 and were commented out (specifically, the syslog functions, which will be available at the end of November 1997). It was also known that the NT security model is quite different from the traditional UNIX model. Specifically, user authentication does not occur against /etc/passwd, and setuid() does not have the same power as on traditional UNIX systems. On traditional UNIX systems, "root" is a special user with the authority to do anything. But the same intent can be accomplished by other means while maintaining a tighter security model. With OpenNT, this is done with an extended set of exec() APIs named exec_asuser(). This does not cause a change in the telnetd code; rather it causes a change in the method of the user obtaining a shell. (It did cause a simple change in the login source code.) The exec_asuser() interfaces accept the same arguments as traditional exec() interfaces with an additional argument for user and password. This allows for the exec() of a program with the security profile of the named user, provided that the password is valid. If the security of the original process becomes compromised (refer to CERT notices for examples), the perturber gains only the security profile that the process has not the security profile of a user that allows anything to be done (i.e., "root"). With OpenNT the process performing the exec_asuser() is usually restricted from obtaining key information about any user. Such data are needed to correctly set up the user's environment. To allow for the correct environment construction, OpenNT has a utility named loginenv(1). Instead of exec()'ing the user's shell directly, loginenv is started with arguments that include the user's shell. Because loginenv will be running with the security profile of the intended user, it is allowed access to the information about the user. loginenv, after setting up the environment, performs the exec() that will start the user's shell. The shell then inherits the correct environment information from loginenv. The testing of the port of telnetd was as much, if not more, of a validation of correct pty semantics and behavior as it was of correct telnetd functionality. Once the full support of ptys had been finished, the additional code changes outside of syslog interfaces were few. The changes centered around included header files, how telnetd itself is started, and the addition of an NT-specific login message. The header files changes were <termio.h> to <termios.h> (the POSIX standard). The change for how telnetd itself starts is not OpenNT specific. The changes made are just as functional on any other traditional UNIX system. Historically, telnetd is started only from inetd. A debugging mode is available when started from the command line, but this limits the functionality of telnetd. telnetd was changed so that it can be started from a shell command line with full functionality. Essentially, the debug mode code was extended. This resulted in the addition of some child management code that would normally be handled by inetd. The change also allows telnetd to be added to the Windows NT services control panel via the Windows interface or through an OpenNT utility named-service. With this ability, telnetd can be started automatically when the system is rebooted. This is particularly useful for system administrators needing to interact with machines from a remote location. The final change was the addition of an information message to explain how NT domains and usernames can be specified together when logging on to a machine. This allows user authentication against the Windows NT domain model. We felt the message was necessary because the Windows NT login authentication was different from what a traditional UNIX user is accustomed to. The alterations were restricted to this so that users employing automatic login scripts (like expect) would not have to make changes. The Porting of inetd to OpenNT Like telnetd, the source code base for inetd is 4.4BSD for OpenNT. Currently, inetd is running internally at the OpenNT lab and is expected to be released in the next update (expected in the fourth quarter of 1997). The changes needed for the porting of inetd can be divided into three parts: updating some of the code to standard POSIX interfaces, removing code not needed (because it is also not supported), and OpenNT-specific issues. The updating of portions of the code to the POSIX standard centered on the changing of a wait3() API call to a waitpid() and changing main to take two arguments (argc, argv) instead of three (argc, argv, argp). These minor changes took literally a couple of minutes and improve the overall portability of the source code. Inetd traditionally reads the inetd.conf file to determine which user the child daemon process should be run as. However, as explained earlier, there is not an "all capable" user (root) that can change identity at will. So this class of code was commented out. In the vast majority of cases, inetd does not need a root-level ability. Running inetd as a user with a restricted security profile has its security advantages, too. So the functionality of inetd and its child processes has not been unduly affected. Changes that are OpenNT specific relate entirely to pathnames. For users accustomed to moving from one system to another, this is not surprising. In the inetd.conf file the paths to the utilities that are related to the socket ports that inetd monitors had to be changed. The pathnames still appear as on a single-rooted filesystem. However, all installations of OpenNT do not have the same root. Windows NT supports the same disk model with letters applied to volumes as DOS and Windows PCs. Often users and Windows NT administrators will want to install certain packages on certain volumes. So the OpenNT world is rooted at $OPENNT_ROOT, and some source code expecting there to be a /bin directory with particular applications is "surprised." (A future release of OpenNT will provide full single-rooted filesystem semantics.) To accommodate a configurable install root, two interfaces are used to turn a single-rooted pathname to the installed root pathname: _prefixInstallPath() and _getInstallPath(). The _getInstallPath() function was used to change the one occurrence of chdir("/") to chdir(_getInstallPath()). The _prefixInstallPath() function was used in two places in total: (1) for the location of the inetd.conf file and (2) for rooting the path of utilities named in the inetd.conf file. Inetd can be managed via the Windows NT service manager application or the OpenNT utility as a Windows NT service. Inetd can be set to run as an automatic service at system boot time, just as with telnetd (i.e., inetd will be started immediately when the system has been rebooted). This has the same advantages for system administrators as mentioned earlier. In the OpenNT lab, the inetd.conf is running with a number of daemons (e.g., ftpd, ntalkd, and telnetd). And the built-in services on well-known ports are also fully functional (e.g., time on port 13). The porting of ntalkd consisted of pathname changes in a more minor sense than with inetd and the use of utmpx (currently active in the OpenNT lab) instead of utmp. The number of lines of change is fewer than ten most of those dealing with utmp to utmpx changes (as OpenNT follows the XPG standard). Summary Porting applications and tools developed on traditional UNIX systems to Windows NT with the OpenNT runtime environment is straightforward. This includes more complex applications like inetd and telnetd that can be run as Windows NT services and require integration into the Windows NT security and authentication model. For more information about the OpenNT architecture, please see the paper "OpenNT: UNIX Application Portability to Windows NT via an Alternative Environment Subsystem," presented at the USENIX Windows NT Workshop, August 1997, Seattle. Complete up-to-date information about OpenNT can be found at <http://www.OpenNT.com>.
|
 Need help? Use our Contacts page.
First posted: 3rd December 1997 efc Last changed: 3rd December 1997 efc |
|
Issue index