-----BEGIN PGP SIGNED MESSAGE----- I think you are missing th epoin there somewhat. I belive the original intent was NOT to modify libc so that /tmp exploits are impossible as a be-all and end-all solution The idea was to modify libc so that anything which used /tmp in blatantly unsafe ways (I subscribe to BUGTRAQ and I have noticed allot of recent exploits and things involvce /tmp) The reason behind doing this is so that thos programs which use /tmp unsafely break automatically... That way they can be fixed As it is now...dozens of programs you use every day without thinking (or maybe just the few you seldom use) could use /tmp unsafely without ever being noticed unless you watch fo rit. Making wrappers to allow programs to work and setting weird flags is only a small solution if you fix the program itself, then you have a larger one (ie. what about filesystems that don't support chattr +X?) and the fix can be sent around to the rest of the community (outside of Debian) and close security holes before they are even known to be exploitable ok..maybe all of that wasn't the original intent of the idea...but that would be the effect personally I prefer that idea to making kernel patches or changeing the nature of /tmp itself of course... I personally agree with what some others said... this "Hacked" libc (or whatever is used) should not make it into a production releace... IMHO it should only be used to identify and fix problems it shouldn't be "standard" for normal users to use - -Steve
On Tue, 21 Apr 1998 [EMAIL PROTECTED] wrote: > > On Mon, Apr 20, 1998 at 11:47:20PM -0700, Guy Maor wrote: > >> Modifying libc to catch common security goals is a laudable goal, but > >> such a libc should go to experimental. > > This may be a stupid question, but *what* /tmp exploit are we trying > to fix? > > I ask solely because /tmp should already have some special attributes > set. Is this exploit something which is already solved by existing > permission flags? Is it something that could be solved by a new > permission flag? > > How about this is as second proposal: modify libc, ext2fs and chattr > to support a new extended attribute: > > chattr +X > > This flag is only meaningful for directories. (The same bit could be > used for other purposes for files; perhaps we could reuse an existing > bit?) > > If this is set, its immediate children will force O_EXCL if O_CREAT is > set. This is slightly different from the first proposal, since "broken" > code would still work *unless* an entry with the same name already > existed. > > Since you aren't using a string comparison all of the problems associated > with it disappear. You could even walk the tree and set this bit on > *every* directory. Since it's controlled by a standard mechanism, it's > easy to write wrapper functions, when necessary, for suitably privileged > users. > > Finally, since there is a workaround (chattr(); broken(); chattr();) > we can reasonably define this bit to apply to *all* users, including > root. If you don't want it at all, don't set the bit. If you do want > it but have broken applications, use wrappers. > > Bear Giles > [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQCVAwUBNT1Ajnxvn0zebBV9AQGsMgQAlJ14mamwp7dM2mELwga/MH4xNV6J1boV yAYICWyIREWn1tLhPPzsLzaVncTMS0VzSZaiy/Pf773hdii8ZSc5oLBf61JXNO4M p/3FriiWibxeoVp0f2DLFHna55zjMYlVaWIghzXYVTDL8jVlzhOMOfz5lbv4nF9U +rwdUZ6alVU= =L5qN -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
