Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501121002200.2310@ppc970.osdl.org>
Date: Wed, 12 Jan 2005 18:12:15 GMT
Message-ID: <fa.gtd7te1.b2iq9n@ifi.uio.no>

On Wed, 12 Jan 2005, Chris Wright wrote:
>
> This same discussion is taking place in a few forums.  Are you opposed to
> creating a security contact point for the kernel for people to contact
> with potential security issues?  This is standard operating procedure
> for many projects and complies with RFPolicy.

I wouldn't mind, and it sounds like a good thing to have. The _only_
requirement that I have is that there be no stupid embargo on the list.
Any list with a time limit (vendor-sec) I will not have anything to do
with.

If that means that you can get only the list by invitation-only, that's
fine.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501121051360.2310@ppc970.osdl.org>
Date: Wed, 12 Jan 2005 19:05:06 GMT
Message-ID: <fa.gttjum0.biur1k@ifi.uio.no>

On Wed, 12 Jan 2005, Chris Wright wrote:
>
> Right, I know you don't like the embargo stuff.

I'd very happy with a "private" list in the sense that people wouldn't
feel pressured to fix it that day, and I think it makes sense to have some
policy where we don't necessarily make them public immediately in order to
give people the time to discuss them.

But it should be very clear that no entity (neither the reporter nor any
particular vendor/developer) can require silence, or ask for anything more
than "let's find the right solution". A purely _technical_ delay, in other
words, with no politics or other issues involved.

Otherwise it just becomes politics:  you end up having security firms that
want a certain date because they want a PR blitz, and you end up having
vendors who want a certain date because they have release issues.

Does that mean that vendor-sec would end up being used for some things,
where people _want_ the politics and jockeying for position?  Probably.
But having a purely technical alternative would be wonderful.

> > If that means that you can get only the list by invitation-only, that's
> > fine.
>
> Opinions on where to set it up?  vger, osdl, ...?

I don't personally think it matters. Especially if we make it very clear
that it's purely technical, and no vendor politics can enter into it.
Whatever ends up being easiest.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501121058120.2310@ppc970.osdl.org>
Date: Wed, 12 Jan 2005 19:13:03 GMT
Message-ID: <fa.gstbum7.aimr1t@ifi.uio.no>

On Wed, 12 Jan 2005, Greg KH wrote:
>
> So you would be for a closed list, but there would be no incentive at
> all for anyone on the list to keep the contents of what was posted to
> the list closed at any time?  That goes against the above stated goal of
> complying with RFPolicy.

There's already vendor-sec. I assume they follow RFPolicy already. If it's
just another vendor-sec, why would you put up a new list for it?

In other words, if you allow embargoes and vendor politics, what would the
new list buy that isn't already in vendor-sec.

When I saw how vendor-sec worked, I decided I will never be on an embargo
list. Ever. That's not to say that such a list can't work - I just
personally refuse to have anything to do with one. Whether that matters or
not is obviously an open question.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501121148240.2310@ppc970.osdl.org>
Date: Wed, 12 Jan 2005 20:05:49 GMT
Message-ID: <fa.gtdhue7.b2or9t@ifi.uio.no>

On Wed, 12 Jan 2005, Marcelo Tosatti wrote:
>
> How you feel about having short fixed time embargo's (lets say, 3 or 4 days) ?

Please realize that I don't have any problem with a short-term embargo per
se, what I have problems with is the _politics_ that it causes.  For
example, I do _not_ want this to become a

 "vendor-sec got the information five weeks ago, and decided to embargo
  until day X, and then because they knew of the 4-day policy of the
  kernel security list, they released it to the kernel security list on
  day X-4"

See? That is playing politics with a security list. That's the part I
don't want to have anything to do with. If somebody did that to me, I'd
feel pissed off like hell, and I'd say "screw them".

But in the absense of politics, I'd _happily_ have a self-imposed embargo
that is limited to some reasonable timeframe (and "reasonable" is
definitely counted in days, not weeks. And absolutely _not_ in months,
like apparently sometimes happens on vendor-sec).

So if the embargo time starts ticking from _first_ report, I'd personally
be perfectly happy with a policy of, say "5 working days" (aka one week),
or until it was made public somewhere else.

IOW, if it was released on vendor-sec first, vendor-sec could _not_ then
try to time the technical list (unless they do so in a very timely manner
indeed).

