linux-kernel - Re: [stable] Linux 2.6.25.10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <487DDC78.2960.1EAE7F08@pageexec.freemail.hu>
Date:	Wed, 16 Jul 2008 11:33:12 +0200
From:	pageexec@...email.hu
To:	Tiago Assumpcao <tiago@...umpcao.org>,
	Casey Schaufler <casey@...aufler-ca.com>
CC:	Theodore Tso <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [stable] Linux 2.6.25.10

On 15 Jul 2008 at 20:27, Casey Schaufler wrote:

> Tiago Assumpcao wrote:
> > Theodore Tso wrote:
> >> Look if you want this, pay $$$ to a distribution and get their
> >> supported distribution.  It costs time and effort to classify bugs as
> >> security related (or not), (...)
> >
> > That's fallacious. Assuming that you have good programmers, and you 
> > do, it's of very low cost the act of identifying what *is likely to 
> > be* a security bug.
> 
> That is based on lots and lots of assumptions that are just not true.
> Ted Tso, Stephen Smalley and I are all recognized as security experts

not so quick. security is a big field, noone really can claim to be
a general expert. Ted knows kerberos but he would be unable to exploit
the task refcount leak bug fixed in 2.6.25.10. Stephen and you know
MAC systems inside out but you too would be unable to exploit that bug.
different domains, different expertise, despite all being 'security'.
with that foreword:

> and we can't even agree on whether sockets are objects or not,

and it's utterly irrelevant to the next hacker that will own your precious
MAC by exploiting a kernel bug that you 'experts' didn't deem important
enough to tell the world about. do you understand that we've been talking
about *kernel* bugs here? do you understand what privilege elevation is?
you surely do since you work with MAC systems all the time whose purpose
is, well, access control.

> much less what constitutes a security bug and even less what is likely to
> be a security bug.

privilege elevation bugs are security bugs, no ifs and buts. whether a given
bug can be exploited at that level is a different question, and if you can't
make that judgement you're welcome to err on the side of safety (i.e., have
people upgrade/backport rather than be possibly exposed) or bring in help
(if Microsoft can pay people to do that, so can commercial Linux companies).

> Goodness, there are some of us who would argue
> that since DNS is itself a security bug it is just not possible for
> DNS to have a security bug, as an example.

it's all very much irrelevant to local kernel security that we're talking
about.

> > In most cases, they are easy to spot.
> 
> Err, no, in the kernel environment a real security flaw is likely to
> be pretty subtle.

i don't have stats about 'most' vs 'likely', but yes, they can indeed
be subtle, that's why you should not be overly optimistic and dismiss
potentially exploitable bugs as not relevant and cover them up.

cheers,
  PaX Team

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/