"Candid" doesn't mean hidden [LWN.net]

"Candid" doesn't mean hidden

Posted Jun 11, 2008 9:48 UTC (Wed) by tialaramex (subscriber, #21167)
In reply to: "Stable" kernel 2.6.25.6 by PaXTeam
Parent article: Stable kernel 2.6.25.6

What you're talking about is commits which lack security impact information.

I explained that commit messages aren't specifically called out as a medium for security
impact information. So it doesn't matter if they don't have security impact information, any
more than it matters if they don't rhyme.

And you've responded to inform me that I "still don't understand" by which, so far as I've
been able to discover you mean simply that I didn't agree with you about how terrible this is.

Candid means frank and open. You may be confused by seeing it used in the context "candid
camera" or "candid photographs" which refer to the fact that the subject isn't aware that
they're being watched and so they act candidly. The developers involved decided /not/ to be
candid about the bug in your example. You're cross about that, we get it. But you still
haven't given me a reason to care.

I've encountered this claim that only a handful of bugs have security impact before. It's
disappointing, particularly when it comes from someone who claims to actually care about
security. I just picked at random a harmless sounding item from the latest stable tree commit
logs

"eCryptfs: remove unnecessary page decrypt call"

... sounds like it's probably a performance fix? Let's take a look. Oh, the bug overwrites
mmap() changes, undoing them. The kernel promises not to do that to you, breaking the promise
converts to a security impact because userspace programs that rely on this promise are now
broken and their security assumptions are violated.

(Log in to post comments)

"Candid" doesn't mean hidden

Posted Jun 11, 2008 13:04 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]

> "Candid" doesn't mean hidden

i never said it did. what Paul was asking the kernel devs was about how honest he should be in
the commit. the mind boggles at that very moment as this was on a list whose declared
disclosure policy is full-disclosure (see Documentation/SecurityBugs if in doubt). then what
do we get in the commit? complete omission of the more serious security impact (arbitrary
kernel memory read). you call that whatever you want, i call it dishonesty. it's not terrible
per se, it's just it's in direct contradiction to what was communicated to the public before
and what this supposedly superiour development model is so proud of among others. as they say,
you can't have it both ways.

also, this one at least got a CVE that, as far as i know, you can't say about that ptrace bug
i posted somewhere above (not even the corresponding -stable commit mentions anything at least
yet the -stable guys were fully aware of its impact - this by the way directly contradicts
Chris Wright's claim in http://marc.info/?l=linux-kernel&m=121312896523183&... ).

> I explained that commit messages aren't specifically called out as a medium for security
impact information.

says who? 'tialaramex' or is it the agreed-upon (read: documented for the public) commit
policy of kernel developers?

as for what percentage of kernel bugs have a security impact (or did you mean something other
than 'kernel code' by 'privileged code'?), i stand by my claim that it's not *most* of them (i
never said 'only a handful' either, nice strawman though). this is based on my personal
experience.

PS: congratulations on finding yet another silently fixed potential security bug.

"Candid" doesn't mean hidden

Posted Jun 11, 2008 17:33 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

If you use words in the opposite sense to their correct meaning without any trace of irony
then people certainly are entitled to assume that's because you don't actually know what they
mean. I see that a dose of your own medicine doesn't suit you.

You've several times provided links which actually don't say what you claim they do. This time
you suggested that the Linux security list has a policy of full disclosure, when in fact the
document you mentioned uses weasel words to declare that disclosure should happen "as soon as
possible" which means nothing at all.

No congratulations are necessary. I did not find a bug, I just read a randomly chosen commit
log. Anyone can do it. Maybe more people should.

"Candid" doesn't mean hidden

Posted Jun 11, 2008 21:11 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]

i see you're getting sidetracked into various things which is a good sign that i raised valid
points you don't contest.

> You've several times provided links which actually don't say what you
> claim they do.

this is a blanket statement without any proof/explanation. elaborate please.

> This time you suggested that the Linux security list has
> a policy of full disclosure, when in fact the document you mentioned
> uses weasel words to declare that disclosure should happen "as soon as
> possible" which means nothing at all.

said document talks about 'full disclosure', not mere 'disclosure' (nice attempt but you got
caught). second, if you cared to read the comment at the bottom of this thread, you'd realize
that said document doesn't at all raise the issue of the amount of disclosure, only its
potential timing. so we're in agreement that the disclosure policy is 'full disclosure' (and
which is what wasn't observed in several cases i cited). i've said nothing else and you
haven't contradicted it either. and frankly, if you're not an active party in all this
non-or-half-assed-disclosure process, you have zero idea about what you're talking.