Xref: utzoo comp.unix.programmer:1299 alt.sources.d:1604 Path: utzoo!news-server.csri.toronto.edu!rutgers!ucsd!sdd.hp.com!cs.utexas.edu!natinst!sequoia!rpp386!jfh From: jfh@rpp386.cactus.org (John F Haugh II) Newsgroups: comp.unix.programmer,alt.sources.d Subject: Re: -x implementations Message-ID: <19101@rpp386.cactus.org> Date: 12 Mar 91 13:25:09 GMT References: <668288533.3106@mindcraft.com> <1991Mar07.091123.13033@kithrup.COM> <1991Mar08.194702.5369@kithrup.COM> Reply-To: jfh@rpp386.cactus.org (John F Haugh II) Organization: Lone Star Cafe and BBS Service Lines: 19 X-Clever-Slogan: Recycle or Die. In article peter@ficc.ferranti.com (Peter da Silva) writes: >Does "auth" have write access to these files? If so then you haven't changed >the problem any. Just made it more obscure. Nothing that someone with adb >and a little determination couldn't crack. You have a pretty poor understanding of how systems with "enhanced security" work. More likely that not, "auth" is only able to write the various files when some magical "trusted path" exists, or only "trusted" applications can be executed by "auth" or some other restriction. You will likely find that "auth" lacks whatever magic cookie it is that would let any random program modify any random file. If it doesn't we should all point our fingers at SecureWare and laugh heartily. [Then we can point our fingers at OSF for picking SecureWare as well ;-) ] -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.