thoughts on kernel security issues

2 views
Skip to first unread message

Chris Wright

unread,
Jan 12, 2005, 12:49:44 PM1/12/05
to ak...@osdl.org, torv...@osdl.org, al...@lxorguk.ukuu.org.uk, marcelo...@cyclades.com, linux-...@vger.kernel.org
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.

http://www.wiretrip.net/rfp/policy.html

Right now most things come in via 1) lkml, 2) maintainers, 3) vendor-sec.
It would be nice to have a more centralized place for all of this
information to help track it, make sure things don't fall through
the cracks, and make sure of timely fix and disclosure.

In addition, I think it's worth considering keeping the current stable
kernel version moving forward (point releases ala 2.6.x.y) for critical
(mostly security) bugs. If nothing else, I can provide a subset of -ac
patches that are only that.

I volunteer to help with _all_ of the above. It's what I'm here for.
Use me, abuse me ;-)

thanks,
-chris

===== MAINTAINERS 1.269 vs edited =====
--- 1.269/MAINTAINERS 2005-01-10 17:29:35 -08:00
+++ edited/MAINTAINERS 2005-01-11 13:29:23 -08:00
@@ -1959,6 +1959,11 @@ M: chri...@weinigel.se
W: http://www.weinigel.se
S: Supported

+SECURITY CONTACT
+P: Security Officers
+M: kernel-security@{vger.kernel.org, osdl.org, wherever}
+S: Supported
+
SELINUX SECURITY MODULE
P: Stephen Smalley
M: s...@epoch.ncsc.mil
===== REPORTING-BUGS 1.2 vs edited =====
--- 1.2/REPORTING-BUGS 2002-02-04 23:39:13 -08:00
+++ edited/REPORTING-BUGS 2005-01-10 15:35:10 -08:00
@@ -16,6 +16,9 @@ code relevant to what you were doing. If
describe how to recreate it. That is worth even more than the oops itself.
The list of maintainers is in the MAINTAINERS file in this directory.

+ If it is a security bug, please copy the Security Contact listed
+in the MAINTAINERS file. They can help coordinate bugfix and disclosure.
+
If you are totally stumped as to whom to send the report, send it to
linux-...@vger.kernel.org. (For more information on the linux-kernel
mailing list see http://www.tux.org/lkml/).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linus Torvalds

unread,
Jan 12, 2005, 1:12:15 PM1/12/05
to Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, marcelo...@cyclades.com, linux-...@vger.kernel.org

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

Marcelo Tosatti

unread,
Jan 12, 2005, 1:32:28 PM1/12/05
to Chris Wright, ak...@osdl.org, torv...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org

Hi Chris!

On Wed, Jan 12, 2005 at 09:48:07AM -0800, 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.
>
> http://www.wiretrip.net/rfp/policy.html
>
> Right now most things come in via 1) lkml, 2) maintainers, 3) vendor-sec.
> It would be nice to have a more centralized place for all of this
> information to help track it, make sure things don't fall through
> the cracks, and make sure of timely fix and disclosure.

I very much like the idea and I also think a "official" list of kernel security issues and
respective fixes is very much required, since not every Linux distribution is supposed
to have kernel developers working for them, going through the whole changelogs
looking for security issues, which is just silly.

Disclosing and bookkeeping of security issues is a job of the Linux kernel team.

Alan used to list down security fixes between each v2.2 release, v2.4 has never
had such an official list (I'm trying to write CAN numbers on the changelogs lately),
neither v2.6. Its not a practical thing for Linus/Andrew to do, its a lot of
work.

It would be interesting to have all developers to know about such initiative
and have them send their security fixes to be logged and disclosed - its obviously
impossible for you to read all changes in the kernel. And have Linus/Andrew
advocate in favour of it.

IMO such initiative needs to be known by all contributors for
it to be effective.

> In addition, I think it's worth considering keeping the current stable
> kernel version moving forward (point releases ala 2.6.x.y) for critical
> (mostly security) bugs. If nothing else, I can provide a subset of -ac
> patches that are only that.

Yes, -ac has been playing that role. It is general consensus that
such point releases are required.

Linus doesnt do it because it is too much extra work him (and he is focused
on other things), glad you have stepped up.

> I volunteer to help with _all_ of the above. It's what I'm here for.
> Use me, abuse me ;-)

You've been doing a lot of security work/auditing in the kernel for a long time,
which fits the job position nicely.

I'm willing to help.

Chris Wright

unread,
Jan 12, 2005, 1:51:10 PM1/12/05
to Linus Torvalds, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, marcelo...@cyclades.com, linux-...@vger.kernel.org
* Linus Torvalds (torv...@osdl.org) wrote:
> 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.

Right, I know you don't like the embargo stuff.

> 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, ...?

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

Chris Wright

unread,
Jan 12, 2005, 1:57:33 PM1/12/05
to Marcelo Tosatti, Chris Wright, ak...@osdl.org, torv...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
* Marcelo Tosatti (marcelo...@cyclades.com) wrote:
> On Wed, Jan 12, 2005 at 09:48:07AM -0800, Chris Wright wrote:
> > Right now most things come in via 1) lkml, 2) maintainers, 3) vendor-sec.
> > It would be nice to have a more centralized place for all of this
> > information to help track it, make sure things don't fall through
> > the cracks, and make sure of timely fix and disclosure.
>
> I very much like the idea and I also think a "official" list of kernel security issues and
> respective fixes is very much required, since not every Linux distribution is supposed
> to have kernel developers working for them, going through the whole changelogs
> looking for security issues, which is just silly.
>
> Disclosing and bookkeeping of security issues is a job of the Linux kernel team.

Yes, I agree.

> Alan used to list down security fixes between each v2.2 release, v2.4 has never
> had such an official list (I'm trying to write CAN numbers on the changelogs lately),
> neither v2.6. Its not a practical thing for Linus/Andrew to do, its a lot of
> work.
>
> It would be interesting to have all developers to know about such initiative
> and have them send their security fixes to be logged and disclosed - its obviously
> impossible for you to read all changes in the kernel. And have Linus/Andrew
> advocate in favour of it.
>
> IMO such initiative needs to be known by all contributors for
> it to be effective.

Indeed, it would be most effective as a collective effort. Of course,
we'll never make 100%, but we could do better than now.

> > In addition, I think it's worth considering keeping the current stable
> > kernel version moving forward (point releases ala 2.6.x.y) for critical
> > (mostly security) bugs. If nothing else, I can provide a subset of -ac
> > patches that are only that.
>
> Yes, -ac has been playing that role. It is general consensus that
> such point releases are required.
>
> Linus doesnt do it because it is too much extra work him (and he is focused
> on other things), glad you have stepped up.
>
> > I volunteer to help with _all_ of the above. It's what I'm here for.
> > Use me, abuse me ;-)
>
> You've been doing a lot of security work/auditing in the kernel for a long time,
> which fits the job position nicely.
>
> I'm willing to help.

