Re: /tmp exploits
-----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 bear@coyotesong.com 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
> bear@coyotesong.com
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
iQCVAwUBNT1Ajnxvn0zebBV9AQGsMgQAlJ14mamwp7dM2mELwga/MH4xNV6J1boV
yAYICWyIREWn1tLhPPzsLzaVncTMS0VzSZaiy/Pf773hdii8ZSc5oLBf61JXNO4M
p/3FriiWibxeoVp0f2DLFHna55zjMYlVaWIghzXYVTDL8jVlzhOMOfz5lbv4nF9U
+rwdUZ6alVU=
=L5qN
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: