"Protected" -- for how long? [LWN.net]

"Protected" -- for how long?

Posted Apr 17, 2009 1:19 UTC (Fri) by spender (guest, #23067)
In reply to: "Protected" -- for how long? by tialaramex
Parent article: The details on loading rootkits via /dev/mem

You don't need to be disingenuous; you were around when the discussion regarding the kernel developers' official policy of silently fixing vulnerabilities was discussed. You are well aware of their policy and Linus' reasons for it.

Yes. Because the only place I consider appropriate is the kernel
changelogs, and since those get published with the sources, there is no
way I can convince myself that it's a good idea to say "Hey script
kiddies, try this" unless it's already very public indeed.
http://thread.gmane.org/gmane.linux.kernel/701694/focus=7...

If you haven't been at a univerisity, you don't know how many smart young
people want to "try it to see".
http://thread.gmane.org/gmane.linux.kernel/701694/focus=7...

Torvalds also says he doesn't care for labeling updates and changes to Linux as a security fix in a security advisory.
http://www.cio.com/article/444075/Torvalds_Calls_OpenBSD_...

"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)," Torvalds wrote.
http://www.internetnews.com/dev-news/article.php/3458961

But congratulations on completely ignoring the content of my post with your worthless reply.

-Brad

to post comments

"Protected" -- for how long?

Posted Apr 17, 2009 9:44 UTC (Fri) by hppnq (guest, #14462) [Link] (5 responses)

The STRICT_DEVMEM design and implementation is not without discussion among kernel developers. Unlike with other systems, the Linux kernel development process allows turds as well as gems to be entered into mainline without them being polished completely. That's the way it works. You see this a lot where people are cooperating.

Of course this has benefits as well as downsides, but you seem to be hinting that this must mean that Linux systems are unsafe, or less safe than they need be. This would very obviously not be true, for the simple reason that unauthorized access to /dev/mem is not completely dependent on a sane implementation of STRICT_DEVMEM. Or it should not be.

In your quoting you seem to miss one important part of Linus' point of view: that it may be a good idea to simply fix all bugs instead of singling out a certain class of them as being more important by nature.

Borrowing your logic: if there is a flaw in the implementation of STRICT_DEVMEM, there is also a flaw in the published attack. I think that demonstrates nicely how the process works.

"Protected" -- for how long?

Posted Apr 22, 2009 23:25 UTC (Wed) by dersteppenwolf (guest, #58226) [Link] (4 responses)

"Unlike with other systems, the Linux kernel development process allows turds as well as gems to be entered into mainline"

This would be great marketing tagline for Red Hat. But I hope you realize the flawed logic behind this reasoning. Let's imagine for a second that PaX was a turd, and ExecShield a gem, or viceversa (depending on your touch with reality and experience on security matters and system internals). Why the integration of some of the PaX features was never considered for mainline?

I'm not talking about the segmentation-based approach to NX, which could have understandable drawbacks for inclusion. But, what about the other gazillion advances PaX has implemented a decade ago and everyone has been slowly, but steadily plagiarizing? (yes, you read that right: plagiarizing. The act of copying someone else's work without giving proper credit or obscuring it for one's self promotion).

Further more, "Linux systems are unsafe, or less safe than they need be" implies you mix an objective sense of security with your perceived one. Let's say that the child pornography collection of some pedophile in Thailand does not have the same security impact as the manuals for operating a military beacon. And I agree, but the problem is that Linux is unsafe because of managerial decisions taken by people who don't have the necessary background, understanding and acumen to make them. Just because Linus is a demigod among hippies does not make him a kernel security nutcase.

I won't go into greater depths to demonstrate that your logic is the actual flawed one, besides the seemingly sheer power you have for squeezing a handful ad hominem fallacies in such a short text.

Linux, so good it smells. If you drink the koolaid, it might go away.

"Protected" -- for how long?

Posted Apr 24, 2009 14:50 UTC (Fri) by hppnq (guest, #14462) [Link] (3 responses)

This would be great marketing tagline for Red Hat.

Even though in this very first sentence you reveal that 1) you do not understand the Linux kernel development process, 2) you do not understand the Red Hat business model and 3) you did not understand my comment, you still managed to surprise me with the rest of your comment.

"Protected" -- for how long?

Posted Apr 27, 2009 17:36 UTC (Mon) by dersteppenwolf (guest, #58226) [Link] (2 responses)

You are right, I don't really understand the business model behind Red Hat. It's quite a challenging thing to understand how a corporation gets away with making a profit from the work of helpful and altruist volunteers world-wide.

And in a similar path of reasoning, I don't understand how Linux (especially 2.6) could end up being used in a corporate environment. With all due respect, it's a theme park version of an operating system core. The rollercoaster gives you a huge thrill, but you throw up anyway.

Regarding your comment, It was indeed pretty awesome, man.

"Protected" -- for how long?

Posted Apr 27, 2009 23:58 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

Thus speaks someone who's never seen high-end financial software used to
throw umpty-trillions around the world.

Believe me, Linux is a glittering icon of perfection next to most of
*that* appalling grot. (I don't even need to mention the major settlement
system whose core was for many years an umpty-thousand-line shell
script... but I'm going to anyway because I want to make you feel as ill
as I do.)

"Protected" -- for how long?

Posted Apr 28, 2009 3:07 UTC (Tue) by dersteppenwolf (guest, #58226) [Link]

Thanks for giving me cancer. Can we get back to discussing why Linux is flawed because their developers choose it to be that way? Even goddamn Vista is safer at the moment. That's kind of a shame.

misquoting

Posted Apr 23, 2009 12:32 UTC (Thu) by pjm (guest, #2080) [Link] (6 responses)

tialaramex may not have been very articulate, and may have ben more curt than courteous, but I think was trying to make a helpful point (which I hope you won't yourself completely ignore, if I can explain it better).

There is quite a distance from Linus words that you now quote (expressing a belief that explicit changelog entries lead to more attacks by relatively casual attackers such as curious university students) to if we don't tell the bad guys about the bugs, they'll never find them.

It is helpful to look into the costs and benefits of various approaches to drawing attention to security flaws. It is helpful to point to this as one data point towards establishing to what extent the current approach to changelog entries is effective in reducing attacks. (Of course one data point isn't enough to show that it doesn't reduce attacks, but does give some information.)

Whereas misrepresenting someone's position in such a way as to give the false impression of having disproven their position (straw man tactics) is not helpful, and is both harmful to establishing the right answer to the question under consideration, and is also objectionable to the person being misquoted (as tialaramex tried to demonstrate with a fairly extreme example of misquoting).

I understand that you may not have intended to apply a straw-man approach, but the effect is the same. So the point is, be careful in representation or attributing quotation to someone.

I hope you find this not a worthless reply, when explained more carefully.

misquoting

Posted Apr 23, 2009 23:21 UTC (Thu) by PaXTeam (guest, #24616) [Link] (5 responses)

if you took this much time to explain what seemingly you failed to understand yourself, you might as well have done some further reading on the subject and saved some time here. i'll draw your attention to http://marc.info/?l=linux-kernel&m=121617056910384&... and its parent post http://marc.info/?l=linux-kernel&m=121616990509661&.... read them and understand where Linus drew the line: covering up the security impact of bugs for good. no ifs and buts, it's there in plain and clear text. what spender quoted may not have been the most descriptive to the subject matter but anyone who followed last summer's flamewar knows what it was about and how it concluded. in short, do your own research before educating someone on misrepresentation.

misquoting

Posted Apr 24, 2009 13:09 UTC (Fri) by pjm (guest, #2080) [Link] (4 responses)

I'm puzzled by your reply. Are you sure you're responding to something I've said? Do you feel it negates something I've said?

misquoting

Posted Apr 24, 2009 14:27 UTC (Fri) by pjm (guest, #2080) [Link] (3 responses)

For example, do you think that it wasn't a misrepresentation of Linus' position, or do you think it merely not important enough to take issue with? If the latter, then there's nothing more I can say on the issue.

misquoting

Posted Apr 25, 2009 1:29 UTC (Sat) by PaXTeam (guest, #24616) [Link] (2 responses)

> For example, do you think that it wasn't a misrepresentation of Linus' position

exactly. i even gave you the links to the thread where you can read about it yourself. have you?

misquoting

Posted Apr 25, 2009 12:36 UTC (Sat) by pjm (guest, #2080) [Link] (1 responses)

Oh good, now I know a bit more about where our differences are. The next thing to know is whether it's because we disagree about what Linus' position is, or whether we agree on the position but disagree about whether or not the words in quotation marks are a sufficiently close approximation to that position.

(I'll continue to spend some more time and space on this partly just for my own curiosity, and partly because there's a slim chance that exploring this might actually lead to a slightly better understanding of Linus' position; and maybe you'd like to understand why I or tialaramex have posted as we have.)

First of all, the easy case: has Linus literally said the words if we don't tell the bad guys about the bugs, they'll never find them ? I'd guess the answer is no, as this doesn't occur in the messages that you or Brad refer to, and a google search doesn't find it [other than here on this thread in LWN], and google does seem to find most other linux-kernel discussion; but maybe he said it in a different forum I'm not aware of that isn't indexed by google. If so, then that would clear things up straight away.

(Btw, I understand and even appreciate you asking to check with your correspondant that they have read the posts linked to: I know it's frustrating to discuss with someone who isn't actually giving thought to what you're saying. So yes, I had read the two posts you linked to, and also the posts that Brad referenced above and some of the surrounding posts, and I remember some of the discussion from when it last came up; though obviously I wouldn't be as closely familiar with the discussion as you and Brad, so thanks for having taken the time to post links to the relevant posts.)

Otherwise, do you believe that Linus either believes or has said that withholding information from commit messages will mean that no bad guy will know about any bug, or that no bug in Linux will be exploited in the wild ? (As distinct from believing merely that withholding information from commit messages will reduce how many bugs bad guys find out about, or reduce how many bugs will be exploited in the wild.)

Otherwise, do you think that there's no significant difference between saying "... then they'll never find them" and saying "... then fewer bad guys will ever find them" ?

There are some other possible reasons for our differing, but the above questions will do for now, if you too would like to continue to look into this. (I'll understand if you choose not to spend any more time on it.)

misquoting

Posted Apr 25, 2009 19:14 UTC (Sat) by PaXTeam (guest, #24616) [Link]

the easy case: think 'paraphrase' (as far as i know, that is. what went on in private discussions is unknown of course, but the public posts speak for themselves, see more on this below).

for what to read: it's not only about the few posts we linked to, it's the entire flamewar on lkml and some 5 threads here on LWN, hundreds of posts altogether. i understand if you're less than inclined to read them though, but then don't expect me to repeat all what was said back then either (much to the delight of many readers i guess ;).

as for your other questions: i assume you're not involved in computer security which would expain why you missed the real meaning behind spender's quote. in short, it was slyly disparaging as Linus' publicly stated position and actual actions are so much disconnected from reality (it's not a matter of my or anyone's belief, it's of public record, so much so that it earned him this nomination last summer: http://pwnie-awards.org/2008/nominees.html#lamestvendor).

let me leave you with some food for thought: imagine someone with the ability to write exploits against kernel bugs. imagine further he can also determine just by looking at a given patch whether it fixed a (potentially) exploitable bug (potentially, since one cannot be sure until one actually tries it, kernel bugs usually aren't the easiest kind to exploit). now imagine that you give this person a list of patches without telling him what they do. do you actually believe that this will prevent him from picking out the ones fixing exploitable bugs? because that's exactly what Linus et al. have tried to argue in their desperate attempt at explaining why coverup is good. last but not least: imagine that a file system driver has a bug that can corrupt on-disk data. do you think the proper approach is to not tell the world about it? history says otherwise. now imagine you have a kernel memory corruption bug that can do the same by virtue of corrupting filesystem (meta)data (let's forget about the potential for privilege elevation). do you think it's prudent to not tell the world about it and vehemently argue why it is even a good thing? history says yes. now consider that a memory corruption bug is typically much easier to abuse for trashing random memory (including the filesystem stuff i mentioned) than it is to properly and reliably exploit for privilege elevation. as i said, just some food for thought...