In an attempt to save the world from disaster, Manoj Srivastava wrote:
> Hi,
> >>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
>
> Ian> I think noone, even humans, should type `echo blah > /tmp/junk'.
> Ian> Make a directory named after your userid, or use your home
> Ian> directory, or somethi
-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
> 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 hav
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.
Why change libc? Isn't there a kernel patch that makes /tmp safe? Why isn't
no-one using it?
--
Joh 3:16
--
To UNSUBSCRIBE
Ian Jackson <[EMAIL PROTECTED]> writes:
> We should modify our libc so that opening a file in /tmp or /var/tmp -
> determined by simple string comparison of the filename passed to
> open(2) - fails if O_CREAT is specified without O_EXCL.
You also need to check whether the current directory is /tm
I agree with Manoj here.
Modifying libc to catch common security goals is a laudable goal, but
such a libc should go to experimental.
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> I think we should stay away from delibrate non-compliance,
> even for laudable goals such as these. An experimental non-conformant
> libc (which I can install on a test system) is not something I shall
> object to.
Why not doing this: Each program when started, whe libc is initialized
Ian Jackson <[EMAIL PROTECTED]> writes:
> We should modify our libc so that opening a file in /tmp or /var/tmp -
> determined by simple string comparison of the filename passed to
> open(2) - fails if O_CREAT is specified without O_EXCL.
>
> We should do this in slink. That way almost any progr
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> I think noone, even humans, should type `echo blah > /tmp/junk'.
Ian> Make a directory named after your userid, or use your home
Ian> directory, or something.
Right. But my machine, my rules -- and this proposal would
change the
Manoj Srivastava writes ("Re: /tmp exploits"):
...
> I think I would want echo blah > /tmp/junk nto to start
> failing on my just because there is a file called junk already
> in there. Modifying libc is too deep rooted a change; and modifes the
> semantics o
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> We should modify our libc so that opening a file in /tmp or
Ian> /var/tmp - determined by simple string comparison of the filename
Ian> passed to open(2) - fails if O_CREAT is specified without O_EXCL.
I think I would want echo b
On Mon, Apr 20, 1998 at 01:20:10PM +0100, Ian Jackson wrote:
> We should modify our libc so that opening a file in /tmp or /var/tmp -
> determined by simple string comparison of the filename passed to
> open(2) - fails if O_CREAT is specified without O_EXCL.
This should only be files directly unde
On Mon, Apr 20, 1998 at 01:20:10PM +0100, Ian Jackson wrote:
> We should modify our libc so that opening a file in /tmp or /var/tmp -
> determined by simple string comparison of the filename passed to
> open(2) - fails if O_CREAT is specified without O_EXCL.
>
> We should do this in slink. That
We should modify our libc so that opening a file in /tmp or /var/tmp -
determined by simple string comparison of the filename passed to
open(2) - fails if O_CREAT is specified without O_EXCL.
We should do this in slink. That way almost any program with a /tmp
security hole will stop working strai
14 matches
Mail list logo