I'm not saying that we'd _have_ to go public after five days. I'm saying
that after that, there would be nothing holding it back (but maybe the
technical discussion on how to _fix_ it is still on-going, and that might
make people just not announce it until they're ready).

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501121222590.2310@ppc970.osdl.org>
Date: Wed, 12 Jan 2005 20:35:49 GMT
Message-ID: <fa.gutttu1.8i4qpn@ifi.uio.no>

On Wed, 12 Jan 2005, Linus Torvalds wrote:
>
> So if the embargo time starts ticking from _first_ report, I'd personally
> be perfectly happy with a policy of, say "5 working days" (aka one week),
> or until it was made public somewhere else.

Btw, the only thing I care about is the embargo on the _fix_.

If a bug reporter is a security house, and wants to put a longer embargo
on announcing the bug itself, or on some other aspect of the issue (ie
known exploits etc), and wants to make sure that they get the credit and
they get to be the first ones to announce the problem, that's fine by me.

The only thing I really care about is that we can serve the people who
depend on us by giving them source code that is as bug-free and secure as
we can make it. If that means that we should make the changelogs be a bit
less verbose because we don't want to steal the thunder from the people
who found the problem, that's fine.

One of the problems with the embargo thing has been exactly the fact that
people couldn't even find bugs (or just uglinesses) in the fixes, because
they were kept under wraps until the "proper date".

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501121750470.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 02:11:36 GMT
Message-ID: <fa.gue3ulv.82ir1l@ifi.uio.no>

On Wed, 12 Jan 2005, Dave Jones wrote:
>
> Who would be on the kernel security list if it's to be invite only ?
> Is this just going to be a handful of folks, or do you foresee it
> being the same kernel folks that are currently on vendor-sec ?

I'd assume that it's as many as possible. The current vendor-sec kernel
people _plus_ anybody else who wants to.

> My first thought was 'Chris will forward the output of security@kernel.org
> to vendor-sec, and we'll get a chance to get updates built'. But you
> seem dead-set against any form of delayed disclosure, which has the
> effect of catching us all with our pants down when you push out
> a new kernel fixing a hole and we don't have updates ready.

Yes, I think delayed disclosure is broken. I think the whole notion of
"vendor update available when disclosure happens" is nothing but vendor
politics, and doesn't help _users_ one whit.  The only thing it does is
allow the vendor to point fingers and say "hey, we have an update, now
it's your problem".

In reality, the user usually needs to have the update available _before_
the disclosure anyway. Preferably by _months_, not minutes.

So I think the whole vendor-sec thing is not helping users at all, it's
purely a "vendor embarassment" thing.

> If you turned the current model upsidedown and vendor-sec learned
> about issues from security@kernel.org a few days before it'd at
> least give us *some* time, as opposed to just springing stuff
> on us without warning.

I think kernel bugs should be fixed as soon as humanly possible, and _any_
delay is basically just about making excuses. And that means that as many
people as possible should know about the problem as early as possible,
because any closed list (or even just anybody sending a message to me
personally) just increases the risk of the thing getting lost and delayed
for the wrong reasons.

So I'd not personally mind some _totally_ open list. No embargo at all, no
limits on who reads it. The more, the merrier. However, I think my
personal preference is pretty extreme in one end, and I also think that
vendor-sec is extreme in the other. So there is probably some middle
ground.

Will it make everybody happy? Hell no. Nothing like that exists. Which is
why I'm willing to live with an embargo as long as I don't feel like I'm
being toyed with.

And hey, vendor-sec works. I feel like vendor-sec just toys with me, which
is why I refuse to have anything to do with it, but it's entirely possible
that the best solution is to just ignore my wishes. That's OK. I'm ok with
it, vendor-sec is ok with it, nobody is _happy_ with it, but it's another
compromise. Agreeing to disagree is fine too, after all.

So it's embarrassing to everybody if the kernel.org kernel has a security
hole for longer than vendor kernels, but at the same time, most _users_
run vendor kernels anyway, so maybe the current setup is the proper one,
and the kernel.org kernel _should_ be the last one to get the fix.
Whatever. I happen to believe in openness, and vendor-sec does not. It's
that simple.

But if we're seriously looking for a middle ground between my "it should
be open" and vendor-sec "it should be totally closed", that's where my
suggestions come in. Whether people _want_ to look for a middle ground is
the thing to ask first..

For example, having an arbitrarily long embargo on actual known exploit
code is fine with me. I don't care. If I have to promise to never ever
disclose an exploit code in order to see it, I'm fine with that - but I
refuse to delay the _fix_ by more than a few days, and even that "few
days" goes out the window if somebody else has knowingly delayed giving
the fix or problem to me in the first place.

This is not just about sw security, btw. I refuse to sign NDA's on hw
errata too. Same deal - it may mean that I get to know about the problem
later, but it also means that I don't have to feel guilty about knowing of
a problem and being unable to fix it. And it means that people can trust
_me_ personally.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501121847410.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 02:53:47 GMT
Message-ID: <fa.gudpue6.820r9i@ifi.uio.no>

On Wed, 12 Jan 2005, Andrew Morton wrote:
>
> That sounds a bit over-the-top to me, sorry.

Maybe a bit pointed, but the question is: would a user perhaps want to
know about a security fix a month earlier (knowing that bad people might
guess at it too), or want the security fix a month later (knowing that the
bad guys may well have known about the problem all the time _anyway_)?

Being public is different from being known about. If vendor-sec knows
about it, I don't find it at all unbelievable that some spam-virus writer
might know about it too.

>  All of these are of exactly the same severity as the rlimit bug,
> and nobody cares, nobody is hurt.

The fact is, 99% of the time, nobody really does care.

> The fuss over the rlimit problem occurred simply because some external
> organisation chose to make a fuss over it.

I agree. And if i thad been out in the open all the time, the fuss simply
would not have been there.

I'm a big believer in _total_ openness. Accept the fact that bugs will
happen. Be open about them, and fix them as soon as possible. None of this
cloak-and-dagger stuff.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501122025140.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 04:51:40 GMT
Message-ID: <fa.gtdftu4.b2qqpg@ifi.uio.no>

On Wed, 12 Jan 2005, Dave Jones wrote:
>
> For us thankfully, exec-shield has trapped quite a few remotely
> exploitable holes, preventing the above.

One thing worth considering, but may be abit _too_ draconian, is a
capability that says "can execute ELF binaries that you can write to".

Without that capability set, you can only execute binaries that you cannot
write to, and that you cannot _get_ write permission to (ie you can't be
the owner of them either - possibly only binaries where the owner is
root).

Sure, that's clearly not viable for a developer or even somebody who
maintains his own machine, but it _is_ probably viable for pretty much any
user that is afraid of compiling stuff him/herself and just gets signed
rpm's that install as root anyway. And it should certainly be viable for
somebody like "nobody" or "ftp" or "apache".

And I suspect there is almost zero overlap between the "developer
workstation" kind of setup (where the above is just not workable) and
"server or end-user desktop" setup where it might work.

A lot of the local root exploits depend on being able to run code that
doesn't come pre-installed on the system. A hole in a user-level server
may get you local shell access, but you generally need another stage to
get elevated privileges and _really_ mess with the machine.

Quite frankly, nobody should ever depend on the kernel having zero holes.
We do our best, but if you want real security, you should have other
shields in place. exec-shield is one. So is using a compiler that puts
guard values on the stack frame (immunix, I think). But so is saying "you
can't just compile or download your own binaries, nyaah, nyaah, nyaah".

As I've already made clear, I don't believe one whit in the "secrecy"
approach to security. I believe that "security through obscurity" can
actually be one valid level of security (after all, in the extreme case,
that's all a password ever really is).

So I believe that in the case of hiding vulnerabilities, any "security
gain" from the obscurity is more than made up for by all the security you
lose though delaying action and not giving people information about the
problem.

I realize people disagree with me, which is also why I don't in any way
take vendor-sec as a personal affront or anything like that: I just think
it's a mistake, and am very happy to be vocal about it, but hey, the
fundamental strength of open source is exactly the fact that people don't
have to agree about everything.

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501130822280.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 16:46:05 GMT
Message-ID: <fa.gsu7tu2.biiqpm@ifi.uio.no>

On Thu, 13 Jan 2005, Christoph Hellwig wrote:
>2B
> On Wed, Jan 12, 2005 at 08:48:57PM -0800, Linus Torvalds wrote:
> > Without that capability set, you can only execute binaries that you cannot
> > write to, and that you cannot _get_ write permission to (ie you can't be
> > the owner of them either - possibly only binaries where the owner is
> > root).
>
> I think this is called "mount user-writeable filesystems with -noexec" ;-)

You miss the point.

It wouldn't be a global flag. It's a per-process flag. For example, many
people _do_ need to execute binaries in their home directory. I do it all
the time. I know what a compiler is.

Others do not necessarily do that. Sure, you could mount each users home
directory separately with a bind mount, but that's not only inconvenient,
it also misses the point - it's not about _where_ the binary is, it's
about _who_ runs it.

What is the real issue with MS security? Is it that NT is findamentally a
weak kernel? Hey, maybe. Or maybe not. More likely it's the mindset that
you trust everything, regardless of where they are. Most users are admins,
and you run any code you see (or don't see) by default, whether it's in an
email attachement or whatever.

Containment is what real security is about. Everybody knows bugs happen,
and that people do stupid things. Developers, users, whatever. We all do.

For example, in many environments it could possibly be a good idea to make
even _root_ have the "can run non-root binaries flag" clear by default.
Imagine a system that booted up that way, and used PAM to enable non-root
binaries on a per-user basis (for developers who need it or otherwise
people who are trusted to have their own binaries). Think about what that
means...

Every single deamon in the system would have the flag clear by default.
You take over the web-server, and the most you have to play with are the
binaries that are already installed on the system (and the code you can
inject directly into the web server process from outside - that's likely
to be the _real_ security hazard).

It's just another easy containment. It's not real security in itself, but
_no_ single thing is "real security". You just add containment, to the
point where it gets increasingly difficult to get to some state where you
can do lots of damage (in a perfect world, exponentially more so, but
these containments are seldom independent or each other).

NOTE! I'd personally hate some of the security things. For example, I
think the "randomize code addresses" is absolutely horrible, just because
of the startup overhead it implies (specifically no pre-linking). I also
immensely dislike exec-shield because of the segment games it plays - I
think it makes sense in the short run but not in the long run, so I much
prefer that one as a "vendor feature", not as a "core feature".

So when I talk about security, I have this double-standard where I end up
convinced that many features are things that _I_ should not do, but
others likely should ;)

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501130909270.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 17:30:26 GMT
Message-ID: <fa.gsu7te9.bieq9t@ifi.uio.no>

On Thu, 13 Jan 2005, Arjan van de Ven wrote:
>
> I think you are somewhat misguided on these: the randomisation done in
> FC does NOT prohibit prelink for working, with the exception of special
> PIE binaries. Does this destroy the randomisation? No: prelink *itself*
> randomizes the addresses when creating it's prelink database

There was a kernel-based randomization patch floating around at some
point, though. I think it's part of PaX. That's the one I hated.

Although I haven't seen it in a long time, so you may well be right that
that one too is fine.

My point was really more about the generic issue of me being two-faced:
I'll encourage people to do things that I don't actually like myself in
the standard kernel.

I just think that forking at some levels is _good_. I like the fact that
different vendors have different objectives, and that there are things
like Immunix and PaX etc around. Of course, the problem that sometimes
results in is the very fact that because I encourage others to have
special patches, they en dup not even trying to feed back _parts_ of them.

In this case I really believe that was the case. There are fixes in PaX
that make sense for the standard kernel. But because not _all_ of PaX
makes sense for the standard kernel, and because I will _not_ take their
patch whole-sale, they apparently believe (incorrectly) that I wouldn't
even take the non-intrusive fixes, and haven't really even tried to feed
them back.

(Yes, Brad Spengler has talked to me about PaX, but never sent me
individual patches, for example. People seem to expect me to take all or
nothing - and there's a _lot_ of pretty extreme people out there that
expect everybody else to be as extreme as they are..)

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501130926260.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 17:43:25 GMT
Message-ID: <fa.gsu5tu6.bicqpi@ifi.uio.no>

On Thu, 13 Jan 2005, Alan Cox wrote:
>
> On Iau, 2005-01-13 at 16:38, Linus Torvalds wrote:
> > It wouldn't be a global flag. It's a per-process flag. For example, many
> > people _do_ need to execute binaries in their home directory. I do it all
> > the time. I know what a compiler is.
>
> noexec has never been worth anything because of scripts. Kernel won't
> load that binary, I can write a script to do it.

Scripts can only do what the interpreter does. And it's often a lot harder
to get the interpreter to do certain things. For example, you simply
_cannot_ get any thread race conditions with most scripts out there, nor
can you generally use magic mmap patterns.

Am I claiming that disallowing self-written ELF binaries gets rid of all
security holes? Obviously not. I'm claiming that there are things that
people can do that make it harder, and that _real_ security is not about
trusting one subsystem, but in making it hard enough in many independent
ways that it's just too effort-intensive to attack.

It's the same thing with passwords. Clearly any password protected system
can be broken into: you just have to guess the password. It then becomes a
matter of how hard it is to "guess" - at some point you say a password is
secure not because it is a password, but because it's too _expensive_ to
guess/break.

So all security issues are about balancing cost vs gain. I'm convinced
that the gain from openness is higher than the cost. Others will disagree.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501131142500.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 19:58:37 GMT
Message-ID: <fa.gut9ue2.8igr9m@ifi.uio.no>

On Thu, 13 Jan 2005, John Richard Moser wrote:
>
> > So all security issues are about balancing cost vs gain. I'm convinced
> > that the gain from openness is higher than the cost. Others will disagree.
>
> Yes.  Nobody code audits your binaries.  You need source code to do
> source code auditing.  :)

