[comp.sys.next] "file" operator disabled on NeXT 2.0

simsong@daily-bugle.media.mit.edu (Simson L. Garfinkel) (01/17/91)

In article "file" operator disabled on NeXT 2.0
 glenn@heaven.woodside.ca.us (Glenn Reid)
of : RightBrain Software, Woodside, CA writes:

>Somebody posted about this a while ago, and I just now got around to
>trying it out.

>The "file" operator on the new release of NeXT system software will not
>allow you to open a file for writing.  It doesn't generate an error,
>it just doesn't create the file (or allow you to modify an existing one).

>I presume this is done for security reasons, but I find it to be
>incompatible with other PostScript platforms and quite a nuisance.  I
>also can't quite figure why it would be a security risk, since the
>WindowServer runs as a user process with the user's normal userid.
>You can open files for reading with "file", but it won't let you open
>files you don't have normal UNIX access to, and opening files for
>writing shouldn't be any different.
- 
 Glenn Reid				RightBrain Software
 glenn@heaven.woodside.ca.us		NeXT/PostScript developers
 ..{adobe,next}!heaven!glenn		415-851-1785 (fax 851-1470)



Glenn,

	If you can open up a file for writing from within postscript, then I could send you a piece of postscript in a mail message that would open up your ".login" or ".cshrc" files for writing and write the following command:

	/bin/rm -rf ~

mdixon@parc.xerox.com (Mike Dixon) (01/22/91)

    >	If you can open up a file for writing from within postscript,
    >then I could send you a piece of postscript in a mail message that
    >would open up your ".login" or ".cshrc" files for writing and write
    >the following command:

    >	/bin/rm -rf ~

    So what? I can send you a piece of C code to do the same. Why is this
    more dangerous inyour view?

because the mail reader doesn't automatically execute pieces of c code
that it finds in messages.  if you've decided to use postscript as
your standard for sending graphics around, you need to assume that
people will execute it without reading it first, and take appropriate
precautions.

louie@sayshell.umd.edu (Louis A. Mamakos) (01/22/91)

>    So what? I can send you a piece of C code to do the same. Why is this
>    more dangerous inyour view?
>
>because the mail reader doesn't automatically execute pieces of c code
>that it finds in messages.  if you've decided to use postscript as
>your standard for sending graphics around, you need to assume that
>people will execute it without reading it first, and take appropriate
>precautions.

This is all very fine and good as an explanation, given that anyone is
actually sending around PostScript inside their mail messages, which I
don't believe is in wide use quite yet.  I suspect that if you have a
mail agent that interprets PostScript for graphical display, you have
any number of other issues that need to be worried about as well.  The
'file' operatore is likely only a small problem.  Consider that the
Display PostScript interpreter is used to feed input events into
the terminal emulators.  Lots of interesting ground to cover here...

On the other hand, I was using the file operator with the distill.ps
package frequently.  This PostScript program really shows that having
Display PostScript available is a big win.  This was an application
that was WORKING JUST FINE BEFORE, but is BROKEN NOW.  (Excuse me for
yelling.)  The 'file' operator no longer conforms to the description
in any documentation (NeXT or Adboe).  The release notes don't mention
any change.  The chapter in the online documentation which describes
NeXT specific or modified PostScript operators doesn't mention it.  If
NeXT wants to impose some restrictions on the file operator, that's
fine; just document it and describe how my working application needs
to be modified to work under 2.0.

This is a BUG, not a feature. (Or a buggy feature, depending upon how
you look at it).


louie

scott@Kolmogorov.gac.edu (Scott Hess) (01/22/91)

In article <1991Jan21.225155.6821@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes:
   >    So what? I can send you a piece of C code to do the same. Why is this
   >    more dangerous inyour view?
   >
   >because the mail reader doesn't automatically execute pieces of c code
   >that it finds in messages.  if you've decided to use postscript as
   >your standard for sending graphics around, you need to assume that
   >people will execute it without reading it first, and take appropriate
   >precautions.

   This is all very fine and good as an explanation, given that anyone is
   actually sending around PostScript inside their mail messages, which I
   don't believe is in wide use quite yet.

OK, to rephrase the original posting (though I had little if anything
to do with it):

Log into your machine and set public windowserver.  I can connect to
your windowserver, and use the file operator to overwrite your ~/.cshrc
with "rm -rf ~/", then the next time you run a csh, you're meat.  Heck,
to be safe, I'll overwrite .profile, too, so I can get you with sh, also.

Well, actually, I can't, but with a free-usage file operator, could.

Few computers have a cc server which will blithly compile incoming
c code and execute it, while a windowserver with public access writes
is essentially the same thing . . . get my point?  Maybe file should be
limited to a specific directory tree (as anon ftp is via chroot in
ftpd)?  Or, better yet, maybe all file access should be so limited
except for authorized connections?  Oh, no, now we're looking at
authorization . . .


--
scott hess                      scott@gac.edu
Independent NeXT Developer	GAC Undergrad
<I still speak for nobody>
"Tried anarchy, once.  Found it had too many constraints . . ."
"Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by
Richard Simmons . . ."

flar@bendenweyr.Eng.Sun.COM (Jim Graham) (01/23/91)

Everyone is ignoring the possibility that I might send out a 15 page
document formatted into PostScript in the middle of which I have hidden
(through the use of obscure indentation and nasty confusing comments all
around) the code which does the dirty deed of modifying your .cshrc.

Then if you preview this file or print it out using the native PS
interpreter built into your machine, I have access to your file
system.

Now are you really planning on scanning every bit of PS that someone
sends you for PS worms?

Sure, if I put it in a mail message, you can always disable an
"automatically run included PS" feature of your mailer and it will
then stick out like a sore thumb, but there are plenty of ways to
get you to voluntarily run the PS yourself by hand.

					...jim

kent@parc.xerox.com (Chris Kent) (01/25/91)

For The X Display PostScript extension we (Digital) decided to incorporate
such a restriction, too, but it was justified: the interpreter runs
inside the X server, which almost always (certainly on DEC machines) runs as 
root, and runs on the server machine, which is often not where the
client runs. Without some sort of intervention, this would lead
to a security hole and some real confusion, since the filesystem
namespace of the client and server might well be different.

We provided access to two directories in the server's filesystem, and 
didn't allow access "above" them (filename strings containing .. 
caused an error). This worked reasonably well, once you got used
to it.

chris
-- 
Chris Kent		Xerox PARC CSL			Palo Alto, CA USA
kent@arisia.xerox.com	xerox!kent			+1.415.494.4821