Great, thanks!


-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

Greg KH

unread,
Jan 12, 2005, 2:01:00 PM1/12/05
to Linus Torvalds, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, marcelo...@cyclades.com, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 10:05:34AM -0800, Linus Torvalds wrote:
>
>
> 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.

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.

I understand your dislike of having to wait once you know of a security
issue before making the fix public, but how should distros coordinate
fixes in any other way?

thanks,

greg k-h

Linus Torvalds

unread,
Jan 12, 2005, 2:05:06 PM1/12/05
to Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, marcelo...@cyclades.com, linux-...@vger.kernel.org

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

Linus Torvalds

unread,
Jan 12, 2005, 2:13:03 PM1/12/05
to Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, marcelo...@cyclades.com, linux-...@vger.kernel.org

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

Chris Wright

unread,
Jan 12, 2005, 2:32:43 PM1/12/05
to Linus Torvalds, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, marcelo...@cyclades.com, linux-...@vger.kernel.org
* Linus Torvalds (torv...@osdl.org) wrote:
> 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.

That's what I figured you meant.

> 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.

Agreed.

> 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.

There is value in coordinating with vendors, namely to keep them from
being caught with pants down. But vendor-sec already does this part
well enough.

> 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.

Well, easiest for me is here ;-)

thanks,


-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

Greg KH

unread,
Jan 12, 2005, 2:36:24 PM1/12/05
to Linus Torvalds, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, marcelo...@cyclades.com, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 11:01:42AM -0800, Linus Torvalds wrote:
>
>
> 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?

I think the issue is that there is no main "security" contact for the
kernel. If we want to make vendor-sec that contact, fine, but we better
warn the vendor-sec people :)

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

vendor-sec handles a lot of other stuff that is not kernel related
(every package that is in a distro.) This would only be for the kernel.

thanks,

greg k-h

Marcelo Tosatti

unread,
Jan 12, 2005, 2:48:48 PM1/12/05
to Linus Torvalds, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 11:01:42AM -0800, Linus Torvalds wrote:
>
>
> 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.

Of course it matters Linus - vendors need time to prepare their updates. You
can't ignore that, and you can't "have nothing to do with it".

You seem to dislike the way embargos have been done on vendorsec, fine. They can
be done on a different way, but you have to understand that you and Andrew
need to follow and agree with the embargo.

How you feel about having short fixed time embargo's (lets say, 3 or 4 days) ?

The only reason for this is to have "time for the vendors to catch up", which
can be defined by the kernel security office. Nothing more - no vendor politics
involved.

It is a simple matter of synchronization.

Chris Wright

unread,
Jan 12, 2005, 2:48:48 PM1/12/05
to Greg KH, Linus Torvalds, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, marcelo...@cyclades.com, linux-...@vger.kernel.org
* Greg KH (gr...@kroah.com) wrote:
> On Wed, Jan 12, 2005 at 11:01:42AM -0800, Linus Torvalds wrote:
> > 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?
>
> I think the issue is that there is no main "security" contact for the
> kernel. If we want to make vendor-sec that contact, fine, but we better
> warn the vendor-sec people :)

Yes. And I think we should have our own contact.

> > In other words, if you allow embargoes and vendor politics, what would the
> > new list buy that isn't already in vendor-sec.
>
> vendor-sec handles a lot of other stuff that is not kernel related
> (every package that is in a distro.) This would only be for the kernel.

Yes, and IMO, it could inform vendor-sec.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

Florian Weimer

unread,
Jan 12, 2005, 2:53:06 PM1/12/05
to Chris Wright, linux-...@vger.kernel.org
* Chris Wright:

> 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?

Would this be anything but a secretary in front of vendor-sec?

> http://www.wiretrip.net/rfp/policy.html
>
> Right now most things come in via 1) lkml, 2) maintainers, 3) vendor-sec.
> It would be nice to have a more centralized place for all of this
> information to help track it, make sure things don't fall through
> the cracks, and make sure of timely fix and disclosure.

You mean, like issuing *security* *advisories*? *gasp*

I think this is an absolute must (and we are certainly not alone!),
but this project does not depend on the way the initial initial
contact is handled.

> + If it is a security bug, please copy the Security Contact listed
> +in the MAINTAINERS file. They can help coordinate bugfix and disclosure.

If this is about delayed disclosure, a few more details are required,
IMHO. Otherwise, submitters will continue to use their
well-established channels. Most people hesitate before posting stuff
they view sensitive to a mailing list.

Florian Weimer

unread,
Jan 12, 2005, 2:57:10 PM1/12/05
to Greg KH, linux-...@vger.kernel.org
* Greg KH:

>> In other words, if you allow embargoes and vendor politics, what would the
>> new list buy that isn't already in vendor-sec.
>
> vendor-sec handles a lot of other stuff that is not kernel related
> (every package that is in a distro.) This would only be for the kernel.

I don't know that much about vendor-sec, but wouldn't the kernel list
contain roughly the same set of people? vendor-sec also has people
from the *BSDs, I believe, but they should probably notified of Linux
issues as well (often, similar mistakes are made in different
implementations).

If the readership is the same, it doesn't make sense to run two lists,
especially because it's not a normal list and you have to be capable
to deal with the vetting.

I agree that embargoed lists are nasty, but sometimes, you have to
make personal sacrifices to further the cause. 8-(

Linus Torvalds

unread,
Jan 12, 2005, 3:05:49 PM1/12/05
to Marcelo Tosatti, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org

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

Linus Torvalds

unread,
Jan 12, 2005, 3:35:49 PM1/12/05
to Marcelo Tosatti, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org

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".

Chris Wright

unread,
Jan 12, 2005, 3:44:37 PM1/12/05
to Linus Torvalds, Marcelo Tosatti, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
* Linus Torvalds (torv...@osdl.org) wrote:
> 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"

I agree, and in most of these cases long delay are due to things
falling through cracks or not getting adequate cycles. Not so much
politics.

> 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.

That's more or less my take. Timely response to reporter, timely
debugging/bug fixing and timely disclosure.

> 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).