Oh, it's very clear that some exploits have definitely been written by
looking at the source code with automated tools or by instrumenting
things, and that the exploits would likely have never been found without
source code. That's fine. We just have higher requirements in the open
source community.

And I do think that the same is true for being open about security
advisories: I think that to offset an open security list, we'd have to
then have more "best practices" than a vendor-sec-type closed security
list might need. I think it would be worth it.

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Original-Message-ID: <Pine.LNX.4.58.0501140731450.2310@ppc970.osdl.org>
Subject: Re: thoughts on kernel security issues
Date: Fri, 14 Jan 2005 15:47:39 GMT
Message-ID: <fa.gttvu62.8imqhi@ifi.uio.no>

On Fri, 14 Jan 2005, Horst von Brand wrote:
>
> But you can trivially run an executable via e.g.:
>
>     /lib/ld-2.3.4.so some-nice-proggie

I thought we fixed this, and modern ld-so's will fail on this if
"some-nice-proggie" cannot be mapped executably. Which is exactly what
we'd do.

[ scrounge scrounge ]

Yup, just checked - it's exactly the same case as MNT_NOEXEC, which indeed
used to have exactly that bug.

So the implementation of what I suggested (and no, I'm not at all
guaranteeing that this is a wonderful idea, I'm sure others have tried it
and it probably sucks) would be something like

	--- 1.161/mm/mmap.c	2005-01-12 08:26:28 -08:00
	+++ edited/mm/mmap.c	2005-01-14 07:37:51 -08:00
	@@ -882,9 +882,12 @@
	 		if (!file->f_op || !file->f_op->mmap)
	 			return -ENODEV;

	-		if ((prot & PROT_EXEC) &&
	-		    (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
	-			return -EPERM;
	+		if (prot & PROT_EXEC) {
	+			if (file->f_vfsmnt->mnt_flags & MNT_NOEXEC)
	+				return -EPERM;
	+			if (!capability(CAP_CAN_RUN_NONROOT) && file->f_dentry->d_inode->i_uid)
	+				return -EPERM;
	+		}
	 	}
	 	/*
	 	 * Does the application expect PROT_READ to imply PROT_EXEC?

(or just add a security hook there - it's not like this couldn't be a
SELinux thing..)

And no, this doesn't trap mprotect(), but that's not the point. The point
of this is not to make it impossible to execute code on purpose by some
existing binary - it's to make it impossible for some people to compile or
download their own binaries.

(Side note: this is probably useful for MIS kind of things - if you don't
want your users to download games etc, you'd want something like that. Of
course, MNT_NOEXEC in that case is fairly easy, and the "run programs
capability" is more a "this also works for arbitrary servers etc" things).

Alan's point about perl is well taken, though. Perl is a pretty damn
generic interpreter, and unlike most interpreters exposes everything. And
I doubt it uses "mmap(.. PROT_EXEC)" to map in the file ;)

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501131307430.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 21:38:49 GMT
Message-ID: <fa.gudjte7.82iq9j@ifi.uio.no>

On Thu, 13 Jan 2005, Arjan van de Ven wrote:
>
> On Thu, 2005-01-13 at 19:41 +0000, Alan Cox wrote:
>
> > So the non-disclosure argument is perhaps put as "equality of access at
> > the point of discovery means everyone gets rooted.". And if you want a
> > lot more detail on this read papers on the models of security economics
> > - its a well studied field.
>
> or in other words: you can write an exploit faster than y ou can write
> the fix, so the thing needs delaying until a fix is available to make it
> more equal.

That's a bogus argument, and anybody who looks at MS practices and
is at all honest with himself should see it as a bogus argument.

I think MS _still_ to this day will stand up and say that they have had no
zero-day exploits. Exactly because they count "zero-day" as the day things
get publically released. Never mind that exploits where (and are)
privately available on cracking networks for months before. They just
haven't been publically released BECAUSE EVERYBODY IS PARTICIPATING IN THE
GAME.

The written rule in this community is "no honest person will report a bug
before its time is through". Which automatically means that you get
branded as being "bad" if you ever rock the boat. That's a piece of
bullshit, and anybody who doesn't admit it is being totally dishonest with
himself.

Me, I consider that to be dirty.

Does Linux have a better track record than MS? Damn right it does. We've
had fewer problems, and I think there are more people out there standing
up for what's right anyway. Less PR people deathly afraid of rockign the
boat. Better technology, and fewer horrid design mistakes.

But that doesn't mean that all the same things aren't true for vendor-sec
that are true for MS. They are just bad to a (much, I hope) smaller
degree.

So instead, let's look at FACTS:

 - fixing a security bug is almost always much easier than writing an
   exploit.  Arjan, your argument simply isn't true except for the worst
   possible fundamental design issues. You should know that. In the case
   of "uselib()", it was literally four lines of obvious code - all the
   rest was just to make sure that there weren't any other cases like that
   lurking around.

 - There are more white-hats around than black-hats, but they are often
   less "driven" and motivated. Now _that_, I would argue, is the real
   problem with early disclosure - motivation.  The people really
   motivated to find the bugs are the people who are also motivated to
   mis-use them. However, vendor-sec and "the game" just makes it more
   worth-while for security firms to participate in it - it gives them the
   "good PR" thing. And how much can you trust the "gray hats"?

And this is why I believe vendor-sec is part of the problem. If you don't
see that, then you're blinding yourself to the downsides, and trying to
only look at the upsides.

Are there advantages and upsides? Yes. Are there disadvantages?
Indubitably. And anybody who disregards the disadvantages as "inevitable"
is not really interested in fixing the game.

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501131433210.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 22:49:26 GMT
Message-ID: <fa.gtdhu63.b2oqhn@ifi.uio.no>

On Thu, 13 Jan 2005, Alan Cox wrote:
>
> On Iau, 2005-01-13 at 21:22, Linus Torvalds wrote:
> > Are there advantages and upsides? Yes. Are there disadvantages?
> > Indubitably. And anybody who disregards the disadvantages as "inevitable"
> > is not really interested in fixing the game.
>
> So the next time I find a remote root hole I should post an exploit
> example targetting kernel.org to the linux-kernel list ? Now where are
> you going to publish the fix - bk is down, kernel.org is down ...
>
> Disclosre isn't quite as simple as you'd like.

This is like saying "somebody will do the bad thing, it might as well be
me". I don't believe that is a basis for doing things right.

First off, I've tried to make it clear that while I believe in openness,
my beliefs are not exclusive to anybody elses beliefs. I'd rather see
shades of gray than absolute black-and-white.

Secondly, I'd much rather have the mindset where we try to minimize the
likelihood of a catastrophic failure. That includes having many
_different_ ways of gettign things out: Bk, tar-balls, email. Diversity is
a _fundamental_ security strength. It also includes having diversity in
other areas, ie multiple architectures.

I see vendor-sec as trying to treat the symptoms. It's a "take two
aspirins, call me in the morning". And you seem to not even want to
discuss treating the disease - and vendor-sec is PART of the disease. It's
the drug that people get addicted to when they decided to treat the
symptoms.

I think Linux - just by the source being open - has one real treatmeant to
one fundamental -cause- of insecurity, namely "we don't care, and we'll
put our heads in the sane". Open source just doesn't allow that mentality.

And similarly, I think truly open disclosure is another fundamental
-treatment-, in that it doesn't _allow_ the mentality that vendor-sec
tends to instill in people.  Well, maybe not "treatment" per se: it's more
like admitting you have a problem.

It's like alcoholism. Admitting you have a problem is the first step.
vendor-sec is the band-aid that allows you to try to ignore the problem
("I can handle it - I could stop any day").

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501131206340.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 20:19:10 GMT
Message-ID: <fa.gttjte6.biuq9i@ifi.uio.no>

On Thu, 13 Jan 2005, Dave Jones wrote:
>
> When issues get leaked, the incentive for a researcher to use the
> same process again goes away, which hurts us.  Basically, trying
> to keep them happy is in our best interests.

Not so.

_balancing_ their happiness with our needs is what's in our best
interests. Yes, we should encourage them to tell us, but totally bending
over backwards is definitely the wrong thing to do.

In fact, right now we seem to encourage even people who do _not_
necessarily want the delay and secrecy to go over to vendor-sec, just
because the vendor-sec people are clearly arguing even against
alternatives.

Which is something I do not understand. The _apologia_ for vendor-sec is
absolutely stunning. Even if there are people who want to only interface
with a fascist vendor-sec-style absolute secrecy list, THAT IS NOT AN
EXCUSE TO NOT HAVE OPEN LISTS IN _ADDITION_!

In other words, I really don't understand this total subjugation by people
to the vendor-sec mentaliy. It's a disease, I tell you.

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501131255590.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 21:14:57 GMT
Message-ID: <fa.guttum5.8i4r1h@ifi.uio.no>

On Thu, 13 Jan 2005, Alan Cox wrote:
>
> I'm all for an open list too. Its currently called linux-kernel. Its
> full of such reports, and most of them are about new code or trivial
> holes where secrecy is pointless. Having an open linux-security list so
> they don't get missed as the grsecurity stuff did (and until I got fed
> up of waiting the coverity stuff did) would help because it would make
> sure that it didn't get buried in the noise.

Yes. But I know people send private emails because they don't want to
create a scare, so I think we actually have several levels of lists:

 - totally open: linux-kernel, or an alternative with lower noise

   We've kind of got this, but things get lost in the noise, and "white
   hat" people don't like feeling guilty about announcing things.

 - no embargo, no rules, but "private" in the sense that it's supposed to
   be for kernel developers only or at least people who won't take
   advantage of it.

   _I_ think this is the one that makes sense. No hard rules, but private
   enough that people won't feel _guilty_ about reporting problems. Right
   now I sometimes get private email from people who don't want to point
   out some local DoS or similar, and that can certainly get lost in the
   flow.

 - _short_ embargo, for kernel-only. I obviously believe that vendor-sec
   is whoring itself for security firms and vendors. I believe there would
   be a place for something with stricter rules on disclosure.

 - vendor-sec. The place where you can play any kind of games you want.

It's not a black-and-white thing. I refuse to believe that most security
problems are found by people without any morals. I believe that somewhere
in the middle is where most people feel most comfortable.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501131442550.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 23:09:30 GMT
Message-ID: <fa.gutpue2.8igr9m@ifi.uio.no>

On Thu, 13 Jan 2005, Alan Cox wrote:
>
> >  - _short_ embargo, for kernel-only. I obviously believe that vendor-sec
> >    is whoring itself for security firms and vendors. I believe there would
> >    be a place for something with stricter rules on disclosure.
>
> Seems these two could be the same list with a bit of respect for users
> wishes and common sense.

Possibly. On the other hand, I can well imagine that the list of
subscribers is different for the two cases. The same way I refuse to have
anything to do with vendor-sec, maybe somebody else refuses to honor even
a five-day rule, but would want to be on the "no rules, but let's be clear
that we're all good guys, not gray or black-hats.

Also, especially with a hard rule, there's just less confusion, I think,
if the two are separate. Otherwise you'd have to have strict Subject: line
rules or something - which basically means that they are separate lists
anyway.

But hey, it's not even clear that both are needed. With a short enough
disclosure requirement, maybe people feel like the "five-day rule,
possible explicitly _relaxed_ by the original submitter" is sufficient.

			Linus

Newsgroups: fa.linux.kernel
From: "Theodore Ts'o" <tytso@mit.edu>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <20050114183415.GA17481@thunk.org>
Date: Fri, 14 Jan 2005 18:37:34 GMT
Message-ID: <fa.d6o5eui.1t5itjc@ifi.uio.no>

On Thu, Jan 13, 2005 at 01:03:22PM -0800, Linus Torvalds wrote:
>
>  - _short_ embargo, for kernel-only. I obviously believe that vendor-sec
>    is whoring itself for security firms and vendors. I believe there would
>    be a place for something with stricter rules on disclosure.
>
>  - vendor-sec. The place where you can play any kind of games you want.
>

Linus,

	I think you're being a bit unfair here.  I've been on
vendor-sec since almost its very beginnings, and it's not nearly as
politically driven as you seem to make it out to be.

	Now, that may be because I've seen the early days of CERT,
where I saw an lpr/lpd hole get covered up for some 9 months before I
gave up tracking to see when they would ever bother to issue a CERT
advisory.  *That's* whoring itself to vendors, where CERT would delay
advisories to keep pace with the slowest vendor, because CERT was a
heavy-weight organization that was beholden to vendors in order to
meet its payroll.  Vendor-sec, because it's a mailing list that is
quite frankly, extremely informally organized, especially compared
many of the other security fora that exist out there, doesn't have
many of the shortcomings of CERT, thanks be to $DEITY.

	That being said, part of the problem here is that everybody
has different standards for when they would like to be informed.  Some
people *like* wearing a pager and even if a security vulnerability is
found at 4am on the Tuesday before Thanksgiving, to rush out, download
a kernel.org kernel, and install it on 500 production critical
machines all over their corporate network within the next eight hours.
Other people would prefer that public releases be delayed until after
public holidays --- so they can get back from visiting their family in
Vermont, where cell phones and pagers don't work so well.

	Similarly people who find and disclose security holes do so
for a very large variety of reasons.  Some of them do it for the
glory; some of them do it because they are trying to drive business to
their security firms; and some of them, believe it or not, do it
because they are trying to make the world a better place.  (You know,
like some open source developers.  :-)

	The people who find and report security holes have a very wide
range of opinions about full versus partial disclosure.  Some of them
take very seriously the possibility of what might happen if they were
to perform full disclosure on some vulnerability, and if an attacker
were to be able to use it to rewire the gates to the Grand Coulee Dam,
and cause huge loss of life, they would consider themselves as least
partially morally culpable.  Other people might say that the upside of
getting the news out faster outweighs any delay at all, even there are
some security breeches that cause loss of life or property.  I don't
hold with that position, but it is an intellectually defensible one.

	As a result, it is a highly religious, extremely charged
emotional issue, and the arguments on *both* sides of the fence tend
to go over the top; I've seen high levels of rhetorical arguing for
both full and delayed disclosure.  I also don't think we're going to
settle this issue any time soon.  We will probably come to some grand
consensus on the emacs versus vi issue first.


	It's probably not going to be helpful to say that vendor-sec
is "whoring itself" because some people who report vulnerabilities say
that they will only report them under certain conditions.  Maybe you
would prefer it if some group of vendors would say "no thank you" if
someone were to attach those conditions to a security report.  That's
a choice you've made, and that's fine.

	But please reflect that the glory-hounds would in fact get
more attention if they were to announce their findings right away,
along with the exploit that does something public and visible, such as
taking down kernel.org ---- and that sometimes the security
researchers who insist on delayed disclosure are doing so out of the
best of intentions, and will only work with organizations that repsect
their requests.  You may not agree with them, but name calling is not
going to help matters.


	I think this is much like your position about licensing.
People can choose whatever license they want on their code.  But if
they choose a particular license, then you better damn well respect
it.  Similarly, if someone tells you that they will only tell you
about a security vulnerability if you agree not to release it until 1
week later, then you are honor bound either to (a) respect their
request of confidentiality, or (b) refuse to accept the information.
Either is an honorable choice.

	However, there have been some on this thread (not you) that
have claimed that vendor-sec should ignore the requests for delayed
disclosure and make public information where the reporter has said,
"I'll only give you this information if you promise to use it in the
following restricted way".  That's just dealing in bad faith, and I
reject that.  People of good will can, and have, and will no doubt
continue, to disagree about whether some level of delayed disclosure
is a good thing.

	I believe that delays of less than 7-10 days are a good thing,
and that scheduling public releases to avoid making a security problem
public at 5pm on Christmas eve, is a good thing.  I would not agree
with six month delays, and I think I've heard you say that a few days
to perhaps a week on the outside you might think would be acceptable.
The point is that there is a huge middle ground here, and in fact I
think most people participating on this thread are somewhere within
this vast middle ground --- I haven't heard anyone saying that the
(historical) CERT-style "delay for six months" is a good thing.

							- Ted

P.S.  As other people have noted, if the reporter says that they plan
to do immediate full/public disclosure, vendor-sec will work with
people who feel that way, and immediately get word out.  Vendor-sec
does *not* only work with delayed disclosure issues, and does not
insist that people hold back on reports, contrary to what some people
have claimed.  It has and always will be up to the person who
discovered the vulnerability to decide how to release it.

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501141047470.2310@ppc970.osdl.org>
Date: Fri, 14 Jan 2005 19:23:57 GMT
Message-ID: <fa.gudlue8.82sr9k@ifi.uio.no>

On Fri, 14 Jan 2005, Theodore Ts'o wrote:
>
> 	But please reflect that the glory-hounds would in fact get
> more attention if they were to announce their findings right away,
> along with the exploit that does something public and visible, such as
> taking down kernel.org ---- and that sometimes the security
> researchers who insist on delayed disclosure are doing so out of the
> best of intentions, and will only work with organizations that repsect
> their requests.  You may not agree with them, but name calling is not
> going to help matters.

I disagree violently.

What vendor-sec does is to make it "socially acceptable" to be a parasite.

I personally think that such behaviour simply should not be encouraged. If
you have a security "researcher" that has some reason to delay his
disclosure, you should see for for what he is: looking for cheap PR. You
shouldn't make excuses for it. Any research organization that sees PR as a
primary objective is just misguided.

Also, there's a more fundamental issue: the "glorification" of bugs. Bugs
aren't news. We have various small bugs all the time, and many of them are
at least potential local DoS issues. Suppression of information is what
_makes_ these bugs news.

So I dislike the _culture_ that vendor-sec encourages. THAT is the real
problem. And hey, it may be better than some other places. Goodie. But
dammit, it needs somebody to be critical about it too.

What's the alternative? I'd like to foster a culture of

 (a) accepting that bugs happen, and that they aren't news, but making
     sure that the very openness of the process means that people know
     what's going on exactly because it is _open_, not because some news
     organization had to make a big stink about it just to make a vendor
     take notice.

     Right now, people seem to think that big news media warnings on
     cnet.com about SP2 fixing 15 vulnerabilities or similar is the proper
     way to get people to upgrade. That just -cannot- be right.

 (b) reporting a bug openly is _good_, and not frowned upon (right now
     people clearly try to steer even white-hat people who have no real
     incentive to use vendor-sec into that mentality - because it's the
     "proper channel")

And yes, for this to work people need to get away from the notion of
"let's apply vendor patch X to fix problem Y". What we should strive for
(and what the whole system should be _geared_ for) is to have redundant
enough security that people hopefully don't know of <n> outstanding bugs
at the same time that allows for a combination attack.

I'm convinced most security firms are like the virus firms: they react.
They react to things they see on the cracker lists etc. They use a lot of
the same tools to find problems that really bad people find. That means
that the problems they "discover" are often discovered by the bad guys
first.  Sure, they have their own people too, but that's like saying that
_we_ have our own people too.

And that makes the whole "nondisclosure to avoid bad people" argument
pretty much totally bogus, something that nobody who argues for vendor-sec
seems to be willing to accept.

And let's not kid ourselves: the security firms may have resources that
they put into it, but the worst-case scenario is actual criminal intent.
People who really have resources to study security problems, and who have
_no_ advantage of using vendor-sec at all. And in that case, vendor-sec is
_REALLY_ a huge mistake.

			Linus

Newsgroups: fa.linux.kernel
From: "Theodore Ts'o" <tytso@mit.edu>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <20050114221343.GA18140@thunk.org>
Date: Fri, 14 Jan 2005 22:29:11 GMT
Message-ID: <fa.d6njeme.1o58ure@ifi.uio.no>

On Fri, Jan 14, 2005 at 11:15:19AM -0800, Linus Torvalds wrote:
>
> What vendor-sec does is to make it "socially acceptable" to be a parasite.
>
> I personally think that such behaviour simply should not be encouraged. If
> you have a security "researcher" that has some reason to delay his
> disclosure, you should see for for what he is: looking for cheap PR.

I disagree.  First of all, we can't know what motivates someone, and
presuming that we know their motivation is something that should only
be done with the greatest of care.  Secondly, someone who does want
cheap PR can do so without delaying their disclosure; they can issue a
breathless press release or "security advisory" about a DOS attack
just easily with a zero-day disclosure as they can with a two-week
delayed disclosure.

Sure, there are less-than-savory security firms that are only after PR
to drive business.  But that's completely orthogonal to whether or not
the disclosure is delayed or not.  Yes, "glorification" of relatively
trivial bugs is a problem; but whether or not the bugs are delayed
doesn't change whether someone issues an "iOFFENSE SECURITY ADVISORY"
which overstates the bug; it only changes whether they send the
advisory right away or a week or two later.  (After all, the security
groups that subscribe to a zero-day "full disclosure" policy use
advisory/press releases glorifies their findings just as much.)

>  (a) accepting that bugs happen, and that they aren't news, but making
>      sure that the very openness of the process means that people know
>      what's going on exactly because it is _open_, not because some news
>      organization had to make a big stink about it just to make a vendor
>      take notice.

A one or two week delay is hardly cause for "a news organization to
make a big stick so vendors will take notice".  Besides, which is it?
Are it about security researchers that are after cheap PR, or "news
organizations forcing vendors to take notice"?  Certainly I've never
that kind of dynamic with Linux vendors where reporters are trying to
get vendors to take notice; it doesn't matter whether take notice if
they are going to be releasing in two weeks later come hell or high
water.

> And yes, for this to work people need to get away from the notion of
> "let's apply vendor patch X to fix problem Y". What we should strive for
> (and what the whole system should be _geared_ for) is to have redundant
> enough security that people hopefully don't know of <n> outstanding bugs
> at the same time that allows for a combination attack.

Here, we certainly agree.

> And let's not kid ourselves: the security firms may have resources that
> they put into it, but the worst-case scenario is actual criminal intent.
> People who really have resources to study security problems, and who have
> _no_ advantage of using vendor-sec at all. And in that case, vendor-sec is
> _REALLY_ a huge mistake.

Nah.  If you have criminal intent, generally there are far easier ways
to target a specific company.  For example, many companies that have
multiple layers of firewalls, intrusion detection systems, etc., will
keep critical financial information in boxes left unlocked in the
hallways, and not bother to do any kind of background checks before
hiring temporary employees/contractors.  Sad but true.

I'm quite certain that far more economic damage is being done by
script kiddies and by "insiders" using officially granted privileges
to access financial applications than by the hypothetical Dr. Evil
that hires computer experts to find vulnerabilities that could be used
to cary out criminal intent.  And it's the script kiddies that we can
prevent by delaying disclosures by only a week or two, to give a
chance to get the fixes out to the people who need them.

						- Ted

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501141444360.2310@ppc970.osdl.org>
Date: Fri, 14 Jan 2005 22:59:24 GMT
Message-ID: <fa.gttrue5.bimr9n@ifi.uio.no>

On Fri, 14 Jan 2005, Theodore Ts'o wrote:
>
> I disagree.  First of all, we can't know what motivates someone, and
> presuming that we know their motivation is something that should only
> be done with the greatest of care.  Secondly, someone who does want
> cheap PR can do so without delaying their disclosure; they can issue a
> breathless press release or "security advisory" about a DOS attack
> just easily with a zero-day disclosure as they can with a two-week
> delayed disclosure.

Your "secondly" is bogus.

Sure, you can do that, and if you do that, then the world recognizes you
for what you are - nothing but a publicity-seeking creep.

THAT is why vendor-sec is bad. It allows publicity-seeking creeps to take
on the mantle of being "good".

I'm arguing for exposing them for what they are. If that hurts some
feelings, tough ;)

> >  (a) accepting that bugs happen, and that they aren't news, but making
> >      sure that the very openness of the process means that people know
> >      what's going on exactly because it is _open_, not because some news
> >      organization had to make a big stink about it just to make a vendor
> >      take notice.
>
> A one or two week delay is hardly cause for "a news organization to
> make a big stick so vendors will take notice".

You ignore reality.

It's not a one- or two-week delay. Once the vendor-sec mentality takes
effect, the delay inevitably grows. You _always_ have excuses for
delaying, and as shown by this thread, a _lot_ of people believe them.

Also, even a one- or two-week delay _is_ actually detrimental. It means
that you can't handle the problem when it happens, so it gets queued up.
People cannot inform unrelated third parties about their patches (because
they are embargoed), which means that they get out of sync, and suddenly
the thing that open source is so good at - namely making communication
work well - becomes a problem.

> > And let's not kid ourselves: the security firms may have resources that
> > they put into it, but the worst-case scenario is actual criminal intent.
> > People who really have resources to study security problems, and who have
> > _no_ advantage of using vendor-sec at all. And in that case, vendor-sec is
> > _REALLY_ a huge mistake.
>
> Nah.  If you have criminal intent, generally there are far easier ways
> to target a specific company.

The spam-viruses clearly show that that isn't always true, though. The
advantage to targeting the whole infrastructure _is_ clearly there.

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: security contact draft
Original-Message-ID: <Pine.LNX.4.58.0501131325560.2310@ppc970.osdl.org>
Date: Thu, 13 Jan 2005 21:43:09 GMT
Message-ID: <fa.gutptu5.8ioqph@ifi.uio.no>

On Thu, 13 Jan 2005, Alan Cox wrote:
>
> It's not documenting the stuff Linus seems to be talking about which is
> a public list ? Or does Linus want both ?

I see myself as pretty extreme when it comes to my approach to security.

And I actually distrust extremes. I'm at one end of the spectrum, and
vendor-sec is at the other (I'm not even counting the head-in-the-sand
approach as part of the spectrum ;). Knowing that, I'd expect that most
people are somewhere in between.

Which to me implies that while what I personally _want_ is total openness,
that's not necessarily what makes the most sense in real life.

So I want to give people choice. I want to encourage openness. But hell,
if we have a closed list with a declared short embargo that is known to
not play games (ie clock starts ticking from original discovery, not from
somebody elses embargo), that's good too.

Let people vote with their feet. If vendor-sec ends up being where all the
"important" things are discussed - so be it. We've not lost anything, and
at worst a "kernel-security" list would be a way to discuss stuff that was
already released by vendor-sec.

			Linus

Newsgroups: fa.linux.kernel
Subject: Re: thoughts on kernel security issues
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Sat, 15 Jan 2005 01:56:52 GMT
Message-ID: <fa.lg73c0n.1ihidpp@ifi.uio.no>

On Gwe, 2005-01-14 at 22:51, Linus Torvalds wrote:
> Sure, you can do that, and if you do that, then the world recognizes you
> for what you are - nothing but a publicity-seeking creep.

And what does that make writing your own operating system ? Some of the
security folks are publicity seekers, others see it as an investment
against getting a job by becoming known. Quite a few we deal with a
large professional organisations who don't need publicity and actually
the more interesting bodies often don't *want* publicity just to ensure
that all their vendors have fixes before things go public and that their
government infrastructure and nation state will be best served.

> THAT is why vendor-sec is bad. It allows publicity-seeking creeps to take
> on the mantle of being "good".

They don't agree with you, nor do the economists I'm afraid.

> I'm arguing for exposing them for what they are. If that hurts some
> feelings, tough ;)

Its ok I'm sure they think you are an arrogant clueless jerk 8)

> It's not a one- or two-week delay. Once the vendor-sec mentality takes
> effect, the delay inevitably grows. You _always_ have excuses for
> delaying, and as shown by this thread, a _lot_ of people believe them.

The "vendor-sec" mentality - from someone who has never been involved in
it. Ah yes Linus you might want to consider writing articles for a local
newspaper you appear to have the right qualifications for it 8)

vendor-sec has a lot of people on it who don't like long non-disclosure
periods and get quite annoyed when they happen out of our control (eg
CERT originated notifications).

Alan

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501142018540.2310@ppc970.osdl.org>
Date: Sun, 16 Jan 2005 15:39:09 GMT
Message-ID: <fa.gvdftm9.92qq1r@ifi.uio.no>

On Sat, 15 Jan 2005, Alan Cox wrote:
>
> vendor-sec has a lot of people on it who don't like long non-disclosure
> periods and get quite annoyed when they happen out of our control (eg
> CERT originated notifications).

Hey, fair enough. I tend to see the problem cases, which may be why I
absolutely detest it. Statistical self-selection and all that.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501260803360.2362@ppc970.osdl.org>
Date: Wed, 26 Jan 2005 16:15:17 GMT
Message-ID: <fa.gte3uu8.b2er9g@ifi.uio.no>

On Wed, 26 Jan 2005, Jesse Pollard wrote:
>
> And covering the possible unknown errors is a good way to add protection.

I heartily agree. The more we can do to make the inevitable bugs be less
likely to be security problems, the better off we are. Most of that ends
up being design - trying to avoid design decisions that just drive every
bug to be an inevitable security problem.

The biggest part of that is having nice interfaces. If you have good
interfaces, bugs are less likely to be problematic. For example, the
"seq_file" interfaces for /proc were written to clean up a lot of common
mistakes, so that the actual low-level code would be much simpler and not
have to worry about things like buffer sizes and page boundaries. I don't
know/remember if it actually fixed any security issues, but I'm confident
it made them less likely, just by making it _easier_ to write code that
doesn't have silly bounds problems.

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: thoughts on kernel security issues
Original-Message-ID: <Pine.LNX.4.58.0501261151010.2362@ppc970.osdl.org>
Date: Wed, 26 Jan 2005 23:59:27 GMT
Message-ID: <fa.gsdc066.a2iq1i@ifi.uio.no>

On Wed, 26 Jan 2005, Olaf Hering wrote:
> >
> > Details, please?
>
> You did it this way:
> http://linux.bkbits.net:8080/linux-2.5/cset@4115cba3UCrZo9SnkQp0apTO3SghJQ

Oh, that's a separate issue. We want to have multiple levels of security.

We not only try to make sure that there are easy interfaces (but yeah, I
don't force people to rewrite - I sadly don't have a cadre of slaves at my
beck and call ;p), but it's also always a good idea to have interfaces
that are bug-resistant even in the face of people actively not using the
better interfaces.

So having good interfaces that are harder to have bugs in does _not_ mean
that we still shouldn't have defensive programming practices anyway. The
combination of the two means that a bug in one layer hopefully gets caught
be the other layer.

		Linus