Major security problem in the UA: looking for a real fix

[Prentiss Riddle]

This has been discussed on the net before, but I want to raise it
again:

There is a security hole in the UA which you could throw a Cray
through.  If an Office menu has an entry "Run=EXEC -p $SHELL", the
shell is invoked with superuser privileges.  Anyone can create an
Office file in her home directory and become root at will. 

This "-p" option (documented in section ua(4) in the manual) is used
extensively in the UA menus.  It is what allows the user "install" to
do many administrative tasks ordinarily reserved for root.  It also is
used for many more mundane things, such as floppy operations, which
ordinary users need to be able to do. 

Darryl Wagoner (unisec!dpw) some time back proposed the following
solution to the problem: the UA grants superuser privileges via the
setuid programs /usr/lib/ua/uasetx and /usr/lib/ua/uasig.  If these
programs are chmod'ed to 4710 and put in a group "super" and only
trusted users (ideally just "install") are put in the "super" group,
then the -p option won't be available to non-trusted users. 

I tried this, with mixed results.  Users in the "super" group were able
to get superuser status as before, but other users lost the ability to
invoke the following items in the UA menus:

	Administration: Change Password
	Administration: Disk Backup
	Administration: Disk Restore
	Administration: Mail Setup: Electronic Mail Name of Other Systems
	Administration: Mail Setup: Electronic Mail Name of This System
	Administration: Software Setup
	Administration: System Information
	Floppy Disk Copy
	Floppy Disk Format
	Floppy Disk Repair
	MSDOS Disk Format
	MSDOS Disk Read
	MSDOS Disk Write
	Printer Queue
	Printer Restart
	Printer Setup

In addition, the ordinary small Unix window invoked by "Run=EXEC -w
$SHELL" would no longer work, although a large borderless "Run=EXEC -wd
$SHELL" would work correctly. 

Some of the affected menu items are security risks in themselves and
probably should not be available to unprivileged users (mail and
printer setup, for instance).  Others are not so expendable: all of our
users need to be able to format floppy disks and do backups and
restores, at least of their own files. 

I also tried simply turning off the setuid bit on "uasetx" and "uasig",
but leaving them executable by everyone.  This was even worse: the
programs would run, but they would run incorrectly -- in particular,
floppy backup operations would fail with a message about the disk being
full when it really was at 70% capacity. 

So we're back at the drawing board.  I don't see any reason why it
should not be theoretically possible to fix these problems.  Most of
the floppy-oriented functions should not need special privileges to
work.  Most if not all of the programs which really require superuser
privileges should not be available to non-superusers anyway.  I've
never seen the rationale behind the "install" user -- why wasn't
install's "Administration" menu simply given to root?  Root is capable
of running the UA too. 

So, are any of the UNIX PC hackers out there interested in tackling
this problem and coming up with a real solution?  (By rights, AT&T
ought to recognize this as a major bug and fix it, but given the status
of the UNIX PC I'm not holding my breath.)

[And can anyone out there tell me what on earth the developers of the
UNIX PC were thinking of when they created this misfeature?  Did they
really think it so necessary to be able to provide root privileges at
the drop of a hat that they thought it was worth creating a security
hole the size of a barn door?  Or did they just not know what they were
doing?  :-( ]

--- Prentiss Riddle ("Aprendiz de todo, maestro de nada.")
--- Opinions expressed are not necessarily those of my employer.
--- riddle at woton.UUCP  {ihnp4,harvard}!ut-sally!im4u!woton!riddle