What about the reverse, and informing vendors? This is typical...project
security contact gets report, figures out bug, works with vendor-sec on
release date. In my experience, the long cycles rarely come from that
final negotiation. It's usually not much of a negotiation, rather a
"heads-up", "thanks".

The two goals: 1) timely response, fix, dislosure; and 2) not leaving
vendors with pants down; don't have to be mutually exclusive.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

Jesper Juhl

unread,
Jan 12, 2005, 4:09:27 PM1/12/05
to Linus Torvalds, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, marcelo...@cyclades.com, linux-...@vger.kernel.org
On Wed, 12 Jan 2005, Linus Torvalds wrote:
>
> 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.
>
Being firmly in the full disclosure camp I hope you intend to stick to
that "no entity (neither the reporter nor any particular vendor/developer)
can require silence" bit. If you do, and if embargoes are kept to short
nr. of days, then I think such a list would probably be a good idea. It
would be a good compromise between full disclosure from day one and things
being kept secret and out of view for months.


Just my 0.02euro.


--
Jesper Juhl

Greg KH

unread,
Jan 12, 2005, 4:09:27 PM1/12/05
to Chris Wright, Linus Torvalds, Marcelo Tosatti, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 12:27:11PM -0800, Chris Wright wrote:
> * Linus Torvalds (torv...@osdl.org) wrote:
> > 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.
>
> That's more or less my take. Timely response to reporter, timely
> debugging/bug fixing and timely disclosure.

That sounds sane to me too.

> > 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).
>
> What about the reverse, and informing vendors? This is typical...project
> security contact gets report, figures out bug, works with vendor-sec on
> release date. In my experience, the long cycles rarely come from that
> final negotiation. It's usually not much of a negotiation, rather a
> "heads-up", "thanks".

Vendors should also cc: the kernel-security list/contact at the same
time they would normally contact vendor-sec. I don't see a problem with
that happening, and would help out the people on vendor-sec from having
to wade through a lot of linux kernel specific stuff at times.

> The two goals: 1) timely response, fix, dislosure; and 2) not leaving
> vendors with pants down; don't have to be mutually exclusive.

I agree, having pants down when you don't want them to be isn't a good
thing :)

thanks,

greg k-h

Dave Jones

unread,
Jan 12, 2005, 4:13:54 PM1/12/05
to Linus Torvalds, Marcelo Tosatti, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 12:00:52PM -0800, Linus Torvalds 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".

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 ?

My first thought was 'Chris will forward the output of secu...@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.

At this time, those with bad intents rub their hands with glee
0wning boxes at will whilst those of us responsible for vendor
kernels run like headless chickens trying to get updates out,
which can be a pain the ass if $vendor is supporting some ancient
release which is afflicted by the same bug.

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

Thoughts?

Dave

Marcelo Tosatti

unread,
Jan 12, 2005, 4:19:04 PM1/12/05
to Linus Torvalds, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 12:00:52PM -0800, Linus Torvalds wrote:
>
>
> 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".

An important thing is that Mr. Torvalds agrees with the embargo, which you never
did, you always applied corrections for security bugs without being concerned
about a disclosure date agreement (which you have your own reasons and arguments
for, OK).

That makes vendorsec/etc uncomfortable submitting the information to you.

Great to hear you think differently and is willing to agree on a reasonable
embargo period.

The kernel security list must be higher in hierarchy than vendorsec.

Any information sent to vendorsec must be sent immediately for the kernel
security list and discussed there.

I'm sure one week is enough for vendors to prepare updates, and I'm sure they
will be fine with it.

> 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).

We all agree there is no good reason to embargo a kernel bug for more than
one week, given that the fix is known and settled.

> 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).

Wonderful.

Greg KH

unread,
Jan 12, 2005, 4:38:26 PM1/12/05
to Linus Torvalds, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, marcelo...@cyclades.com, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 10:57:25AM -0800, Linus Torvalds wrote:
> On Wed, 12 Jan 2005, Chris Wright wrote:
> > 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.

I think vger fits that bill, if for no other reason than to keep the
"osdl is taking over the kernel" rumors at bay :)

That is, if the vger postmasters agree.

thanks,

greg k-h

Marcelo Tosatti

unread,
Jan 12, 2005, 4:43:02 PM1/12/05
to Linus Torvalds, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 12:28:14PM -0800, Linus Torvalds wrote:
>
>
> 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.

I'm not a big fan of hiding security fixes - having a defined and clear
list of security issues is important. Moreover, the code itself is verbose
enough for some people.

If you release the code earlier than the embargo date, even with "non verbose
changelogs", to best serve the people who depend on us by giving them source
code that is as bug-free and secure as possible, you make the issue public.

IMO the best thing is to be very verbose about security problems - giving
credit to the people who deserve it accordingly (not stealing the thunder
from the discovers, but rather making more visible on the changelog who
they are).

The KSO (Kernel Security Officer, the new buzzword on the block) has to
control the embargo date and be strict about it.

> 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".

Exactly, and keeping under wraps means "obscure, unclear list of security issues".
We want the other way around.

Chris Wright

unread,
Jan 12, 2005, 6:22:10 PM1/12/05
to Florian Weimer, Greg KH, linux-...@vger.kernel.org
* Florian Weimer (f...@deneb.enyo.de) wrote:
> * Greg KH:
>
> >> In other words, if you allow embargoes and vendor politics, what would the
> >> new list buy that isn't already in vendor-sec.
> >
> > vendor-sec handles a lot of other stuff that is not kernel related
> > (every package that is in a distro.) This would only be for the kernel.
>
> I don't know that much about vendor-sec, but wouldn't the kernel list
> contain roughly the same set of people?

No.

> vendor-sec also has people
> from the *BSDs, I believe, but they should probably notified of Linux
> issues as well (often, similar mistakes are made in different
> implementations).

Take a look at <http://www.freebsd.org/security/index.html>. Pretty
good description. It's normal for projects to have their own security
contact to handle security issues. Once it's vetted, understood,
etc...it's normal to give vendors some heads-up.

> If the readership is the same, it doesn't make sense to run two lists,
> especially because it's not a normal list and you have to be capable
> to deal with the vetting.

It's not the same readership.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

Chris Wright

unread,
Jan 12, 2005, 7:34:26 PM1/12/05
to Florian Weimer, Chris Wright, linux-...@vger.kernel.org
* Florian Weimer (f...@deneb.enyo.de) wrote:
> * Chris Wright:
>
> > 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?
>
> Would this be anything but a secretary in front of vendor-sec?

