Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!convex!swarren
From: swarren@convex.com (Steve Warren)
Newsgroups: comp.unix.amiga
Subject: Re: interesting feature on AMIX..
Keywords: unix security, amix security, setuid
Message-ID: <1991Jun24.005213.944@convex.com>
Date: 24 Jun 91 00:52:13 GMT
References: <426@hfsi.UUCP> <1991Jun21.201119.722@ckctpa.UUCP> <431@hfsi.UUCP>
Sender: usenet@convex.com (news access account)
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Lines: 55
Nntp-Posting-Host: neptune.convex.com

In article <431@hfsi.UUCP> frank@hfsi.UUCP (Frank McPherson) writes:
>Would you have to meddle around with the KSH to make it set-uid to root?
>My point here is, if you started up a ksh, even if from your own file
>system, shoudn't it disallow you to setuid to root?  If not, that is a 
>pretty serious security hole in the way we're doing things.

You don't need to execute ksh to make it into a setuid executable.  That is a
quality of the file, like the protection bits.  You change this using the
chmod command.  Once the file that is the ksh executable is chmod'd to setuid
to root, it of course will do this every time this file is executed.  That is
why such files are jealously guarded by good sys-admins.

On a machine in which you do not have super-user permission you would not be
able to chmod any files to setuid-root.  However, on your own personal
property machine you would of course be the super-user.  You could create
setuid-root files to your heart's content.  What is at issue here is the
concern that you could transfer this file to another system without your
permission to do so being questioned.  The new system, believing that only the
super-user has permission to *create* such files, would not hesitate to
perform the setuid-root operation when any file with the setuid-root mode was
executed.

The idea of security is that the OS must be able to supervise the permissions
of all files introduced by non-root users.  This means that any scheme
allowing non-root users to mount filesystems must include a bullet-proof way
of verifying the permissions of all files on the new filesystem.

Once they are verified there must also be a check to make certain that the
user does not mount a filesystem and then swap disks with an identical
filesystem, but different permissions on the identical files.  The Amiga
should permit this extra check, because it monitors the floppy drive, and it
is possible to note each time a floppy is removed from the system.  At that
point the user-mounted filesystem should be unmounted, because once the floppy
is removed from the system there is no guarantee that the disk will be
returned unmodified.

>                                                     ...    I'm not 
>sure that it really MATTERS, because the machines aren't incredibly
>important anyway, and there aren't any overwhelming reasons for someone
>to want root access on one of them, other than just saying they did it.

Well, if these machines are being used for classwork then what this security
hole means is that any student who is sufficiently motivated may gain access
to the programs of every other student who has an account on the same machine.
A dedicated hacker could wreak all kinds of havoc after finding this hole.
How about writing a daemon that runs quietly and secretly copies every floppy
that students mount, to the harddrive?  I think that this represents an
overwhelming reason to want root access to a small portion of students at any
university.  That is one reason why those protections are there.

--
            _.
--Steve   ._||__
  Warren   v\ *|
             V