| |||||||||||||
fixed in v2.6.31.1fixed in v2.6.31.1Posted Sep 27, 2009 14:06 UTC (Sun) by hppnq (guest, #14462)In reply to: fixed in v2.6.31.1 by spender Parent article: Kernel release status I was just pulling your leg, my system -- pristine, default Ubuntu -- is not running 2.6.31 in the first place. ;-) You may think this is silly, but I think that this observation makes a lot of sense when it comes to "real" security. The first question, when doing a vulnerability assessment, is not "Is it remotely exploitable?", it is "Are we running that stuff?". So in this case, anyone who is running 2.6.31 with perf counters on a system that handles untrusted user data is likely to be vulnerable. Not too many people, I should think, fall in that category without knowing it. That said, these bugs need to be fixed. But your sense of urgency and your tone are easily ignored -- sometimes much too easily -- and therefore, the question whether you plan to ever cooperate better with the kernel developers remains valid and to the point. If you would strip all communication of its unneeded emotion, and for instance, simply set up a repository that contains the fixes you find during your research, this could prove to be very fruitful to all parties.
(Log in to post comments)
fixed in v2.6.31.1 Posted Sep 27, 2009 14:19 UTC (Sun) by spender (subscriber, #23067) [Link]
As I mentioned elsewhere, anyone using a distro config will have perf counters automatically enabled without knowing it (since it gets turned on if PROFILING=y, which the vendors all enable).
As for the repository:
our code has always been open for anyone to pull fixes from.
PS: what system doesn't handle untrusted user data?
-Brad
fixed in v2.6.31.1 Posted Sep 27, 2009 20:32 UTC (Sun) by hppnq (guest, #14462) [Link] As I mentioned elsewhere, anyone using a distro config will have perf counters automatically enabled without knowing it (since it gets turned on if PROFILING=y, which the vendors all enable). You mean, in the case where users download 2.6.31 and blindly reuse a non-matching distribution-supplied config? That is not a safe practice. Otherwise, I have to assume that either the distribution or the user knows what is turned on, with what impact.
Incorporating fixes in your own patches is not the same as fixing bugs in the vanilla kernel. (The link doesn't work, so I am assuming it points to a full-blown grsecurity patch, which is not part of the vanilla kernel.) That said, you seem to write excellent code, and I wish more of your efforts would end up in the kernel in a way that satisfies you, the kernel developers, and Linux users alike. A git repository seems like a good idea. It's not so much the code contribution that's important (crucial fixes will always be picked up), but the cooperation it would help shape.
Well, in the office we of course work with data classifications (and there is no "completely trusted" one), but here I would say a home or test system that is not connected to a public network fits the bill. When referring to systems that do handle untrusted data, I was thinking of Internet facing systems that, for instance, allow FTP or shell access, and I couldn't think of a reason why an admin would turn on profiling on them, or why the admin would not have a security policy based on the assumption that these systems will be hacked to pieces sooner or later.
|
|||||||||||||