Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!convex!swarren
From: swarren@convex.com (Steve Warren)
Newsgroups: comp.unix.amiga
Subject: Floppy filesystem security (was Re: interesting feature on AMIX..)
Keywords: unix security, amix security, setuid
Message-ID: <1991Jun27.150353.21674@convex.com>
Date: 27 Jun 91 15:03:53 GMT
References: <1991Jun24.173951.17552@convex.com> <436@hfsi.UUCP> <1991Jun25.143038.22816@convex.com>
Sender: usenet@convex.com (news access account)
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Lines: 40
Nntp-Posting-Host: neptune.convex.com

In article <1991Jun25.143038.22816@convex.com> swarren@convex.com (Steve Warren) writes:
                             [...]
>Can anyone think of a reason why setuid bits need to be securely enabled (as
>opposed to being ignored) on a temporary filesystem like a floppy disk?

Well, I just found an answer to my own question.  I am taking a Unix OS class
right now, and our next project is to write a scheduler and some assorted
other programs to go with it.  If I was required to do a project like this on
a floppy file-system with setuid disabled I would not be able to implement
many important features such as tracking user-IDs, because no one but me would
be able to run the processess that have to communicate with my scheduler
(since they have to write some files inside my workspace to work).  Some of
the programs will have to be setuid to myself.

So it seems to me that in a university environment where you are using the
floppy filesystem as the working directory for your students, you don't really
want to disable setuid completely, because they will need to use this feature
occassionally while learning how Unix works.  Therefore I believe that a
carefully thought-out mount utility with a securely enabled setuid/gid
capability would be best.

I believe it should at least do this much:

1) Refuse to mount a filesystem with with any file setuid to a different user
   than the user mounting the filesystem (assuming he is not root, which is a
   trivial case).

2) Refuse to mount a filesystem with with any file setgid to a group that the
   user mounting the filesystem is not a member of.

3) Detect when the floppy has been ejected and automatically unmount the
   floppy.  This would cause the floppy to need a fsck the next time it is
   used.  Of course it should be unmounted *before* it is ejected.  This
   requirement is to prevent a user from having 2 identical floppies with
   different setuid bits on selected files.  The strategy for breaking
   security would be to mount the legitimate floppy, then swap disks.
   Unmounting the floppy upon ejection prevents this.

Other measures might be necessary.  This is all I have thought of.
--