I have been using linux as my desktop full time for the last 11 years. I am aware of the fact
that RedHat chooses to enable SELinux by default, but I am also aware of the fact that many
(if not most) sysadmins (as opposed to casual users) end up disabling SELinux as a fairly
routine thing as they start to configure the boxes to be something other then the defaults
that RedHat ships. and from various discussions on the kernel mailing list it's clear that the
most of the kernel developers do as well (those that have RedHat based systems).
the useage argument is that since the kernel developers don't use it, they don't have the
mindset to take it into account when evaluating the severity of bugs, and therefor something
that requires root access to do is not considered that bad as root can already get around the
limitations (even on a RedHat system root is the account that can disable SELinux, so
pretending that SELinux can protect you from rootis wishful thinking)
distribution-maintained kernels will backport or not backport patches on teir own criteria,
not matter what the kernel devs decide to put in a -stable kernel (and note that this patch
did make it into stable, it's not that they didn't fix the problem, it's that you are
complaining that the commit message didn't identify it as a security problem)
Posted Jun 17, 2008 7:28 UTC (Tue) by nix (subscriber, #2304)
[Link]
Oh, in our previous go-round he was quite clear that the problem wasn't
the commit message... after spending half a dozen messages whining about
nothing else.
I'm still unclear what the problem actually *is*. There's meant to be some
sort of huge conspiracy, perhaps focused around not doing whatever Brad
says the instant he says it (it would help if he didn't say it in such a
profoundly unpleasant fashion.)
(And I thought I was bad at diplomacy. At least I have interaction modes
besides `J'accuse' and don't try that one first. If you want to get people
to do something, telling them they're all in a conspiracy and
intentionally attacking the general public(?) is not the way to go.)
"Stable" kernel 2.6.25.7 released
Posted Jun 17, 2008 9:32 UTC (Tue) by PaXTeam (subscriber, #24616)
[Link]
> Oh, in our previous go-round he was quite clear that the problem wasn't
> the commit message... after spending half a dozen messages whining about
> nothing else.
would you stop distorting the facts? first, it was me who posted quite a few messages, not
Brad, second, the problem *is* with the commit messages in that they intentionally omit
important and known-to-the-developers security information. you were given several examples,
not one of which you contested. it's funny how you keep running around with a huge post sign
shouting conspiracy whereas noone of us said anything like that. what we did talk about was
good old human dishonesty hidden in an unaccountable mailing list. as you quite rightly said
in your last post on that other thread, you should not be talking to us as we can't change the
situation. you should be asking questions to your kernel developers and make them accountable.
unfortunately it seems it's easier to pull strawmen than actually trying to get to the bottom
of this problem.
"Stable" kernel 2.6.25.7 released
Posted Jun 17, 2008 13:47 UTC (Tue) by nix (subscriber, #2304)
[Link]
Ah, right, you were talking in such similar ways that I confused you :/ However, you're
assuming that a large number of people are each acting dishonestly for no obvious gain in
different places, with the strong implication of coordination (in that they have all chosen to
be 'dishonest' in exactly the same way: by not mentioning things you consider a security hole
in their commit logs). That's called a conspiracy theory. If you remove the assumption of
dishonesty, it's simply human error, or perhaps that they have lower thresholds for defining
something a security hole than you do. (It would be a miracle if this were not true, given
that most of these people are not security paranoids by nature, and thus are almost bound to
have lower thresholds for such things than you are!)
I'm not contesting the facts: I'm contesting your unnecessarily unpleasant interpretation of
them.
In fact your interpretation makes no sense at all: why would people spend time coordinating to
hide security holes when knowingly doing that could have no consequence other than to harm the
reputation of the system they're working on? Doing that would be ridiculous. Ergo, they aren't
doing that: there is no magically coordinated decision to fix security holes while hiding them
by the single means of describing them differently in commit logs, no conspiracy, no bad
intent. Simply differently-set thresholds.
"Stable" kernel 2.6.25.7 released
Posted Jun 17, 2008 14:47 UTC (Tue) by PaXTeam (subscriber, #24616)
[Link]
i'm not assuming or interpreting anything, i speak of facts i have. for one, it's not a large
number of people, it's the membership of secret lists which by its nature is quite limited.
second, it doesn't take a lot of coordination when you're within your normal social circle
anyway (the same kernel devs who interact on lkml, at conferences, real life, etc), it's
normal human behaviour to stick to the flock lest you get ejected. so no, this is not a
conspiracy (you've been caught again ;).
speaking of facts, what do you have to say about the Paul Mackerras quote and its visible
result in the commit message? what is your interpretation? why was he even raising the point
of how candid he should be in the commit?
> In fact your interpretation makes no sense at all: why would people
> spend time coordinating to hide security holes when knowingly doing that
> could have no consequence other than to harm the reputation of the
> system they're working on? Doing that would be ridiculous.
why would there be consequences when all of this can take place outside of the public eye, in
a completely unaccountable manner?
> Ergo, they aren't doing that:
and you determined that by...? oh right, you didn't. why don't you go ask for the mailing list
archives? that would surely answer all questions, do you agree? and if there's nothing bad to
hide in there, there shouldn't be any objections to getting them.
"Stable" kernel 2.6.25.7 released
Posted Jun 17, 2008 15:40 UTC (Tue) by nix (subscriber, #2304)
[Link]
Er, if the holes get exploited, of *course* there's a consequence. And if there's no
possibility that the holes would be exploited, then modifying the commit messages to conceal
the security-related nature of the commits makes no sense.
You're blatantly contradicting yourself now. I've had enough of this thread.
"Stable" kernel 2.6.25.7 released
Posted Jun 17, 2008 16:09 UTC (Tue) by PaXTeam (subscriber, #24616)
[Link]
> Er, if the holes get exploited, of *course* there's a consequence.
> And if there's no possibility that the holes would be exploited, then
> modifying the commit messages to conceal the security-related nature of
> the commits makes no sense.
i have absolutely no idea what you are talking about now. probably another of your strawmen,
but just in case: you were trying to speculate why it makes no sense to downplay/hide security
information in commit messages (mind you, a few posts below you argued the *opposite*, so much
for contradiction ;) since that would only endanger the reputation of their work. except you
forgot the little fact that such coverup took place in a secret list, hence there was no
danger of exposure, on the other hand there was a perceived advantage of not getting bad PR
about the many silently fixed security bugs. and now, out of the blue, you come with this
commit message modification and how it makes no sense for bugs that don't have a security
impact. guess what, if a bug cannot possibly be exploited then it doesn't have a
security-related nature. that's a tautology and i'm not sure what you tried to say with that.
incidentally, we weren't talking about bugs without security impact either. another strawman
down ;).
> You're blatantly contradicting yourself now.
hmm, where? you're making no sense to me now, sorry. but feel free to elaborate. of course if
you just wanted a cheap cop-out, let this rest.
"Stable" kernel 2.6.25.7 released
Posted Jun 17, 2008 18:07 UTC (Tue) by nix (subscriber, #2304)
[Link]
As I said, I'm dropping this because we're talking past each other. ('Cheap cop-out'.
Charming.)