[677] in linux-security and linux-alert archive
Re: [linux-security] Security problems in RedHat 3.0.3...
daemon@ATHENA.MIT.EDU (Zygo Blaxell)
Wed Apr 17 19:52:29 1996
From: Zygo Blaxell <zblaxell@myrus.com>
To: scoile@gmu.edu (Steve \"Stevers!\" Coile)
Date: Wed, 17 Apr 1996 16:55:32 -0400 (EDT)
Cc: zblaxell@myrus.com, linux-security@tarsier.cv.nrao.edu
In-Reply-To: <Pine.OSF.3.91.960416140638.15688A-100000@mason2.gmu.edu> from "Steve \"Stevers!\" Coile" at Apr 16, 96 02:12:49 pm
Quoted from Steve \"Stevers!\" Coile:
> > I just checked all of RedHat's man pages; none of them seem to use a .sy
> > command. This sounds like a feature we can just patch out of groff and
> > forget about (except possibly to refuse to process man pages with '.sy'
> > in them after preprocessing).
>
> Patch out of groff?! And what about everyone using that
> functionatilty? Just tell 'em, "tough luck, our purposes before
> yours"? No, that's an unacceptable answer. If you're going to patch
> groff, add a feature to *selectively* disable ".sy", not disable it
> altogether.
Errr...I'm sure I meant 'make .sy non-default for groff with a flag to
enable it' rather than 'remove it completely'. If you must, then switch
the sense of the flag; just put the flag in and document its function,
fix 'man' to use the flag, and I'll be happy.
That said, I think it would be a useful security policy for all programs
(under Linux or anything else) to by default *not* allow you to run
shell programs taken from their input files (i.e. via ghostscript,
nroff, etc). Most packages have no problems dealing with odd variants
of groff anyway, and few enough of those use .sy that changing them
shouldn't be a problem. <TANGENT DIRECTION="PostScript">How many
real postscript files, files that you expect to send to a real
PostScript printer to generate printed output, use the pipe or
write-to-file features? Why does ghostscript need to enable these
features by default?</TANGENT>
There's something to be said for least surprise. On the one hand, it is
surprising for people who use .sy to suddenly require a command-line
option to groff to get it to work; on the other hand, it is surprising
for new Unix users to find out that reading a formatted text file is a
security hole (I've been using Unix for four years, and I was
surprised by this one). Who would you rather surprise?
> > We can also assume that system man pages in root-configured paths are
> > free of .sy directives or at least contain only harmless ones.
There's also the possibility of configuring groff or man with a list of
'approved' .sy, .open, .pi, etc commands and filtering the input to
reject any other ones (or for man to proceed without using the caching
mechanism, which would require extra privileges). This sounds like a
lot of trouble; I'd prefer establishing the rule that man pages read by
the 'man' command either a) can't execute programs, period, or b) can
execute programs, but with the original user's privileges, and without
using the privileged shared cache mechanism.
> We can *assume*?! Geezus, is that how you handle security, through
> *assumptions*? We can't *assume* anything.
I can assume that it is safe for me to execute programs stored in
binaries owned by root and stored in directories such that only root can
manipulate their contents. These programs are as trustworthy as the
system integrator who compiled, verified, and installed them (and as
trustworthy as the least trustworthy program running with elevated
privileges, but we'll leave weaknesses in the Unix security model aside
for now). Without this assumption, the whole Unix security model goes
away as there's nothing left.
I merely proposed extending the set of trustworthy programs to include
man pages that have the same characteristics as the binaries in /bin and
friends. If the man page was installed by the system administrator,
then it's probably OK to assume that any programs it invokes are
programs that the system administrator approves of--otherwise, why did
the system administrator install them in the first place?
Educating sysadmins, of course, is a separate problem. ;-)
Of course, as I pointed out a few times by now, a privileged 'man'
program has to be able to distinguish between man pages installed by the
sysadmin and man pages presented to it by random users, to determine
whether it should use its privileges to write cache pages.
> Either we prohibit the use
> of ".sy" in manual pages, or we find a way to support them safely. We
> don't *assume* they don't exist or can be safely ignored, we *find
> out*.
I just checked my (RedHat 3.0.3, all packages installed) man page
database for '.sy', '.pi', and '.open'. None of these seem to be used
in man pages (except '.open', which appears twice in the gtroff(1) man
page, but as data--it occurs in the middle of its own documentation).
It would therefore seem to be safe to reject these requests in the
special case of man pages.
Are there any packages that have *man pages* that use these features,
and if so, how difficult would it be to wean them off of .sy and
friends? (I would imagine a quick shell script run at install time
could generate a .sy-free version of the man page).
> Personally, I like the idea of a man page client and server.
:)
--
Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science
Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate
Programming Contest Finals, 1994. Administer Linux nets for food, clothing,
and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong
