Briefly, my original question went something like this:
I'd like to let Joe Random User mount and unmount a pcfs-format floppy
from his built in drive.
I then proposed two small programs, one for mounting and one for
unmounting, and asked if there were any security problems which I
might have overlooked.
Responses fell in to one of three categories: comments on my programs,
other mounting alternatives, other PC file system alternatives.
***Comments on my programs:
Quite a few respondents told me that this would not be secure unless I
checked for setuid files and device special files on the disk being
mounted. However: I am 99.5% certain that Sun's "pcfs" file system
does not support either of those file types. This means that neither
type of file can ever appear on a disk mounted as "pcfs". Since (a)
the /pcfs entry in /etc/fstab explicitly specified the pcfs file type,
(b) /etc/fstab can only be changed by root, and (c) fdmount explicitly
invokes mount with the argument "/pcfs", I feel that this is not a
valid concern.
To those of you out there thinking that a scheme similar to the one I
proposed would be neat for Unix file systems as well, I have this to
say: DON'T DO IT! There are serious security ramifications to letting
Joe Random User mount unix file systems from removable media!
It turns out that there *is* a problem with fdmount as I wrote it.
"mount" will attempt to mount a pcfs file system by exec-ing a program
called "mount_pcfs", which happens to be located in "/usr/etc". You'd
think it would invoke it explicitly. But, nope, it uses execlp. That
is, it runs whatever "mount_pcfs" it happens to find on the PATH! So
I really really need to hand the exec("/usr/etc/mount"...) my own
path. Some people suggested that I just do the mount system calls
myself, which is a good idea.
A few people pointed out that eject will do the umount for you (and
will not eject the disk if the umount fails). This is, in fact, true,
making it unnecessary to do all the stuff I originally did in fdeject.
Others suggested that the system would get confused if the floppy was
forcibly ejected (say, with a paper clip) and a different one
inserted: perhaps to the extent that the system would crash. This
could be considered unsecure in some environments, but personally I
figure "hey, it's his workstation, if he wants to crash it that's his
problem." I just want to make sure he can't become root. Still
another potential security problem is someone ELSE logging in remotely
and accessing the floppy after it is mounted. This can be fixed by
playing with device ownerships within fdmount and fdeject.
***Mounting alternatives:
Many other people suggested the "MNTDISK" package, which was recently
posted to alt.sources. Here is a blurb from the author:
Did you ever want to make use of those 3.5" floppy drives in Sun SparcStations?
Are you an administrator who is tired of copying files from DOS format disks
onto your workstations for your users? Do hate having to check whether a CD
has a 4.2 or High Sierra filesystem before you mount it? Are you so desperate
that you have created set-uid shell scripts to do this regardless of the
security holes? Then check out MNTDISK. The following paragraph is from the
README file:
MNTDISK is a package to allow users to perform basic
operations on some type of removable disk media in a
reasonably secure manner. Currently, Sun CD-ROM's (both HSFS
and UFS) and Sun floppy disks (both PCFS and UFS) are
supported.
Some people sent me the scripts and stuff they use to handle this same
problem. I didn't look very closely at them, but at some point
something has to be setuid in order to do the mount. FOLKS, PLEASE
HEED THIS WARNING: Never ever ever install a setuid shell script.
There are too many known holes with that approach, and I'm sure
that there are quite a few not-yet-discovered holes as well.
***pcfs alternatives:
Finally, some people pointed me at another package called "Mtools".
Apparently mtools has been around for awhile, but I hadn't heard about
it (at least not by name) until now.
John Valdes <valdes@geosun.uchicago.edu>:
Instead of writing your own setuid programs, I'd suggest using the
mtools package, available on cecer.army.mil or titan.rice.edu.... The
two main advantages of mtools over pc-fs are the fact that you don't
have to be root to use it, and it's also much faster. There was (is)
a discussion of mtools on sun-spots (comp.sys.sun) recently. One user
reported that mtools was more than 5x faster when copying files
between unix file systems and dos file system.
I found and retrieved mtools from cecer.army.mil (by the way, Rice
does NOT appear to have a copy of mtools---it only has a collection
of patches for mtools). It is much faster than pcfs, and not that
difficult to use. And you don't have to be root to run any of it.
I've decided that mtools is sufficient for what I'm trying to do.
I'll enclose the Readme at the end of this summary.
The only disadvantage that I can think of is there is no way to
prevent any user on the machine from accessing the floppy. In our
environment this is not a serious problem: not everyone in the YP
passwd map can log in to every machine. Your mileage may vary.
Thanks again to all who responded:
"Anthony A. Datri" <datri@concave.convex.com>
Brendan Kehoe <brendan@cs.widener.edu>
brent@curie.ssctr.bcm.tmc.edu (Brent Alan Wiese)
Emmett Hogan <hogan@csl.sri.com>
rjt@sedist.cray.com (Randy Thomas)
"Joel L. Seber ... CH210" <JLS2013%tntech.bitnet@eecs.nwu.edu>
mp@allegra.att.com (Mark Plotnick)
phil@dgbt.doc.ca (Phil Blanchfield)
dupuy@hudson.cs.columbia.edu (Alexander Dupuy)
rackow@antares.mcs.anl.gov
era@niwot.scd.ucar.EDU (Ed Arnold)
Steve Hayman <sahayman@porbeagle.cs.indiana.edu>
David Fetrow <fetrow@biostat.washington.edu>
antoine@roentgen.RadOnc.Duke.EDU
canuck@rice.edu (Mike Pearlman)
Roy Richter <rrichter@link.ph.gmr.com>
John Valdes <valdes@geosun.uchicago.edu>
laplante@iro.umontreal.ca (Pierre Laplante)
steve@umiacs.UMD.EDU (Steve D. Miller)
mikef@kristen.lerc.nasa.gov (Mike J. Fuller)
stssram@valdez.unocal.com (Bob Myers)
"Brian R. Smith" <brsmith@cs.umn.edu>
Jim Harkins <pacdata!jimh@ucsd.edu>
alek@spatial.com ( Alek O. Komarnitsky )
smb@ulysses.att.com
John.Finlay@Eng.Sun.COM (John Finlay)
pearlman%moose@rand.org (Laura Pearlman)
Stephen Guy Polis <guy@zeuswtc.sbi.com>
birger@vest.sdata.no ( Birger Wathne)
per@erix.ericsson.se (Per Hedeland)
mfg@ee.edinburgh.ac.uk
VINCE@UCONNVM.UCONN.EDU
pbg@cs.brown.edu (Peter Galvin)
ted@borgil.uchicago.edu (Ted Rodriguez-Bell)
"G. Roderick Singleton" <gerry@jtsv16.jts.com>
kevins@Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
long-morrow@CS.YALE.EDU
William LeFebvre
Computing Facilities Manager and Analyst
Department of Electrical Engineering and Computer Science
Northwestern University
<phil@eecs.nwu.edu>
-------------------- Readme file from mtools:
MTOOLS
version 2.0
Mtools is a public domain collection of programs to allow Unix systems
to read, write, and manipulate files on an MSDOS filesystem (typically a
diskette).
The following MSDOS commands are emulated:
Mtool MSDOS
name equivalent Description
----- ---- -----------
mattrib ATTRIB change MSDOS file attribute flags
mcd CD change MSDOS directory
mcopy COPY copy MSDOS files to/from Unix
mdel DEL/ERASE delete an MSDOS file
mdir DIR display an MSDOS directory
mformat FORMAT add MSDOS filesystem to a low-level format
mlabel LABEL make an MSDOS volume label.
mmd MD/MKDIR make an MSDOS subdirectory
mrd RD/RMDIR remove an MSDOS subdirectory
mread COPY low level read (copy) an MSDOS file to Unix
mren REN/RENAME rename an existing MSDOS file
mtype TYPE display contents of an MSDOS file
mwrite COPY low level write (copy) a Unix file to MSDOS
You should be able to just close your eyes and pretend you're on an MSDOS
system. Everything should work the same... except for the added 'm' at
the beginning of each command.
I really wanted to avoid the use of a 'text' mode and a 'data' mode when
transferring files, but I couldn't find a better way. It gets rather
confusing and it's quite possible to mess up a file if you apply the
text mode when it is not appropriate (ie: to a COM or EXE file).
The pattern matching routine more closely resembles Unix than MSDOS.
For example, "*" matches all MSDOS files in lieu of "*.*".
The use of wildcards (or the '\' separator) will require the names to be
enclosed in quotes to protect them from the shell. For example:
RIGHT: mcopy "a:*.c" .
will copy all files on the A: disk with the extension .C to the
current Unix directory.
WRONG: mcopy a:*.c .
will cause the shell to expand a:*.c in the current Unix directory
(which is probably not what you wanted) then copy that list of
files (if there were any) from A: to the current Unix directory.
RIGHT: mcopy *.c a:
will copy all files with the extension .c in the current Unix
directory to the A: drive. (This time you *want* the shell
the expand the *.c).
The manuals are very terse... it's assumed that the reader is already
familiar with MSDOS.
Mcopy is really a front-end to the low level Mread and Mwrite commands.
Emmet P. Gray US Army, HQ III Corps & Fort Hood
...!uunet!uiucuxc!fthood!egray Attn: AFZF-DE-ENV
fthood!egray@uxc.cso.uiuc.edu Directorate of Engineering & Housing
Environmental Management Office
Fort Hood, TX 76544-5057
--------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:19 CDT