Note that in the case of PostScript (and Display PostScript), the
dangerous "file" operators have been crippled in the name of security.
For example, on the NeXT, you cannot create a file using the file
operator in PostScript, only open existing files for reading.
Now sure, this eliminates a large class of security problems, but also
renders certain types of things impossible. You have to be careful
where you decide to enforce security policy so that you don't prevent
or prohibit otherwise resonable things from being done. In my
opinion, what was done in Display PostScript on the NeXT was going a
little too far.
Actually, it is worse than you say -- the approach taken here is neither
necessary nor sufficient.
Example: If I can read files on behalf of the user, I can probably read
and process sensitive stuff like .rhosts files and the like. Worse, if I'm
running as some sort of system-level thingie, I can probably read things like
the system password file. Now, I cannot write any files, but PostScript
axiomatically is a language that produces some sort of output! So, if I'm
being moderately clever, I send a PostScript file to an unsuspecting user and
ask them use their PostScript interpreter to display it on my screen. In the
process it displays all the sensitive files I can dredge up. Elaborations on
this theme are left as an exercise.
This is especially a problem for things like FAX gateways that accept
PostScript -- I doubt if I need to explain further... And yes, I have seen
holes like this actually being exploited by crackers.
One solution is to run PostScript and similar things under the auspices of a
special entity (from the security standpoint) whose only purpose is the viewing
of PostScript from unauthenticated sources. This entity can then be assigned
the degree of access that's consistent with its operation (e.g it can have a
temporary directory of its own). Of course some operating systems don't allow
for protection stuff like this. It is a shame that it is just these systems
that people often run PostScript interpreters on.
I'm strongly for providing the mechanism and perhaps pointing out
where policy might be "inflicted" by the application. But it is an
application issue, and not one of the protocol itself.
And as such it does not belong in a protocol document. (I note in passing that
the PostScript Language Reference Manual does not discuss these things either
apart from an extremely brief reference on page 76 of the Second Edition.)
If someone wants to do a informational security RFC that describes security
problems with mail I'll be happy to try and help. I don't think this belongs in
RFC-XXXX.
Ned