User: Password:
|
|
Subscribe / Log in / New account

Kernel security, year to date

Kernel security, year to date

Posted Sep 10, 2008 0:11 UTC (Wed) by spender (subscriber, #23067)
In reply to: Kernel security, year to date by njs
Parent article: Kernel security, year to date

Even for trends they're problematic: at most it gives you trends in what
gets publicly reported as security bugs; this is a level removed from the
kinds of things you would actually want to know.

My personal preference was for the odd/even development model. The current
model is unsustainable from a security perspective -- but there's no
interest in changing from that model, so suggesting a change of models
isn't useful. In other words, I realize the model won't change, so I'm
merely pointing out the problem with it and suggesting that at least
*something* be done about the security aspect. The current official view
is simply to "fix bugs" and not treat security bugs as special in any way.
With that kind of view, things will only decline.

We had previously extensively discussed changes that could be made to the
process so that at least security related bugs would be reported with more
accuracy and consistency, but instead it was decided to go backwards
instead of forwards. So my post wasn't really a request for change but
more of a "why are you surprised that it's so horrible?", since several
people have been pointing it out for years, and it continues to get worse.

At this point, I don't know what to tell you other than you should have
spoke up last month before they began their anti-security campaign. If you
want to find out what things you were vulnerable to, you'll have to
discover that information on your own by investigating each patch. If you
want to improve the security of the kernel in some way, you'll have to do
that yourself as well -- nobody seems to take it seriously.

Since you asked though about what can be done to improve kernel security,
one route is to remove the exploitability of certain bugclasses. The PaX
team recently has added a feature which prevents exploitation of refcount-
based bugs (like the ptrace ones listed in the CVEs in this article). So
there are always things that can be done with negligible impact, but don't
hold your breath waiting for it to come from the kernel developers
themselves.

-Brad


(Log in to post comments)

Kernel security, year to date

Posted Sep 11, 2008 9:58 UTC (Thu) by intgr (subscriber, #39733) [Link]

The rest of your post I can mostly agree with, but this statement of yours is completely backwards:

The PaX team recently has added a feature which prevents exploitation of refcount-based bugs (like the ptrace ones listed in the CVEs in this article). So there are always things that can be done with negligible impact, but don't hold your breath waiting for it to come from the kernel developers themselves.

If there are security enhancements that have (supposedly) negligible overhead, then why are not they being pushed towards the mainline where they can benefit everyone? Expecting kernel developers to go to the PaX team begging for their patch is not the way mainline development works. You go as far as to imply that the mainline kernel developers should duplicate this effort -- why?

Supposedly, getting patches into the kernel is easy with the current development model. Yes, they have different ideas about how security should be managed, but they are reasonable people. Why is the PaX team not interested in working with the mainline kernel?

Kernel security, year to date

Posted Sep 11, 2008 13:47 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> If there are security enhancements that have (supposedly) negligible
> overhead, then why are not they being pushed towards the mainline where
> they can benefit everyone?

why does something have to be in mainline to benefit everyone?

> Expecting kernel developers to go to the PaX team begging for their
> patch is not the way mainline development works.

any source for this (rather silly, i might add) allegiation? last time i checked, the PaX patches were out there freely available to everyone.

> Supposedly, getting patches into the kernel is easy with the current
> development model. Yes, they have different ideas about how security
> should be managed, but they are reasonable people.

my experience says otherwise:

http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-07/m...
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-07/m...
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-07/m...

(unfortunately vger's spam filter ate my mails, so you'll have to piece the story together from the quoted parts). the funny thing is that since last year, when CFS (by Ingo, no less) went into the kernel, it too became victim of the user_mode() mess in that now if you run an endless loop in v86 mode, its runtime will be accounted as system time, not user time. to quote Linus: 'Sad.'

> Why is the PaX team not interested in working with the mainline kernel?

it's the other way around: i've been told explicitly and got it even codified in DCO that anonymous submissions are not to be. i prefer my status over silly policies.

Kernel security, year to date

Posted Sep 11, 2008 16:02 UTC (Thu) by pdundas (guest, #15203) [Link]

> why does something have to be in mainline to benefit everyone?

It doesn't have to be in mainline to benefit everyone.
But putting fixes in mainline DOES benefit everyone.
Putting them anywhere else only benefits a subset of users.

> > Expecting kernel developers to go to the PaX team
> > begging for their patch is not the way mainline
> > development works.

> any source for this (rather silly, i might add)
> allegiation? last time i checked, the PaX patches
> were out there freely available to everyone.

I think you're missing the point he was making.

If you want patches to go into mainline (and we just saw
that is A Good Thing (TM)), then Someone (TM) has to
submit that patch.

Possibly developing and testing their own code and
reviewing submissions keeps mainline kernel devs
quite busy. They may not have all that much time for
scouring the net for potentially useful patches.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds