riddle@woton.UUCP (Prentiss Riddle ) (02/02/88)
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@woton.UUCP {ihnp4,harvard}!ut-sally!im4u!woton!riddledhesi@bsu-cs.UUCP (Rahul Dhesi) (02/03/88)
In article <1023@woton.UUCP> riddle@woton.UUCP (Prentiss Riddle ) writes: >There is a security hole in the UA which you could throw a Cray >through.... >[And can anyone out there tell me what on earth the developers of the >UNIX PC were thinking of when they created this misfeature? The UNIX PC was supposed to be a personal computer (i.e. a computer owned and operated by an individual for the individual's own use) running UNIX. The lack of strenuous security is in keeping with this philosophy. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
riddle@woton.UUCP (Prentiss Riddle ) (02/04/88)
In article <2017@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > > The UNIX PC was supposed to be a personal computer (i.e. a computer > owned and operated by an individual for the individual's own use) > running UNIX. The lack of strenuous security is in keeping with > this philosophy. Sorry, but I don't consider that argument good enough. AT&T sold us the UNIX PC for use in a multi-user office/research environment, and its chief selling point was that it was a personal computer running UNIX. Any machine which runs UNIX should have (at least!) normal UNIX security. If we had wanted the vulnerability to error and abuse of the security-free DOS world, we would have bought a DOS machine. --- Prentiss Riddle ("Aprendiz de todo, maestro de nada.") --- Opinions expressed are not necessarily those of my employer. --- riddle@woton.UUCP {ihnp4,harvard}!ut-sally!im4u!woton!riddle
slocum@hi-csc.UUCP (Brett Slocum) (02/04/88)
In article <2017@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <1023@woton.UUCP> riddle@woton.UUCP (Prentiss Riddle ) writes: >>There is a security hole in the UA which you could throw a Cray >>through.... >>[And can anyone out there tell me what on earth the developers of the >>UNIX PC were thinking of when they created this misfeature? > >The UNIX PC was supposed to be a personal computer (i.e. a computer >owned and operated by an individual for the individual's own use) >running UNIX. The lack of strenuous security is in keeping with >this philosophy. In the literature I saw, the Unix PC was being touted as being able to handle up to 5 users. It was presented as a multi-user business machine. The Installation documents ask from the very start whether this machine was going to be used by multiple users. So I disagree with your statement that the Unix PC was for a single user. -- --Brett Slocum "Never bet with a Sicilian where Death is involved." UUCP: ...uunet!hi-csc!slocum Arpa: hi-csc!slocum@umn-cs.arpa UUCP: ...ihnp4!umn-cs!hi-csc!slocum (descending order of speed, I think)
alex@umbc3.UMD.EDU (Alex S. Crain) (02/05/88)
>Sorry, but I don't consider that argument good enough. AT&T sold us >the UNIX PC for use in a multi-user office/research environment, and >its chief selling point was that it was a personal computer running >UNIX. Any machine which runs UNIX should have (at least!) normal UNIX >security. If we had wanted the vulnerability to error and abuse of the >security-free DOS world, we would have bought a DOS machine. The unixpc *does* have unix security. I can break security on my unixpc just like I can on a vax 11-785 ! (:-) My solution to the UA security holes was to remove the UA from the system. Windows are too slow over a 1200 baud serial line. (I actually didn't remove it, just locked it up and left install as a ua driven user. When I'm onvinced that I no longer need it (real soon now) it will go away for good.) If this sounds to extream, I will point out that window shells in general are prone to security problems, the sperry sysV box we had at school took 20 minutes to break the first time we logged on (we didn't have accounts) and most of that time was waiting for the screens to set up! The best solution to a guest login is rsh, the best solution to a problem user is to install their home directory on a floppy disk. -- :alex. nerwin!alex@umbc3.umd.edu alex@umbc3.umd.edu
rich@bergy.UUCP (Bergstedt) (02/06/88)
In article <2017@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > In article <1023@woton.UUCP> riddle@woton.UUCP (Prentiss Riddle ) writes: > >[And can anyone out there tell me what on earth the developers of the > >UNIX PC were thinking of when they created this misfeature? > > The UNIX PC was supposed to be a personal computer (i.e. a computer > owned and operated by an individual for the individual's own use) > running UNIX. The lack of strenuous security is in keeping with > this philosophy. I don't think that this is a valid statement. A UNIX system is always going to be able to be accessed from remote terminals and this was a capability even with the original .5 MB Memory/10MB hard disk systems. I do believe that the original o.s. developers never expected the system to be as thoroughly analyzed as it is now. I believe the philosophy was to shelter UNIX $ access for naive users and make this system easy-to-use and administer. The intended user would never have known what was going on underneath the windows. The fire sale has changed all of this and opened up the O.S. to many of you who would never have even seen it without the low low prices. PLEASE NOTE THE DISCLAIMER - THESE ARE MY OPINIONS AND NOT THOSE OF MY EMPLOYER. -- +-----------------------------------------------------------------------------+ | Rich Bergstedt AT&T Data Systems Group | | voice: 714-855-5570 23421 S. Pointe Dr. #100 | | fax: 714-855-5690 Laguna Hills, CA 92653 | | uucp: ...uunet!ccicpg!arnold!bergy!rich -or- attmail!rbergstedt | | DISCLAIMER: These are my opinions, definitely not AT&T's. | +-----------------------------------------------------------------------------+
brant@manta.UUCP (Brant Cheikes) (02/14/88)
In article <114@hodge.UUCP> rusty@hodge.UUCP (Rusty Hodge) writes: >Let's face it: the UA is *evil*. Get rid of it. Hide it in a nested >directory and take away its execute privledges. Make it go away. For those who don't need to give ua access to "non-trusted" users, the simplest solution seems to be: 1. Create a new group in /etc/group, say "guest". 2. Put all non-trusted users in the guest group (all "trusted" users remain in the "users" group) 3. chgrp users /usr/bin/ua 4. chmod o-rwx /usr/bin/ua Now, only the superuser and members of the "users" group can execute the user agent. -- Brant Cheikes University of Pennsylvania Department of Computer and Information Science ARPA: brant@linc.cis.upenn.edu, UUCP: ...drexel!manta!brant
andys@shlepper.ATT.COM (a.b.sherman) (02/14/88)
In article <114@hodge.UUCP>, rusty@hodge.UUCP (Rusty Hodge) writes: > [Description of several well known holes in the UA] > > Let's face it: the UA is *evil*. Get rid of it. Hide it in a nested directory > and take away its execute privledges. Make it go away. > > Root will still be able to get to most of those nifty UA-run programs for > screen-oriented system administration. :-> But what if you like the convenience of the UA and multiple windows? There is a better way. The nasty piece of goods is a program called uasetx which resides in /usr/lib/ua. This is the guy who does a setuid to root for those things in the UA which are exec'ed that way. Here's what you do. Create a group called "super" or some such. Give uasetx group execute permissions for super and no others. Put yourself, (assuming you own the machine), install, and anyone you'd trust with your livelihood in group super. Change the group id for those logins in /etc/passwd and your in business. Presto. You have left everyone the convenience of the UA, left yourself the convenience of the dangerous stuff in the UA, and controlled access to those same functions. I hear that floppies can be a problem for your un-super user, but you can always access the floppy drive from a shell, or hack the UA files to not require root privileges to write to the floppy. Now then, doesn't your face look better with the nose still on it?? -- Andy Sherman / AT&T Bell Laboratories (Medical Diagnostic Systems) 480 Red Hill Road / Middletown NJ 07748 / (201) 615-5708 UUCP: {ihnp4,allegra,akgua,cbosgd,mtune....}!shlepper!andys INTERNET: andys@shlepper.ATT.COM
erict@flatline.UUCP (eric townsend) (02/14/88)
In article <114@hodge.UUCP>, rusty@hodge.UUCP (Rusty Hodge) writes: [Some stuff on security...] > Let's face it: the UA is *evil*. Get rid of it. Hide it in a nested directory > and take away its execute privledges. Make it go away. > > Root will still be able to get to most of those nifty UA-run programs for > screen-oriented system administration. :-> I agree, UA is evil. I use it on my console, but don't allow dial-ups to use it. A few comments: If you're going to have a multi-user UNIX-PC, make sure you trust the users and they trust each other. My last place of employment had no problem with security because everybody worked together. (The few rare times we multi-user'd a 3b1, that is.) Don't multi-user it. If you're going to have dial-up lines to run, say, a bbs, have the person execute the bbs on login and keep them away from shell access. Or just get rid of the 3b1 and buy a Connection Machine... :-) -- Just say NO to skate harassment. | Just another journalist with too much If I wish really hard, will IBM go away forever? | computing power.. Girls play with toys. Real women skate. -- Powell Peralta ad J. Eric Townsend ->uunet!nuchat!flatline!erict smail:511Parker#2,Hstn,Tx,77007
alex@umbc3.UMD.EDU (Alex S. Crain) (02/15/88)
In article <184@shlepper.ATT.COM> andys@shlepper.ATT.COM (a.b.sherman) writes: >In article <114@hodge.UUCP>, rusty@hodge.UUCP (Rusty Hodge) writes: >> [Description of several well known holes in the UA] >> >> Let's face it: the UA is *evil*. Get rid of it. >But what if you like the convenience of the UA and multiple windows? [solution involving super-group deleted] System security is a very real problem that doesn't have a quick & dirty (or quick and clean) solution. Unix is an open system with security holes up the wazoo, and closing the obvious ones only make the problem more subtle. Sorry, but someone who needs to ask about what to do with the UA simply isn't qualified to do battle with a experianced hacker, period. A large hidden issue is this: If a system admin closes all the holes that he knows about, then he won't have any idea how the hacker broke his system. So this approch doesn't work. The stock solution, regularly used for anonymous ftp, is to have two groups of users, trusted and not trusted. Trusted users are given a free run of the system, non-trusted users (guest logins, etc) get a restricted shell and very limited access to the system (see rsh(1)). Since a 3b1 will only support a few users, this should work for most cases, and after all, If I don't trust someone enough to think that he won't trash my system, who cares if he gets windows or not? For LANS and educational facilities, I prefer logs and traps that track problem users instead of barriers, but thats off the subject, really. -- :alex. nerwin!alex@umbc3.umd.edu alex@umbc3.umd.edu
dpw@unisec.usi.com (Darryl P. Wagoner) (02/16/88)
In article <794@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: > > A large hidden issue is this: If a system admin closes all the holes >that he knows about, then he won't have any idea how the hacker broke his >system. So this approch doesn't work. I am sorry that statement doesn't track. If you don't close all of the holes that you know about then you won't know if the hacker got in via the one you know about or another one. > The stock solution, regularly used for anonymous ftp, is to have >two groups of users, trusted and not trusted. Trusted users are given a free >run of the system, non-trusted users (guest logins, etc) get a restricted >shell and very limited access to the system (see rsh(1)). Since a 3b1 will >only support a few users, this should work for most cases, and after all, >If I don't trust someone enough to think that he won't trash my system, who >cares if he gets windows or not? Don't trust rsh(1) to work the way you would hope. It is childs play for any hacker worth his salt to break out of the rsh(1). chroot(1M) is the best way to contain a user, but beware it has a few risks itself. Mainly because you must have and protect the /chroot/etc directory the same as you would the real one. On the problem of UA, one solution maybe a program that will check out what the user is passing to uasetx & uasig and reject or accept it base upon the user, the group that user, and where he is logged in. Uasig may not be a problem, but it is a setuid program and should be checked out. At some point I may write this program but it will be a while. -- Darryl Wagoner dpw@unisec.usi.com UniSecure Systems, Inc.; OS/2, Just say No! Round Rock, Tx; (512)-255-8751 (home) (512)-823-3774 UUCP: {ut-sally!uiucuxc!kitty}!unisec!dpw