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.