Yes, it'd be the primary contact for handling kernel security issues.
Handling vendor coordination is only one piece of a handling security
issue.

> > http://www.wiretrip.net/rfp/policy.html
> >
> > Right now most things come in via 1) lkml, 2) maintainers, 3) vendor-sec.
> > It would be nice to have a more centralized place for all of this
> > information to help track it, make sure things don't fall through
> > the cracks, and make sure of timely fix and disclosure.
>
> You mean, like issuing *security* *advisories*? *gasp*

Yes, although we're not even tracking things well, let alone advisories.

> I think this is an absolute must (and we are certainly not alone!),
> but this project does not depend on the way the initial initial
> contact is handled.
>
> > + If it is a security bug, please copy the Security Contact listed
> > +in the MAINTAINERS file. They can help coordinate bugfix and disclosure.
>
> If this is about delayed disclosure, a few more details are required,
> IMHO. Otherwise, submitters will continue to use their
> well-established channels. Most people hesitate before posting stuff
> they view sensitive to a mailing list.

Yes, that's the point of coordinating the fix _and_ the disclosure.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

Hubert Tonneau

unread,
Jan 12, 2005, 8:18:57 PM1/12/05
to ak...@osdl.org, torv...@ppc970.osdl.org, linux-...@vger.kernel.org
Where is 2.6.10.1 with the security fix only ?

I have not yet finished to deal with the TCP troubles moving to 2.6.10 generated
on my production server, and now, I should apply another large set of mainly
untested patches just to fill the security hole. This just cannot be done in
a fiew days because on many organisations, the new kernel has to pass several
days on secondary servers before reaching the main ones.

Now assuming that I have other production servers still running older kernels,
I have no way to get the simple fix from kernel.org and backport it to 2.6.8
and 2.6.9, unless I'm a kernel fulltime worker that reads all messages on kernel
mailing list.

Basically, you are currently leaving non distribution related users alone in the
cold and this is really really bad for the confidence we have in Linux,
so please publish a 2.6.10.1 with the short term solution to fix the hole.
Of course this does not prevent to publish 2.6.10.2 when you found a better
solution, or use a different fix in 2.6.11 since they are not based on 2.6.10.1

Regards,
Hubert Tonneau


PS: I believe that it would also be a very good idea, since Linux is now
expected to be a mature organisation, to automatically publish 2.6.x.y new holes
only fix patch for each stable kernel that has been released less than a year ago.
This would enable smoother upgrade of highly important production servers.

Andrea Arcangeli

unread,
Jan 12, 2005, 8:58:19 PM1/12/05
to Chris Wright, Linus Torvalds, Marcelo Tosatti, Greg KH, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 12:27:11PM -0800, Chris Wright wrote:
> The two goals: 1) timely response, fix, dislosure; and 2) not leaving
> vendors with pants down; don't have to be mutually exclusive.

All vendors are normally ready way before the end of the embargo.
I would suggest the slowest of all vendors will enforce the date (i.e.
all vendors propose a date, and the longest one will be choosen like a
reverse auction, the worst offer wins), with a maximum delay of 1 month
(or whatever else). To guarantee everyone will go as fast as possible
the date proposed by every different vendor can be published in the
final report. Just keeping in mind that the more archs involved, the
more kernels have to be built and the slower will be a vendor. So a
difference of a few days just to build and test everything is very
reasonable and not significant, but this will avoid differences of
>1week and it'll avoid the unnecessary delays when everybody is ready to
publish but nobody can (which personally is the only thing that would
annoy me if I were a customer). This will also raise the attention and
it'll increase the stress to get things done ASAP since there'll be a
reward. Nothing gets done if there's no reward.

Greg KH

unread,
Jan 12, 2005, 9:05:29 PM1/12/05
to Dave Jones, Linus Torvalds, Marcelo Tosatti, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 03:53:50PM -0500, Dave Jones wrote:
>
> If you turned the current model upsidedown and vendor-sec learned
> about issues from secu...@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 having security@ notify vendor-sec when it finds a real problem
would be a good idea, as a lot of stuff is just sifting through finding
the root cause and fix. And if security@ still has it's "5 day
countdown" type thing, that still gives you (and me) at least a few days
to run around like mad to update things, which is better than nothing :)

thanks,

greg k-h

Linus Torvalds

unread,
Jan 12, 2005, 9:11:36 PM1/12/05
to Dave Jones, Marcelo Tosatti, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org

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 secu...@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 secu...@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

Andrew Morton

unread,
Jan 12, 2005, 9:32:29 PM1/12/05
to Linus Torvalds, da...@redhat.com, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
Linus Torvalds <torv...@osdl.org> wrote:
>
> 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.
> ...

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

That sounds a bit over-the-top to me, sorry.

AFAIUI, the vendor requirement is that they have time to have an upgraded
kernel package on their servers when the bug becomes public knowledge.

If correct and reasonable, then what is the best way in which we can
support them in this while promptly upgrading the kernel.org kernel?


Also:

I think we need to be more explicit in separating _types_ of security
problems. This recent controversy over the RLIM_MEMLOCK DoS is plain
silliness.

Look through the kernel changelogs for the past year - we've fixed a huge
number of "fix oops in foo" and "fix deadlock in bar" and "fix memory leak
in zot". All of these are of exactly the same severity as the rlimit bug,
and nobody cares, nobody is hurt.

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

IMO, local DoS holes are important mainly because buggy userspace
applications allow remote users to get in and exploit them, and for that
reason we of course need to fix them up. Even though such an attacker
could cripple the machine without exploiting such a hole.

For the above reasons I see no need to delay publication of local DoS holes
at all. The only thing for which we need to provide special processing is
privilege escalation bugs.

Or am I missing something?

Linus Torvalds

unread,
Jan 12, 2005, 9:53:47 PM1/12/05
to Andrew Morton, da...@redhat.com, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org

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

Greg KH

unread,
Jan 12, 2005, 9:59:31 PM1/12/05
to Andrew Morton, Linus Torvalds, da...@redhat.com, marcelo...@cyclades.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 06:28:38PM -0800, Andrew Morton wrote:
>
> IMO, local DoS holes are important mainly because buggy userspace
> applications allow remote users to get in and exploit them, and for that
> reason we of course need to fix them up. Even though such an attacker
> could cripple the machine without exploiting such a hole.
>
> For the above reasons I see no need to delay publication of local DoS holes
> at all. The only thing for which we need to provide special processing is
> privilege escalation bugs.
>
> Or am I missing something?

