ARPUS/ce, Version 2.6.2 (03/10/05) (SCCS 1.4) _______________________________________________________________________________ Concept: Security considerations DESCRIPTION: On some machines, it is required that ceterm run as root. This document describes the functions which require root authority. More importantly, it covers considerations related to using Ce from a root account or any other sensitive account. SETUID The need for root authority is limited to the setup and bring down of the ceterm terminal emulation. This is the same thing xterm needs the setuid for. Because ce can start ceterm's from the command input window with the 'cp' or 'ceterm' command, it is not practical to isolate the ceterm module. Ce does the things it needs to do as root and reverts to the calling user. During the short sequences where Ce has setuid on, it is not accepting any input from the user. The need for the setuid privilege is as follows: HP/UX, DEC Ultrix, Sun Solaris 2.3 Root authority is needed to open and change the ownership of the pseudo tty's used to access the shell. It is also needed to update the utmp entry for the ceterm session. IBM RS6000, DEC OSF1 Root authority is needed to access the utmp entry. Ce could be run without the setuid, and it will simply not update the utmp entry. This will prevent the who command from showing the user and on some machines will prevent the passwd command from working. Sun OS 4.1.3, Apollo Domain OS 10.3.5 Ce normally is not run with a setuid as neither the pseudo tty's nor the utmp require special authority to open it. The program functions the same on these machines and setting the setuid bit will not cause a security exposure. A recent Sun bulletin for 4.1.3 noted a security hole related to the ability to update utmp entries and suggested making the utmp file updatable only by root. If this is done, you will need to set the setuid bit for ceterm. OPERATIONAL CONDISERATIONS: The primary hole through which security can be violated is the xhost command. If you allow anyone to open your display, they can access your windows and thus access your files. This is especially true in the case of Ce, which supports the 'xdmc' command. While xdmc will not send commands to a window owned by another user, someone could circumvent this. The bottom line is to avoid opening your display to arbitrary users. Unless X cookies are being used, a person who can telnet to your node can open your display. This means he can send keystrokes and mouse clicks and other events to your windows. Program like xterm and ceterm filter out such events. Additionally, xdmc will not send a request to a window not owned by the same uid as it is running under. One case where it is desirable to open the display is when you telnet to another node and then want to open a ceterm back to your display. One technique is to set up a shell which opens the display for the host your are interested in, starts the ceterm via rsh (or remsh) and relocks the display. This minimizes the exposure. CC -DISPLAY You can create a carbon copy of an edit session or transcript pad to another display. This can be really handly when you want the person in the next cubical to proof read something for you. It is also useful if you are providing support and a person who is at some distance from you calls for help. You can have them cc their ceterm over to you and you can see what they type while they are still on the phone. The risk is straightforward. When you cc a window to another node, there is still only one process. This process is running as the originator of the cc. From the Ce "Command:" window, you can start other processes and those processes will run as the originator of the cc. The question becomes do I trust the person I am sending a cc window to to be able to create a process as me? _______________________________________________________________________________ Copyright (c) 2005, Robert Styma Consulting. All rights reserved.