To: linux-kernel@vger.kernel.org
Path: not-for-mail
From: daw@mozart.cs.berkeley.edu (David Wagner)
Newsgroups: isaac.lists.linux-kernel
Subject: Re: The disappearing sys_call_table export.
Date: 11 May 2003 17:20:26 GMT
Organization: University of California, Berkeley
Distribution: isaac
Message-ID: <b9m0oq$2sp$1@abraham.cs.berkeley.edu>
References: <200305111234_MC3-1-3865-CD21@compuserve.com>
NNTP-Posting-Host: mozart.cs.berkeley.edu
NNTP-Posting-Date: 11 May 2003 17:20:26 GMT
Originator: daw@mozart.cs.berkeley.edu (David Wagner)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1148
Lines: 21

Chuck Ebbert  wrote:
>  How about:

Here's a good rule of thumb:
  In security, if you need to ask, it's probably broken.

The way to do security design is NOT by throwing a few kludgy hacks
against the wall and seeing if any of them stick.  That's a recipe for
security holes.  The way you get security right is by building a clean,
simple design that you can convincingly argue to be correct.  In security,
you don't write code until you've got your assurance argument down pat.

If you can't convince yourself it's correct, it's probably not.

>        copy_from_user(name1, userfilename, ...);
>        ret = original_unlink(userfilename);
>        copy_from_user(name2, userfilename, ...);

Insecure.  Simply exploit the race condition twice: once just before
the original_unlink() to change the string to a dangerous filename,
then a second time just after the original_unlink() to change it back.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/