So, a "classification" of the severity of the bug would cause different
type of disclosures? That's a good idea in theory, but trying to nail
down specific for bug classifications tends to be difficult.

Although I think both Red Hat and SuSE have a classification system in
place already that might help out here.

Anyway, if so, I like it. I think that would be a good thing to have,
if for no other reason that I don't want to see security announcements
for every single driver bug that's patched that had caused a user
created oops.

thanks,

greg k-h

Chris Wright

unread,
Jan 12, 2005, 10:02:32 PM1/12/05
to Andrew Morton, Linus Torvalds, da...@redhat.com, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
* Andrew Morton (ak...@osdl.org) wrote:
> AFAIUI, the vendor requirement is that they have time to have an upgraded
> kernel package on their servers when the bug becomes public knowledge.

Yup.

> If correct and reasonable, then what is the best way in which we can
> support them in this while promptly upgrading the kernel.org kernel?

Most projects inform vendors with enough heads-up time to let them get
their stuff together and out the door.

> IMO, local DoS holes are important mainly because buggy userspace
> applications allow remote users to get in and exploit them, and for that
> reason we of course need to fix them up. Even though such an attacker
> could cripple the machine without exploiting such a hole.
>
> For the above reasons I see no need to delay publication of local DoS holes
> at all. The only thing for which we need to provide special processing is
> privilege escalation bugs.
>
> Or am I missing something?

No, that's pretty similar to CVE allocation. At one time, there was
little effort even put into allocating CVE entries for local DoS holes.
It's not that they aren't important, but less critical than remote DoS
issues, and way less so than anything priv escalation related.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

David Blomberg

unread,
Jan 12, 2005, 10:10:30 PM1/12/05
to linux-...@vger.kernel.org
Linus Torvalds said:
>
>
> 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
>
Devils-advocate: Who is on the vendor-sec list? as I have started
devloping a roll your own linux dsitro (as 100s of other have as well) who
decides who is "approved" to hear about the fixes beforehand-what makes
SuSE, and Red Hat more deserving than Bonzai) User Base?
inhouse-developrs?. I agree with Linus-san openness is best all around.
the rest is mostly politics.

--
David Blomberg
dblo...@davelinux.com
AIS, APS, ASE, CCNA, Linux+, LCA, LCP, LPI I, MCP, MCSA, MCSE, RHCE, Server+

Christian

unread,
Jan 12, 2005, 10:21:28 PM1/12/05
to linux-...@vger.kernel.org, Linus Torvalds
Linus Torvalds wrote:
>
> 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.

what the....no!!

changelogs have to be verbose, i'm still often missing hints in the
current changelogs, commenting that patch_a and update_b got in because
of a security issue. some boxes need only be updated for the sake of
security, so one would be happy only watching for <security patch> lines
in the kernel changlogs. giving credits to the people who found the
problem is still possible by mentioning the (source of the)original
advisory.

Christian.
--
BOFH excuse #30:

positron router malfunction

Dave Jones

unread,
Jan 12, 2005, 10:27:01 PM1/12/05
to Linus Torvalds, Marcelo Tosatti, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 06:09:31PM -0800, Linus Torvalds wrote:

> 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 volume of traffic we as a vendor get every time an issue
makes news (and sadly even the insignificant issues seem to be
making news these days) from users wanting to know where our
updates are is a good indication that your thinking is clearly bogus.

> The only thing it does is allow the vendor to point fingers and say "hey, we
> have an update, now it's your problem".

I fail to see the point you're trying to make here.

> 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.

I think the timelyness isn't the issue, the issue is making sure that
the kernel.org kernel actually does end up getting the fixes.
That 2.6.10 got out of -rc with known vulnerabilities which were
known to be fixed in 2.6.9-ac is mind-boggling. That a 2.6.10.1
didn't follow up yet is equally so.

Part of the premise of the 'new' development model was that vendor kernels
were where people go for the 'super-stable kernel', and the kernel.org
kernel may not be quite so polished around the edges. This seems to
go against what you're saying in this thread which reads..
'kernel.org kernels might not be as stable as vendor kernels, but you're
going to need to run it if you want security holes fixed asap'

> Whatever. I happen to believe in openness, and vendor-sec does not. It's
> that simple.

That openness comes at a price. I don't need to bore you with
analogies, as you know as well as I do how wide and far Linux
is deployed these days, but doing this openly is just irresponsible.

Someone malicious on getting the announcement of a new kernel.org release
gets told exactly where the hole is and how to exploit it.
All they'll need to do is find a target running a vendor kernel before
updates get deployed. Whilst this is true to a certain degree
today, as not everyone deploys security updates in a timely manner
(some not at all), things can only get worse.

Dave

Dave Jones

unread,
Jan 12, 2005, 10:37:45 PM1/12/05
to Andrew Morton, Linus Torvalds, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 06:28:38PM -0800, Andrew Morton wrote:

> IMO, local DoS holes are important mainly because buggy userspace
> applications allow remote users to get in and exploit them, and for that
> reason we of course need to fix them up. Even though such an attacker
> could cripple the machine without exploiting such a hole.
>
> For the above reasons I see no need to delay publication of local DoS holes
> at all. The only thing for which we need to provide special processing is
> privilege escalation bugs.
>
> Or am I missing something?

The problem is it depends on who you are, and what you're doing with Linux
how much these things affect you.

A local DoS doesn't both me one squat personally, as I'm the only
user of computers I use each day. An admin of a shell server or
the like however would likely see this in a different light.
(though it can be argued a mallet to the kneecaps of the user
responsible is more effective than any software update)

An information leak from kernel space may be equally as mundane to some,
though terrifying to some admins. Would you want some process to be
leaking your root password, credit card #, etc to some other users process ?

priveledge escalation is clearly the number one threat. Whilst some
class 'remote root hole' higher risk than 'local root hole', far
too often, we've had instances where execution of shellcode by
overflowing some buffer in $crappyapp has led to a shell
turning a local root into a remote root.

For us thankfully, exec-shield has trapped quite a few remotely
exploitable holes, preventing the above.

Dave

Rik van Riel

unread,
Jan 12, 2005, 10:41:58 PM1/12/05
to Marcelo Tosatti, Linus Torvalds, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, 12 Jan 2005, Marcelo Tosatti wrote:

> The only reason for this is to have "time for the vendors to catch up",
> which can be defined by the kernel security office. Nothing more - no
> vendor politics involved.

There are other good reasons, too. One could be:

"Lets not make this security bug public on christmas eve,
because many system administrators won't get around to
applying patches, while the script kiddies have lots of
time over their christmas holidays."

