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.