On Tue, Aug 27, 2002 at 05:55:37PM +0200, Johnny Billquist wrote:
> On Tue, 27 Aug 2002, Jason R Thorpe wrote:
> > On Tue, Aug 27, 2002 at 05:34:14PM +0200, Johnny Billquist wrote:
> >  > While true, that goes both ways. It also becomes a potentially more
> >  > dangerour system. Sneak things into libc, and you have an even better
> >  > chance at perverting things.
> > What a totally absurd argument.  If someone puts a trojan in your libc,
> > you're hosed, period.  This is true whether or not /bin and /sbin
> > are static.
> 
> Look, I didn't want to take the security discussion, but if you insist...
> Yes, you are most likely hosed if your libc becomes compromised.
> But you have to realize it as well. Without /bin and /sbin dynamically
> linked, they are more protected anyhow, and can be more trusted (even
> though that's no guarantee either), and you can perhaps make it back from
> there. With dynamically linked stuff, you'll have to revert to
> /rescue.

No.

If someone can overwrite your libc, they can overwrite every static
executable on your system as well.

Any attempt to say "setup X" makes it more possible to recover a
compromised system is wrong, completely wrong.

Once compromised, your _only_ guaranteed recovery is to boot from a
clean system disk, and compare SHA1/MD5 checksums (ala tripwire etc) to
detect modified files, or to ignore that and reinstall every executable
component.

> > If you want to prevent (or at least make extremely difficult) this, then
> > set the "immutable" bit on the shlib, and run at a high kern.securelevel.
> 
> That's actually something I would think NetBSD should default to.

That could be an interesting thread, in the usual convienience/security
tradeoff vein, but isn't relevant here.

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
All this stuff in twice the space would only look half as bad!
					      - me