IMHO it will be good to coordinate things like this, based on
common sense, and trying to minimise the impact on users of
the software. I do agree with Linus' "no politics" point,
though ;)

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Andrew Morton

unread,
Jan 12, 2005, 10:48:29 PM1/12/05
to Dave Jones, torv...@osdl.org, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
Dave Jones <da...@redhat.com> wrote:
>
> On Wed, Jan 12, 2005 at 06:28:38PM -0800, Andrew Morton wrote:
>
> > IMO, local DoS holes are important mainly because buggy userspace
> > applications allow remote users to get in and exploit them, and for that
> > reason we of course need to fix them up. Even though such an attacker
> > could cripple the machine without exploiting such a hole.
> >
> > For the above reasons I see no need to delay publication of local DoS holes
> > at all. The only thing for which we need to provide special processing is
> > privilege escalation bugs.
> >
> > Or am I missing something?
>
> The problem is it depends on who you are, and what you're doing with Linux
> how much these things affect you.
>
> A local DoS doesn't both me one squat personally, as I'm the only
> user of computers I use each day. An admin of a shell server or
> the like however would likely see this in a different light.
> (though it can be argued a mallet to the kneecaps of the user
> responsible is more effective than any software update)

yup. But there are so many ways to cripple a Linux box once you have local
access. Another means which happens to be bug-induced doesn't seem
important.

> An information leak from kernel space may be equally as mundane to some,
> though terrifying to some admins. Would you want some process to be
> leaking your root password, credit card #, etc to some other users process ?
>
> priveledge escalation is clearly the number one threat. Whilst some
> class 'remote root hole' higher risk than 'local root hole', far
> too often, we've had instances where execution of shellcode by
> overflowing some buffer in $crappyapp has led to a shell
> turning a local root into a remote root.

I'd place information leaks and privilege escalations into their own class,
way above "yet another local DoS".

A local privilege escalation hole should be viewed as seriously as a remote
privilege escalation hole, given the bugginess of userspace servers, yes?

Marek Habersack

unread,
Jan 12, 2005, 10:57:06 PM1/12/05
to Dave Jones, Linus Torvalds, Marcelo Tosatti, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 10:25:06PM -0500, Dave Jones scribbled:
[snip]

