Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
Newsgroups: comp.lang.c++
Subject: Re: Re^2: information hiding
Message-ID: <11710@ulysses.homer.nj.att.com>
Date: 27 Jun 89 21:11:21 GMT
References: <6031@watdcsu.waterloo.edu> <6590164@hplsla.HP.COM> <1827@itivax.iti.org>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 25

You *really* don't want to make any part of the compiler setgid.
Writing secure privileged programs is *hard*; you have to think about
what you're doing in advance.  I'd lay heavy odds that it wouldn't be
hard to trick a compiler into violating your security model; compilers
are just too big, and too complex, to be ``trusted'' in that sense.
As someone here has said, ``you don't give privileges to a whale''.

Of course, the simple model given doesn't work anyway; what's to
prevent me from using the appropriate options to just collect the
cpp output?  Ah -- make cc or CC setgid, then they can decide to
reset the gid if the options appear to be secure, since they have
to understand them all anyway.  Then, of course, each component of
the compilation system has to toggle setgid on and off when creating
output files, to avoid a breach that way.  Then -- but you get the
picture.

Returning to the original question, for most purposes I don't think it
matters that the programmer can see the private sections of class
definitions.  I admit that my original reaction was the same -- but
then again, I'm primarily a network security person, and ``cheating''
in this fashion seemed to be an information leak.  But cfront isn't
part of a trusted security kernel, and shouldn't be.  The goal of
private class components is to provide insulation, not total isolation.

		--Steve Bellovin