Re: [Groff] moving TOC to start

From:

Tadziu Hoffmann

Subject:

Re: [Groff] moving TOC to start

Date:

Thu, 29 Sep 2005 22:23:15 +0200

User-agent:

Mutt/1.5.6i

> > > The problem with groff's `write' requests is that they
> > > don't work, if the user fails to specify the `-U' flag,
> > > when invoking groff.
> > >
> > > This flag activates the so called `unsafe' mode. While it
> > > probably isn't the case, this carries the connotation that
> > > it makes groff in some way harmful, and therefore, some
> > > users may be reluctant to use it. If the ms' `XS', `XA'
> > > and `XE' macros are reimplemented, so as to rely on
> > > `write' requests, then they appear broken, in the event
> > > that the user either forgets, or refuses to specify `-U'.
> > >
> > > Not a big deal, I know, but `unsafe' is a rather
> > > unfortunate choice of name for this `extended
> > > functionality' mode of groff's.
> >
> > The command allows unsafe behaviour in the same manner as, I
> > believe, 'Word' macros, so the name is appropriate IMHO.
>
> Word macros are inherently unsafe because they permit the
> execution of arbitrary code, effectively with super-user
> privileges on account of Windoze' weak security model, simply
> by opening what is ostensibly a text document.
>
> I find it difficult to see how allowing groff to write to
> named files, in addition to stdout and stderr, represents any
> such sort of security risk, especially when run on a host with
> a proper security model, unless of course you are crazy enough
> to install groff suid root, but perhaps you know otherwise.
Assume that you (an unsuspecting groff user) want to format a
document downloaded from the internet for printing, but the
roff-file has unfortunately been modified by some malicious
prankster to write a shell script called "ls" to your personal
"bin" directory (which is included in your PATH *before* /bin)
and the next time you execute ls... well, you get the idea.
(I'm ignoring things like the permission bits here, but you can
instead append to a file that already has execute permission.)
Furthermore, "-U" does not only allow "extended functionality",
but omitting "-U" also gives you "reduced functionality" by
disabling the ".sy" request that allows executing arbitrary
programs in your name. (For similar reasons, vim greatly
restricts what you can do with modelines, compared to the
original vi.) I think groff's default of forbidding things
unless you explicitly say "I trust this document" is the
prudent solution. Better safe than sorry.
Interestingly enough, the ghostscript people have chosen a more
optimistic stance by allowing these activities by default unless
you explicitly forbid them. (The option is called "SAFER", which
to me seems to imply that "normal" is already safe, but the
option makes things even safer.) On the other hand few people
invoke ghostscript directly, but rather through a frontend like
gv, which by default calls ghostscript with the "SAFER" flag.