> > Whatever. I happen to believe in openness, and vendor-sec does not. It's
> > that simple.
>
> That openness comes at a price. I don't need to bore you with
> analogies, as you know as well as I do how wide and far Linux
> is deployed these days, but doing this openly is just irresponsible.
>
> Someone malicious on getting the announcement of a new kernel.org release
> gets told exactly where the hole is and how to exploit it.
> All they'll need to do is find a target running a vendor kernel before
> updates get deployed. Whilst this is true to a certain degree
> today, as not everyone deploys security updates in a timely manner
> (some not at all), things can only get worse.
That might be, but note one thing: not everybody runs vendor kernels (for various
reasons). Now see what happens when the super-secret vulnerability (with
vendor fixes) is described in an advisory. A person managing a park of machines
(let's say 100) with custom, non-vendor, kernels suddenly finds out that they
have a buggy kernel and 100 machines to upgrade while the exploit and the
description of the vuln are out in the wild. They have to port their
custom stuff to the new kernel, compile it, test it (at least a bit), deploy
on 100 machines and pray it doesn't break. During all that time (and the
whole process won't take a day or even two) the evil guys are far ahead of
the poor bastard managing the 100 machines (since all they need is one
exploit which will work on any of our admin's machines). One other factor
that makes it hard for such a person to apply the patches is simply that there
is no single place to find the security patches in. He goes to securityfocus.com,
for instance, and what does he find? A nice description of the vulnerability, a
discussion, a list of affected kernel versions and credits which usually
list vendor advisories and kernel versions and very rarely a link to an
archived mail message or a webpage with the patch. Hoping he'll find the
fixes in the vendor kernels, he goes to download source packages from SuSe,
RedHat or Trustix, Debian, Ubuntu, whatever and discovers that it is as easy
to find the patch there as it is to fish it out of the vanilla kernel patch
for the new version. Frustrating, isn't it? Not to mention that he might
need to backport the fix, if he runs an earlier version of the kernel.
And now assume that everything is as extremely open as Linus says - the
admin has the same access to the exact information the vendors on vendor-sec
have, together with the same fix they have (in form of a simple patch
available without fishing for it all over the place). He starts the race
with the bad guys exactly at the same time they start running looking for
the vulnerable machines on the 'Net. Priceless, IMHO.
I guess that, contrary to what you've just said above, hiding the
information is irresponsible.
Having said that, I don't think everything should be as extremely open as
Linus would want it to see, but rather the way he proposed (and which many
folks agreed to) with the 5-day (or so) embargo for the advisory release and
with the patch(es)/discussion openly available to anyone interested (based
on the premise that most people learn about vulnerabilities not from
security lists but from security bulletins, tech news sites, user forums etc.)

best regards,

marek

signature.asc

Chris Wright

unread,
Jan 12, 2005, 10:58:44 PM1/12/05
to Andrew Morton, Dave Jones, torv...@osdl.org, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
* Andrew Morton (ak...@osdl.org) wrote:
> yup. But there are so many ways to cripple a Linux box once you have local
> access. Another means which happens to be bug-induced doesn't seem
> important.

That depends on the environment. If it's already locked down via MAC
and rlimits, etc. and the bug now creates a DoS that wasn't there before
it may be important. But, as a general rule of thumb, local DoS
is much less severe than other bugs, I fully agree.

> > An information leak from kernel space may be equally as mundane to some,
> > though terrifying to some admins. Would you want some process to be
> > leaking your root password, credit card #, etc to some other users process ?
> >
> > priveledge escalation is clearly the number one threat. Whilst some
> > class 'remote root hole' higher risk than 'local root hole', far
> > too often, we've had instances where execution of shellcode by
> > overflowing some buffer in $crappyapp has led to a shell
> > turning a local root into a remote root.
>
> I'd place information leaks and privilege escalations into their own class,
> way above "yet another local DoS".

Yes, me too.

> A local privilege escalation hole should be viewed as seriously as a remote
> privilege escalation hole, given the bugginess of userspace servers, yes?

Absolutely, yes. Local root hole all too often == remote root hole.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

Linus Torvalds

unread,
Jan 12, 2005, 11:51:40 PM1/12/05
to Dave Jones, Andrew Morton, marcelo...@cyclades.com, Greg KH, chr...@osdl.org, Alan Cox, Kernel Mailing List

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

William Lee Irwin III

unread,
Jan 13, 2005, 12:06:49 AM1/13/05
to Andrew Morton, Dave Jones, torv...@osdl.org, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
Dave Jones <da...@redhat.com> wrote:
>> The problem is it depends on who you are, and what you're doing with Linux
>> how much these things affect you.
>> A local DoS doesn't both me one squat personally, as I'm the only
>> user of computers I use each day. An admin of a shell server or
>> the like however would likely see this in a different light.
>> (though it can be argued a mallet to the kneecaps of the user
>> responsible is more effective than any software update)

On Wed, Jan 12, 2005 at 07:42:39PM -0800, Andrew Morton wrote:
> yup. But there are so many ways to cripple a Linux box once you have local
> access. Another means which happens to be bug-induced doesn't seem
> important.

This is too broad and sweeping of a statement, and can be used to
excuse almost any bug triggerable only by local execution.

Most of the local DoS's I'm aware of are memory management -related,
i.e. user- triggerable proliferation of pinned kernel data structures.
Beancounter patches were meant to address at least part of that. Paging
the larger kernel data structures users can trigger proliferation of
would also be a large help.


Dave Jones <da...@redhat.com> wrote:
>> An information leak from kernel space may be equally as mundane to some,
>> though terrifying to some admins. Would you want some process to be
>> leaking your root password, credit card #, etc to some other users process ?
>> priveledge escalation is clearly the number one threat. Whilst some
>> class 'remote root hole' higher risk than 'local root hole', far
>> too often, we've had instances where execution of shellcode by
>> overflowing some buffer in $crappyapp has led to a shell
>> turning a local root into a remote root.

On Wed, Jan 12, 2005 at 07:42:39PM -0800, Andrew Morton wrote:
> I'd place information leaks and privilege escalations into their own class,
> way above "yet another local DoS".
> A local privilege escalation hole should be viewed as seriously as a remote
> privilege escalation hole, given the bugginess of userspace servers, yes?

I agree on the latter count. On the first, I have to dissent with the
assessment of local DoS's as "unimportant".


-- wli

William Lee Irwin III

unread,
Jan 13, 2005, 12:11:47 AM1/13/05
to Dave Jones, Andrew Morton, Linus Torvalds, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 06:28:38PM -0800, Andrew Morton wrote:
>> IMO, local DoS holes are important mainly because buggy userspace
>> applications allow remote users to get in and exploit them, and for that
>> reason we of course need to fix them up. Even though such an attacker
>> could cripple the machine without exploiting such a hole.
>> For the above reasons I see no need to delay publication of local DoS holes
>> at all. The only thing for which we need to provide special processing is
>> privilege escalation bugs.
>> Or am I missing something?

On Wed, Jan 12, 2005 at 10:35:42PM -0500, Dave Jones wrote:
> The problem is it depends on who you are, and what you're doing with Linux
> how much these things affect you.
> A local DoS doesn't both me one squat personally, as I'm the only
> user of computers I use each day. An admin of a shell server or
> the like however would likely see this in a different light.
> (though it can be argued a mallet to the kneecaps of the user
> responsible is more effective than any software update)

It deeply disturbs me to hear this kind of talk. If we're pretending to
be a single-user operating system, why on earth did we use UNIX as a
precedent in the first place?


On Wed, Jan 12, 2005 at 10:35:42PM -0500, Dave Jones wrote:
> An information leak from kernel space may be equally as mundane to some,
> though terrifying to some admins. Would you want some process to be
> leaking your root password, credit card #, etc to some other users process ?
> priveledge escalation is clearly the number one threat. Whilst some
> class 'remote root hole' higher risk than 'local root hole', far
> too often, we've had instances where execution of shellcode by
> overflowing some buffer in $crappyapp has led to a shell
> turning a local root into a remote root.
> For us thankfully, exec-shield has trapped quite a few remotely
> exploitable holes, preventing the above.

If we give up and say we're never going to make multiuser use secure,
where is our distinction from other inherently insecure single-user OS's?


-- wli

Dave Jones

unread,
Jan 13, 2005, 12:22:37 AM1/13/05
to William Lee Irwin III, Andrew Morton, Linus Torvalds, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 08:49:19PM -0800, William Lee Irwin III wrote:

> On Wed, Jan 12, 2005 at 10:35:42PM -0500, Dave Jones wrote:
> > The problem is it depends on who you are, and what you're doing with Linux
> > how much these things affect you.
> > A local DoS doesn't both me one squat personally, as I'm the only
> > user of computers I use each day. An admin of a shell server or
> > the like however would likely see this in a different light.
> > (though it can be argued a mallet to the kneecaps of the user
> > responsible is more effective than any software update)
>
> It deeply disturbs me to hear this kind of talk. If we're pretending to
> be a single-user operating system, why on earth did we use UNIX as a
> precedent in the first place?

You completely missed my point. What's classed as a threat to one
user just isn't relevant to another.

> On Wed, Jan 12, 2005 at 10:35:42PM -0500, Dave Jones wrote:
> > An information leak from kernel space may be equally as mundane to some,
> > though terrifying to some admins. Would you want some process to be
> > leaking your root password, credit card #, etc to some other users process ?
> > priveledge escalation is clearly the number one threat. Whilst some
> > class 'remote root hole' higher risk than 'local root hole', far
> > too often, we've had instances where execution of shellcode by
> > overflowing some buffer in $crappyapp has led to a shell
> > turning a local root into a remote root.
> > For us thankfully, exec-shield has trapped quite a few remotely
> > exploitable holes, preventing the above.
>
> If we give up and say we're never going to make multiuser use secure,
> where is our distinction from other inherently insecure single-user OS's?

Nowhere did I make that claim. If you parsed the comment about
exec-shield incorrectly, I should point out that we also issued
security updates to various applications even though (due to exec-shield)
our users weren't vulnerable. The comment was an indication that
the extra barrier has bought us some time in preparing updates
when 0-day exploits have been sprung on us unexpectedly on more
than one occasion.

Dave

Barry K. Nathan

unread,
Jan 13, 2005, 12:39:15 AM1/13/05
to Marek Habersack, Dave Jones, Linus Torvalds, Marcelo Tosatti, Greg KH, Chris Wright, ak...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Thu, Jan 13, 2005 at 04:53:31AM +0100, Marek Habersack wrote:
> archived mail message or a webpage with the patch. Hoping he'll find the
> fixes in the vendor kernels, he goes to download source packages from SuSe,
> RedHat or Trustix, Debian, Ubuntu, whatever and discovers that it is as easy
> to find the patch there as it is to fish it out of the vanilla kernel patch
> for the new version. Frustrating, isn't it? Not to mention that he might

http://linux.bkbits.net is your friend.

Each patch (including security fixes) in the mainline kernels (2.4 and
2.6) appears there as an individual, clickable link with a description
(e.g. "1.1551 Paul Starzetz: sys_uselib() race vulnerability
(CAN-2004-1235)").

If other patches have gone in since then, you may have to scroll through
a (short-form) changelog. However, it's still less frustrating than the
scenario you portray.

-Barry K. Nathan <bar...@pobox.com>

Barry K. Nathan

unread,
Jan 13, 2005, 12:52:49 AM1/13/05
to Linus Torvalds, Dave Jones, Andrew Morton, marcelo...@cyclades.com, Greg KH, chr...@osdl.org, Alan Cox, Kernel Mailing List
On Wed, Jan 12, 2005 at 08:48:57PM -0800, Linus Torvalds wrote:
> 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

That reminds me...

What are the chances of exec-shield making it into mainline anytime
in the near future? It's the *big* feature that has me preferring
Red Hat/Fedora vendor kernels over mainline kernels, even on non-Red
Hat/Fedora distributions. (I know that parts of exec-shield are already in
mainline, but I'm wondering about the parts that haven't been merged yet.)

-Barry K. Nathan <bar...@pobox.com>

Andrew Morton

unread,
Jan 13, 2005, 1:56:56 AM1/13/05
to William Lee Irwin III, da...@redhat.com, torv...@osdl.org, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
William Lee Irwin III <w...@holomorphy.com> wrote:
>
> Most of the local DoS's I'm aware of are memory management -related,
> i.e. user- triggerable proliferation of pinned kernel data structures.

Well. A heck of a lot of the DoS opportunities we've historically seen
involved memory leaks, deadlocks or making the kernel go oops or BUG with
locks held or with kernel memory allocated.

William Lee Irwin III

unread,
Jan 13, 2005, 2:24:15 AM1/13/05
to Andrew Morton, da...@redhat.com, torv...@osdl.org, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
William Lee Irwin III <w...@holomorphy.com> wrote:
>> Most of the local DoS's I'm aware of are memory management -related,
>> i.e. user- triggerable proliferation of pinned kernel data structures.

On Wed, Jan 12, 2005 at 10:54:12PM -0800, Andrew Morton wrote:
> Well. A heck of a lot of the DoS opportunities we've historically seen
> involved memory leaks, deadlocks or making the kernel go oops or BUG with
> locks held or with kernel memory allocated.

I'd consider those even more severe.


-- wli

Matt Mackall

unread,
Jan 13, 2005, 2:27:29 AM1/13/05
to Andrew Morton, William Lee Irwin III, da...@redhat.com, torv...@osdl.org, marcelo...@cyclades.com, gr...@kroah.com, chr...@osdl.org, al...@lxorguk.ukuu.org.uk, linux-...@vger.kernel.org
On Wed, Jan 12, 2005 at 10:54:12PM -0800, Andrew Morton wrote:
> William Lee Irwin III <w...@holomorphy.com> wrote:
> >
> > Most of the local DoS's I'm aware of are memory management -related,
> > i.e. user- triggerable proliferation of pinned kernel data structures.
>
> Well. A heck of a lot of the DoS opportunities we've historically seen
> involved memory leaks, deadlocks or making the kernel go oops or BUG with
> locks held or with kernel memory allocated.

I think we can probably exclude root-only local DoS from the full
embargo treatment for starters. The recent /dev/random sysctl one was
in that category.

I can imagine some local DoS bugs that are worth keeping a lid on for
a bit. Classic F00F bug may have been a good example. But hole in an
arbitrary driver may not.

--
Mathematics is the supreme nostalgia of our time.

Matt Mackall

unread,
Jan 13, 2005, 2:32:22 AM1/13/05
to Linus Torvalds, Dave Jones, Andrew Morton, marcelo...@cyclades.com, Greg KH, chr...@osdl.org, Alan Cox, Kernel Mailing List
On Wed, Jan 12, 2005 at 08:48:57PM -0800, Linus Torvalds wrote:
>
>
> 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).

We can do that now with a combination of read-only and no-exec mounts.

--
Mathematics is the supreme nostalgia of our time.

Willy Tarreau

unread,
Jan 13, 2005, 2:57:47 AM1/13/05
to Matt Mackall, Linus Torvalds, Dave Jones, Andrew Morton, marcelo...@cyclades.com, Greg KH, chr...@osdl.org, Alan Cox, Kernel Mailing List
On Wed, Jan 12, 2005 at 11:28:51PM -0800, Matt Mackall wrote:
> On Wed, Jan 12, 2005 at 08:48:57PM -0800, Linus Torvalds wrote:
> >
> >
> > 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).
>
> We can do that now with a combination of read-only and no-exec mounts.

That's why some hardened distros ship with everything R/O (except var) and
/var non-exec.

Willy

David Lang

unread,
Jan 13, 2005, 3:13:51 AM1/13/05
to Willy Tarreau, Matt Mackall, Linus Torvalds, Dave Jones, Andrew Morton, marcelo...@cyclades.com, Greg KH, chr...@osdl.org, Alan Cox, Kernel Mailing List
On Thu, 13 Jan 2005, Willy Tarreau wrote:

> On Wed, Jan 12, 2005 at 11:28:51PM -0800, Matt Mackall wrote:
>> On Wed, Jan 12, 2005 at 08:48:57PM -0800, Linus Torvalds wrote:
>>>
>>>
>>> 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).
>>
>> We can do that now with a combination of read-only and no-exec mounts.
>
> That's why some hardened distros ship with everything R/O (except var) and
> /var non-exec.

this only works if you have no reason to mix the non-exec and R/O stuff in
the same directory (there is some software that has paths for stuff hard
coded that will not work without them being togeather)

also it gives you no ability to maintain the protection for normal users
at the same time that an admin updates the system. Linus's proposal would
let you five this cap to the normal users, but still let the admin manage
the box normally.

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare

Christoph Hellwig

unread,
Jan 13, 2005, 3:25:47 AM1/13/05
to Linus Torvalds, Dave Jones, Andrew Morton, marcelo...@cyclades.com, Greg KH, chr...@osdl.org, Alan Cox, Kernel Mailing List
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" ;-)

Florian Weimer

unread,
Jan 13, 2005, 3:25:43 AM1/13/05