Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux's Security Through Obscurity

CmdrTaco posted more than 6 years ago | from the we-all-do-it-sometimes dept.

Security 215

An anonymous reader writes "The age-old full disclosure debate has been raging again, this time in no other place than at the foundations of the open-source flagship GNU/Linux operating system: within the Linux kernel itself. It beggars belief, but even Linux creator, Linus Torvalds, has advocated against the sort of openness on which Linux has thrived, arguing that security fixes to the kernel should be obscured in changelogs, saying 'If it's not a very public security issue already, I don't want a simple "git log + grep" to help find it.' Unfortunately, it's not kernel exploit writers who need to grep the changelog in order to find kernel vulnerabilities. On the contrary, it's downstream distributors who rely on changelog information in order to decide when to patch the kernels of their distributions, in order to keep their users safe."

cancel ×

215 comments

Sorry! There are no comments related to the filter you selected.

first (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24227109)

firsssst

8301: The year of Linux on the desktop (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#24227117)

NERDS!

The idealistic young become the cynical old. (4, Interesting)

HungryHobo (1314109) | more than 5 years ago | (#24227119)

And so the cycle continues.

The thing is that while security through obscurity is a fools game it can also hurt your users to publish exact details of the security vulnerabilities you've found in your own product before many of your users have had a chance to patch the problem.

Re:The idealistic young become the cynical old. (5, Funny)

neuromancer23 (1122449) | more than 5 years ago | (#24227283)

"Get off my lawn!" - Linus Torvalds

Re:The idealistic young become the cynical old. (5, Informative)

dch24 (904899) | more than 5 years ago | (#24227551)

Realistically, this article is light on the quotes of Linus because the article is trying to make a big deal out of Linus' words "I personally consider security bugs to be just 'normal bugs'. I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special. [kerneltrap.org] "

At that point, slashdot and schneier.com are just trolling. Read the whole email [kerneltrap.org] I quote above:

We went through this discussion a couple of weeks ago, and I had absolutely zero interest in explaining it again.

I personally don't like embargoes. I don't think they work. That means that I want to fix things asap. But that also means that there is never a time when you can "let people know", except when it's not an issue any more, at which point there is no _point_ in letting people know any more.

So I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special.

So there is no "policy". Nor is it likely to change.

It's a flamebait email thread. Linus has harsh words for BSD. Nobody ever said Linus doesn't do that -- but this is not security through obscurity.

His take on security issues is simply: they're bugs. Deal with it.

Unless they're malicious bugs... (0)

Anonymous Coward | more than 5 years ago | (#24227691)

unless the security bugs are malicious and in on purpose... they're just bugs by my definition.

Re:The idealistic young become the cynical old. (5, Insightful)

spankymm (1327643) | more than 5 years ago | (#24227903)

He's right - they're just bugs. Where he isn't right is about OpenBSD - security is a by-product of fixing bugs. They don't just fix the bugs, but when a new class of bug is identified the whole source tree is scanned for that type of bug - both kernel *and* user-land. But then Linux is just a kernel, isn't it?

Re:The idealistic young become the cynical old. (1)

gmack (197796) | more than 5 years ago | (#24228013)

It's funny how well that doesn't work for them. I still remember the number of bugs that were suddenly discovered in openSSH right after the Linux distros switched over to it.

Re:The idealistic young become the cynical old. (2)

spankymm (1327643) | more than 5 years ago | (#24228105)

In the 'portable' version of openssh?

Re:The idealistic young become the cynical old. (4, Interesting)

gmack (197796) | more than 5 years ago | (#24228171)

In both. There were some that were Linux only but quite a few affected OpenBSD as well.

It's not that they didn't do a good job and they clearly did a much better job than the SSH daemon they replaced it's just that the Linux distros adopting it increased it's userbase by a lot and as a side affect increased the the number of people who saw a need to look at the code.

Re:The idealistic young become the cynical old. (0)

Anonymous Coward | more than 5 years ago | (#24227947)

Maybe it's light on quotes because they wanted people to actually read the links included in the mail, and not have to repeat the huge amount of information already discussed?

Re:The idealistic young become the cynical old. (3, Interesting)

frodo from middle ea (602941) | more than 5 years ago | (#24228001)

The problem arises when you are using Linux in environments which must meet certain Government (SOX etc) , Industry standard (PCI etc) requirements on security. To meet these requirements you must routinely audit your systems and when you audit your systems, you need to classify security related bugs (vulnerabilities ) found, and having clearly marked security related bugs, will help these auditors/tools do a better job. May be for a kernel developer , security related bugs are on the same level as any other bugs, but for an end user of the Linux system, it will definitely be the most important bug. Otherwise how are Linux vendors supposed to create security-fix only updates ? Or do you expect every one to blindly upgrade the kernel every time a new point release comes out ?

Missing the point (5, Informative)

IceCreamGuy (904648) | more than 5 years ago | (#24228165)

I think what pageexec (the "antagonist" in the referenced thread) was trying to say was that he feels a lot of the developers don't follow Documentation/SecurityBugs in their commits in a consistent way. He's saying that when people post commits for regular bugs, they include a decent amount of data about what they fixed, but if it's a security bug, people are posting a minimal amount in their commits. Apparently in Documentation/SecurityBugs, it says that full disclosure is the policy, but what he's seeing is less than full disclosure in practice. That is what the thread is actually about, Linus' opinions are ancillary to that point.

He's just saying that it seems to him that what is written as policy for kernel devs is not what they're actually doing, so they should either change the policy or change their commits. If the changelogs don't conform to policy, at some point somewhere downstream devs are going to miss something because the policy doesn't match the practice, and that's what's a security risk.

Re:The idealistic young become the cynical old. (3, Insightful)

NickFortune (613926) | more than 5 years ago | (#24228385)

At that point, slashdot and schneier.com are just trolling

Umm.... the schneier article is almost seven years old and discussing apparently discusses a release of the 2.2 kernel. I think the article was referenced purely as summary of security-through-obscurity issues, rather than an attack on Linus.

Re:The idealistic young become the cynical old. (4, Insightful)

fictionpuss (1136565) | more than 5 years ago | (#24227297)

The thing is that while security through obscurity is a fools game it can also hurt your users to publish exact details of the security vulnerabilities you've found in your own product before many of your users have had a chance to patch the problem.

Surely though, the people who are looking to take advantage of security vulnerabilities, are generally the ones who already have a financial motivation to do so? The people who already have their own dark networks to share or buy and sell vulnerabilities?

Won't they still do this even if it becomes harder to decipher changelogs? The only thing changing then, is that it'll take longer for regular users to see the danger.

There is no absolute security (3, Insightful)

bunratty (545641) | more than 5 years ago | (#24227409)

But won't fewer be able to take advantage of security vulnerabilities if it becomes harder to decipher changelogs? Security is not an all-or-nothing situation. The fewer people who know about a vulnerability, the fewer that can exploit it, and that means that users have a lower chance of being exploited.

That's actually an important point about security. You cannot make a useful system without any vulnerabilities. You can only maker it harder to exploit the vulnerabilities, meaning that fewer will be able to exploit them. For example, you cannot make an uncrackable and useful code, but you can make a code so hard to break that very few will even try.

There is no absolute scarcity (1)

fictionpuss (1136565) | more than 5 years ago | (#24227517)

Making a task harder does not necessarily limit production, especially if the new difficulty level still lies within the skill level of the individuals involved.

Isn't the real problem that you're fighting against market forces which create a demand for the vulnerabilities in the first place?

Re:There is no absolute security (1, Insightful)

Anonymous Coward | more than 5 years ago | (#24227595)

Your confusing exploiting vulnerabilities with knowing they exist.

All this does is make it harder to know about vulnerabilities. The fewer who know about vulnerabilities only means the fewer who know how to fix, patch, or work around them.

To fix your analogy: For example, you cannot make an uncrackable and useful code, but you can make a code so hard to read that few people will even try to read it to find exploits, or to fix the exploits. Those looking to exploit the code could always use the trusty binaries, like they have always done, but the rest of us depend upon the source code to know about possible vulnerabilities, to work around them, and fix them.

Re:The idealistic young become the cynical old. (1)

BPPG (1181851) | more than 5 years ago | (#24227807)

He's not announcing his security bugs, but at the same time he's not using deceit or obfuscation to hide them. After a certain amount of time he might release his private notes on what's not already well known by then, but he has no real reason to at the moment. No point in punishing those who haven't upgraded.

Re:The idealistic young become the cynical old. (1)

inode_buddha (576844) | more than 5 years ago | (#24227933)

"Surely though, the people who are looking to take advantage of security vulnerabilities, are generally the ones who already have a financial motivation to do so"

I bet a fair bunch in the pool you selected do it just for the hell of it. Also I think Linus and the distributors nee to take a vacation.

Re:The idealistic young become the cynical old. (1)

freddy_dreddy (1321567) | more than 5 years ago | (#24228297)

Won't they still do this even if it becomes harder to decipher changelogs? The only thing changing then, is that it'll take longer for regular users to see the danger.

Bang on, what's exactly the technical difficulty in scripting something that deciphers vulnerabilities (e.g. struct leaks) from a changelog ? It may take a few days, but once it's written you'll have the same problem. So in the end you punish the regular users and give the ones you target a fun project to work on.

Re:The idealistic young become the cynical old. (4, Insightful)

dotancohen (1015143) | more than 5 years ago | (#24227355)

Read the replies. Linus is not advocating security through obscurity. He just doesn't want a big flashing sign "SECURITY" on security-related bugfixes. He doesn't want them to stand out in any way at all.

Re:The idealistic young become the cynical old. (5, Insightful)

Tupper (1211) | more than 5 years ago | (#24227581)

Yeah, he thinks security bugs are just like regular bugs. But he's wrong. Most bugs don't bite most users--- the ones that don't can be ignored. Very few people can ignore security bugs--- they bite everyone. The chance I need a random bugfix is very small; if I don't need it, I don't want it. The chance I want a security bugfix is almost 100%.

Re:The idealistic young become the cynical old. (2, Interesting)

dotancohen (1015143) | more than 5 years ago | (#24227789)

The chance I need a random bugfix is very small; if I don't need it, I don't want it. The chance I want a security bugfix is almost 100%.

And where will the manpower for triaging every bug for possible exploits come from? Not all security-related bugs are easily identifiable as such. And even if they were, and then they were marked as such, do you really want the changelog easily greppable by them?

Re:The idealistic young become the cynical old. (4, Funny)

TheGreek (2403) | more than 5 years ago | (#24227847)

Not all security-related bugs are easily identifiable as such. And even if they were, and then they were marked as such, do you really want the changelog easily greppable by them?

"Dear God, won't somebody please think of the children?"

Re:The idealistic young become the cynical old. (5, Funny)

dotancohen (1015143) | more than 5 years ago | (#24227929)

"Dear God, won't somebody please think of the children?"

Actually, as a kernel issue, this affects all the system threads.

Re:The idealistic young become the cynical old. (1)

richlv (778496) | more than 5 years ago | (#24227863)

first, i guess the reasoning here is to openly mark bugs already known to be security related as such.

second, really, this is about "us" being able to easily understand when we really, really should upgrade the kernel. even if did read full kernel changelogs, i wouldn't be able to understand which commits are security related. so i would rely on somebody to do that AND publicise it, at which point it gets more publicity than simply marking it in the changelog would have provided.

i'd argue that by not making them stand out will only create more hype - and for a good reason.
one thing i can see the motivation behind - not marking a fix as a security related until it has been developed, somewhat tested and maybe even a new kernel version is released.

Re:The idealistic young become the cynical old. (1)

dotancohen (1015143) | more than 5 years ago | (#24227955)

even if did read full kernel changelogs, i wouldn't be able to understand which commits are security related. so i would rely on somebody to do that AND publicise it, at which point it gets more publicity than simply marking it in the changelog would have provided.

That's what your distro does. Unless you are rolling your own, in which case, it is up to you to read the entire changelog and understand it.

Re:The idealistic young become the cynical old. (1)

richlv (778496) | more than 5 years ago | (#24228027)

this assumes that only large distributions will exist in near future.
imagine that somebody has to read full changelogs for ALL packages (included in the distro)... that's just not realistic and insane.

Re:The idealistic young become the cynical old. (2, Interesting)

ShibaInu (694434) | more than 5 years ago | (#24227913)

Don't THEY have the source code, since the kernel is free? How about a simple diff? Seems to me that if a malicious programmer is bothering to grep the changelog, just looking at the code changes isn't THAT much of a stretch? If Linux is "free" as in speech, keep it that way.

Re:The idealistic young become the cynical old. (4, Insightful)

xtracto (837672) | more than 5 years ago | (#24227995)

Yeah, he thinks security bugs are just like regular bugs. But [I think] he's wrong.

There, fixed it for you. The fact is that just because from your personal point of view a bug that is potentially useful to gain unauthorized rights does not mean that everybody sees it that way.

From what I have read about Linus, he is a very pragmatic guy. For him, a security bug is just another bug in the code (and in a simplistic way, it really is true).

Some people will be more concerned with those bugs, others will be concerned with bugs that reduce the performance of the OS, others will be more interested in bugs that reduce the reliability (as in, crashing every so often, etc).

The fact is that there are lots of people already classifying bugs, I think what Linus is saying is that he does not consider the job of the kernel guys to do such kiind of classification.

For them, it is just another bug that must be seen.

Re:The idealistic young become the cynical old. (0)

Anonymous Coward | more than 5 years ago | (#24228061)

"The chance I need a random bugfix is very small" is it really so if a bug keeps corupting your data on your hardrive or keeps crashing your machine, small random bugs can do alot of strange things

Re:The idealistic young become the cynical old. (0)

Anonymous Coward | more than 5 years ago | (#24228069)

99% of the bugs are a security problem.

Re:The idealistic young become the cynical old. (1)

Hatta (162192) | more than 5 years ago | (#24227657)

I want a big flashing sign saying "SECURITY" on security related bug-fixes. How else am I going to know that it's important to upgrade?

Most kernel fixes offer me nothing, it's very important that these bug fixes are marked so I know that they're urgent and not to be ignored like most other kernel fixes.

Re:The idealistic young become the cynical old. (4, Insightful)

gmack (197796) | more than 5 years ago | (#24227825)

Congratulations your exactly the reason Linus doesn't want a big flashing "Security" sign.

Linus' point was that most bugs can be potential security problems and if you ignore anything but security fixes you risk not patching in the case of a bug being discovered exploitable after the fix goes into the kernel.

Re:The idealistic young become the cynical old. (5, Insightful)

sukotto (122876) | more than 5 years ago | (#24227877)

In the same thread he also says "So as far as I'm concerned, 'disclosing' is the fixing of the bug. It's the 'look at the source' approach."

I don't see any security by obscurity going on here. He fixes the bug, and tells you in the changelog what the bug was.

What he's NOT doing is announcing in advance how to exploit the bug.

So why are so many people getting agitated about this?

What the... (5, Insightful)

gparent (1242548) | more than 5 years ago | (#24227123)

Linux users typically praise open source software on the basis that vulnerabilities can be found easily and patched by anybody who possesses the knowledge to do so, making open source software more secure. Why should this change now?

Re:What the... (5, Insightful)

HungryHobo (1314109) | more than 5 years ago | (#24227213)

As the userbase shifts towards more mainstream users and away from the technically abled the percentage of users to whom the "who possesses the knowledge" actually applies drops and the number who are likely to be slow updating their systems goes up.This changes the game a little. I'm a supporter of the open model but I can see where they're coming from.

Re:What the... (0)

Anonymous Coward | more than 5 years ago | (#24227389)

Oh! Does that mean that it's the Year of the Linux Desktop now? :)

Re:What the... (4, Insightful)

hcmtnbiker (925661) | more than 5 years ago | (#24228259)

Linux users typically praise open source software on the basis that vulnerabilities can be found easily and patched by anybody who possesses the knowledge to do so, making open source software more secure. Why should this change now?

This has nothing to do with the openness of the source code or the disclosure of vulnerabilities. Linus just doesn't want big proof of concepts for exploits in the last version of the kernel(which there will of course be people still running) to end up in this version. He doesn't want to aid script kiddies. Anyone can still find and patch parts of the code base, there's no move away from that.

Linus does not mean obfuscation (5, Informative)

Novus (182265) | more than 5 years ago | (#24227137)

Note that the quote from Linus [marc.info] continues:

That said, I don't _plan_ messages or obfuscate them, so "overflow" might well be part of the message just because it simply describes the fix. So I'm not claiming that the messages can never help somebody pinpoint interesting commits to look at, I'm just also not at all interested in doing so reliably.

He doesn't believe in obfuscating changelogs, just not filling them with security information making it easy to find vulnerable kernels.

Re:Linus does not mean obfuscation (1)

zebslash (1107957) | more than 5 years ago | (#24227187)

But only a diff will tell you where to look for the fix/vulnerability...

Re:Linus does not mean obfuscation (1)

von_rick (944421) | more than 5 years ago | (#24227473)

How can diff tell you things that haven't been entered into log files? Its against the law of thermodynamics.

Re:Linus does not mean obfuscation (1)

MadKeithV (102058) | more than 5 years ago | (#24227733)

You can find the code change itself in the diffs, which can tell you exactly what was fixed. Just not always why.

Re:Linus does not mean obfuscation (0)

zebslash (1107957) | more than 5 years ago | (#24228073)

If in the code you see a fix that looks like:

- for (int i=0; i<=bound; i++) {
+ for (int i=0; i<bound; i++) {

that gives you a good clue a buffer overflow may have been fixed.

Re:Linus does not mean obfuscation (1)

Hatta (162192) | more than 5 years ago | (#24227197)

How do you know if your kernel has a vulnerability then? If it's passed off as a mere bugfix, you may well decide it's not that important to upgrade your kernel right away.

Re:Linus does not mean obfuscation (0)

Timothy Brownawell (627747) | more than 5 years ago | (#24227369)

I thought all bugs were potential security holes?

Re:Linus does not mean obfuscation (1)

somersault (912633) | more than 5 years ago | (#24227591)

A bug that ends up with a computer game character able to jump incredible distances instead of the 'normal' distance doesn't seem like much of a security hole to me. And no, I'm not just talking about Spiderman. A bug is simply anything that causes a program to produce an unintended result, which could be a security exploit, but could just be something perfectly safe, but unexpected (in a bad way, not in a wow-this-AI-is-smart way).

Re:Linus does not mean obfuscation (0)

jefu (53450) | more than 5 years ago | (#24227967)

a computer game character able to jump incredible distances

I thought that the base context of the discussion was kernel and OS level code. In which case almost any bug has the potential to be a security bug at least at a denial-of-service level.

And I think I'd consider embedding a game character in the kernel to be a bug in and of itself.

Re:Linus does not mean obfuscation (1)

somersault (912633) | more than 5 years ago | (#24228273)

I wasn't really thinking in a kernel context, was just trying to think of an innocent bug. I'm not familiar with the kernel's code so I'm not sure where the kernel ends and other things begin, but if for example there was a bug that meant that the system time consistently read the time of the clock on the mobo as the actual clock time + 1 second, and wrote to the clock as the system time -1 second, then IMO that wouldn't pose a security risk, but I would still consider it a bug of sorts.

'Denial of service' (ie something is broken) isn't a security issue unless it is actively caused by an attacker. You don't call the police when your toilet is broken, you call a plumber. If something however is working but can be disabled by a malicious attacker via a bug in the kernel, yes that's a security issue.

Re:Linus does not mean obfuscation (2, Interesting)

betterunixthanunix (980855) | more than 5 years ago | (#24227275)

How is that any better? If I need to weigh security against stability, I need to know whether or not a patch fixes a major security bug on production machines or just changes obscure drivers that I don't even use. If I were to see a sudden increase in the number of attempted buffer overflows, I'm gonna want to check for known overflow attacks on the kernel and userspace programs I am administrating.

My theory? Linus is losing his mind, and he slips too far, we will wind up with a fork of the kernel (NetBSD/OpenBSD style).

Re:Linus does not mean obfuscation (2, Informative)

LO0G (606364) | more than 5 years ago | (#24227439)

I agree.

Here's the danger of not identifying security fixes in your patch logs: If a security fix isn't clearly identified, then customers won't necessarily update it.

I run Windows at work, the IT department there has deployed its own WSUS servers. They only deploy security fixes from Microsoft on those servers (don't ask, it's stupid, but it's what they do). If Microsoft were to hide security fixes in non security updates, then our machines would remain vulnerable to those security bugs.

The theory that somehow hiding the patches will keep customers safe (or deter the hackers from figuring out the vulnerability) is totally bogus. Even though Microsoft is closed source, security researchers can reverse engineer a working exploit from the binary patches in minutes [slashdot.org] .

It's important to flag security fixes as security fixes so that customers know that they need to give them higher priority.

Re:Linus does not mean obfuscation (1)

Timothy Brownawell (627747) | more than 5 years ago | (#24227593)

Here's the danger of not identifying security fixes in your patch logs: If a security fix isn't clearly identified, then customers won't necessarily update it.

How well does this hold if the customers know that fixes don't get special tags for having known security implications? Or when there's an intermediary whose job is specifically to handle such things?

Re:Linus does not mean obfuscation (2, Funny)

x2A (858210) | more than 5 years ago | (#24227907)

I would say that those people are the vulnerability and they're the ones that need patching. Not all vulnerabilities of a system are in the code!

Re:Linus does not mean obfuscation (2, Interesting)

gmack (197796) | more than 5 years ago | (#24227897)

If you want stability just stay on the current branch your on.. ex 2.6.23.x. No new features will be added only bugfixes. Need to know if you need to apply the patch? Just check the change log to see if the bug is in any subsystem you use.

Otherwise you risk someone discovering a bug is exploitable after the patch was added to the kernel.

 

It's already fixed right? (2, Insightful)

rubbsdecvik (1326987) | more than 5 years ago | (#24227147)

It would seem that if the vulnerability is patched in the change log, then it's fixed. I realize that some may need to run on an older kernel, but if a kernel developer found the vulnerability and fixed it, there is little way of knowing if anyone else (read black hat) has already known about it.

Re:It's already fixed right? (1)

gmack (197796) | more than 5 years ago | (#24227937)

There is no reason whatsoever to run a non bugfixed kernel. 2.2.x, 2.4.x and every 2.6.x branch since Linus switched over to the new shorter dev cycle are still actively maintained with bugfixes.

Isn't that part of their job? (4, Insightful)

MikeRT (947531) | more than 5 years ago | (#24227173)

On the contrary, it's downstream distributors who rely on changelog information in order to decide when to patch the kernels of their distributions, in order to keep their users safe."

As long as the information is in there, isn't it part of their job to read through the changelog, read between the lines, and update appropriately? I have no mercy for the commercial groups that do their own distributions, and quite frankly, if they're going to play with the big boys, anyone who is rolling their own distribution should be put the effort into it to read the changelog for the kernel. It's not like some security hole in a fairly obscure or minor piece of software that they're having to look out for.

Re:Isn't that part of their job? (4, Insightful)

betterunixthanunix (980855) | more than 5 years ago | (#24227447)

You say you have no mercy for commercial distributors, but the truth is that this sort of obscuration will only increase their business. Companies like Red Hat and Novell have the resources to pay people to spend all day reading through changelogs and deciding whether or not a patch is worth applying (in addition to people to are paid to submit patches). Universities may not have those resources, and their computer centers may only have enough time to quickly check a patch for common security fixes using grep. If it becomes impossible to do that, then all that we'll see is an increase in the number of people who buy support from commercial distributors, because they won't be able to support themselves.

Re:Isn't that part of their job? (4, Insightful)

kipin (981566) | more than 5 years ago | (#24227781)

And what exactly is the problem with this method?
If you don't have the time to perform security maintenance, but someone else does, why shouldn't they be allowed to make a profit for their time?

Re:Isn't that part of their job? (1)

betterunixthanunix (980855) | more than 5 years ago | (#24227815)

I never said it was a problem. I think it gives credence to free software in a corporate-based society like America.

Re:Isn't that part of their job? (0)

Anonymous Coward | more than 5 years ago | (#24227791)

So?

An increase in support revenue to Linux-based companies? Oh no!

You make that sound like it's a bad thing (3, Insightful)

MikeRT (947531) | more than 5 years ago | (#24227821)

If it becomes impossible to do that, then all that we'll see is an increase in the number of people who buy support from commercial distributors, because they won't be able to support themselves.

The more demand for commercial support, the cheaper it will become. That means that eventually the cost to support university Linux-based systems via RedHat, Novell, etc. may become cheaper than the cost of keeping people on staff to do it. The end result is that while the universities may not be doing it for themselves anymore, it's cheaper for them to focus on what they do best. After all, no one seriously argues that society is worse off today because the average car owner cannot rebuild their car like a mechanic.

Re:Isn't that part of their job? (1)

gmack (197796) | more than 5 years ago | (#24227971)

Under what conditions would a patch not be worth applying? Thanks to the new shorter dev cycle once a kernel is marked stable it doesn't need or get new features.. only bugfixes.

Re:Isn't that part of their job? (1)

MedBob (96899) | more than 5 years ago | (#24228003)

The work of the commercial companies in following changelogs is only in support of the places where they deviate from the "standard" kernel. I believe in the Frankenstein principle. "You create a monster, you take care of it". It's not always wise to create a fork, even a private one, because you are then responsible for it's care and feeding. I don't have a lot of sympathy in this issue, in that some of my largest problems have been where a particular distribution has to do a thing "their way", and by creating a different way, causes me grief. Don't get me wrong. I understand that I chose that particular package of grief. My point is that the option is always there to use the stock kernel. That should be the default unless there are overwhelming reasons not to. (and if so, should you not report a bug to the maintainers?)

Completely out of context (5, Informative)

Anonymous Coward | more than 5 years ago | (#24227183)

The article quote is completely out of context, go read the full thread and see what he really said. His main point is that security bugs are like any other bug. He doesn't see the point in putting code that can trip bugs into the git reports, whether it is a security bug or otherwise.

Re:Completely out of context (4, Insightful)

Anonymous Coward | more than 5 years ago | (#24228207)

Agreed. The thing to note is that this cuts both ways.

*Every* bug is a potential security bug. So should we look for ways to try to convert every bug into a security notice? Of course not! Why waste the time? What happens when it turns out that a bug doesn't have security implications? Do we shout "hurray!" and flag it as such?

Linus is entirely correct - a bug is a bug and must be fixed.

Summary: Flamebait? (5, Insightful)

struppi (576767) | more than 5 years ago | (#24227191)

The summary and the linked email from Brad Spengler look very flamebait to me. Linus Thorwalds writes in the quoted mail:

That said, I don't _plan_ messages or obfuscate them, so "overflow" might well be part of the message just because it simply describes the fix. So I'm not claiming that the messages can never help somebody pinpoint interesting commits to look at, I'm just also not at all interested in doing so reliably.

And from the second email:

> by 'cover up' i meant that even when you know better, you quite
> consciously do *not* report the security impact of said bugs
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.

Also, someone is not satisfied with an email from Linus Thorwalds and he drags the discussion over here to /. - This certainly will solve the problem... (Sorry for RTFA, I should know better)

"Sorry for RTFA"? (4, Funny)

argent (18001) | more than 5 years ago | (#24227233)

*snort*

And I thought I'd seen every variant on the usual Slashdot in-jokes.

You win a gold star.

Re:Summary: Flamebait? (1)

pruneau (208454) | more than 5 years ago | (#24227747)

Flamebait ? This is a kernel mailing list, for gods sake.

Have a look at this post [gmane.org] , and tell me who wins the flamebait pissing context.

Re:Summary: Flamebait? (1)

spankymm (1327643) | more than 5 years ago | (#24227973)

Well, probably me.

So (4, Insightful)

C_Kode (102755) | more than 5 years ago | (#24227285)

So, what they're saying is when you find/fix a vulnerability you should broadcast on BBC otherwise you will be less safe?

I don't think so. Love it or hate it, obscure security issues do protect some users. Obviously the issues need to tracked and I think changelogs are a good place to do it. There isn't a real reason to inform the world through all channels avaliable. Just fix it, log it, and move on. Anyone who needs to know will know where to look.

Two sides to this story (5, Informative)

yerdaddy (93884) | more than 5 years ago | (#24227303)

This is a an extremely one-sided presentation of this story. Linus makes some controversial but insightful points about the security obsessed culture in the community. This should not have been a "Linus has gone mad" story. This is a legitimate re-evaluation of how security patches are handled.

Read the thread, make your own decision:
http://thread.gmane.org/gmane.linux.kernel/701694/focus=706950

I just love the smell of napalm in the morning... (4, Informative)

Timothy Brownawell (627747) | more than 5 years ago | (#24227325)

See the Kerneltrap posting [kerneltrap.org] which includes a good part of the email discussion.

It looks like Linus' main concern is that publicizing a few bugs as "security" issues will act to hide other real security issues that weren't recognized at fix time; that any effort to publicize security issues will be so incomplete as to be misleading. And I see no mention of these concerns in the linked postings, almost as if the "full disclosure" people posting them are afraid to disclose the potential bugs (which would automatically be security bugs because of the topic) in their own methodologies.

Stop hiding. (0)

Bigmilt8 (843256) | more than 5 years ago | (#24227327)

Sounds shady to me.

Some context. (4, Informative)

delire (809063) | more than 5 years ago | (#24227357)

Looks like Brad is spinning things a bit. Further in the thread a 'Robert Peaslee' writes:

Hi Brad, Your comments are kind of misguided. Linus can be quoted as saying: "my responsibility is to do a good job. And not pander to the people who want to turn security into a media circus." He was referring to individuals such as yourself when making the circus comment, as your message was slightly alarmist and dramatized. Security is important, of course - but Linus' opinions [kerneltrap.org] are completely correct in terms of development of the Linux kernel. I would agree with you if security bugs were actually being hidden, but they aren't. They just aren't given special treatment.

From here [seclists.org]

Re:Some context. (0)

Anonymous Coward | more than 5 years ago | (#24228227)

Who the hell is Robert Peaslee?

Intentionally writing commit messages so as to avoid any mention of security is giving them special treatment. Including them in the -stable releases along with other non-security bugs, to the exclusion of the many other bugs in the kernel, is giving them special treatment.

Pragmatism (2, Interesting)

jandersen (462034) | more than 5 years ago | (#24227365)

I have never really seen Linus as a prophet, unlike some, and although I can see the sense in being as open as possible - because that gives developers a strong incentive to fix things - I can also see that it may not be completely stupid to allow developers a bit of time to try to fix a newly discovered security vulnerability. I mean, it is not as if we are talking about keeping things very secret in order to avoid doing anything about it; but most of the time, if the news about a problem isn't bellowed out in public as soon as it is discovered, it buys people just a little bit of valuable time.

Not the prophet? (2, Interesting)

Puffy Director Pants (1242492) | more than 5 years ago | (#24227921)

But I've already started compiling a book of his wisdom and am preparing to start a church! Oh well, guess any good religion needs an enemy.

Linus endorses MS security model!!!!!! (0)

Anonymous Coward | more than 5 years ago | (#24227479)

Linus, you fought a good fight, but your defeat was inevitable. You were a worthy opponent. WE SALUTE YOU.

Security Through Obscurity does have a benefit (1)

electrosoccertux (874415) | more than 5 years ago | (#24227553)

That benefit isn't as great as the benefit of OSS I think...
But consider what could happen if all the software for a voting machine were out in the open. Doubtless there would be those who might find a bug, and keep it to themselves in the hopes of using it to elect who they want. I'm not saying the current situation is better, because I think it's worse, but if the voting software were OS'd we might just be out of the frying pan and into the fire.

IANAP so maybe someone else can offer a technical solution for how to let the code be OS'd, yet keep it from being readily exploitable if a bug is found. Think of the money you could make betting on your presidential candidate...

Re:Security Through Obscurity does have a benefit (1)

a_real_bast... (1305351) | more than 5 years ago | (#24228117)

Design By Contract and formal methodology (mathematically proving a program's "correctness") would be a start.
The only time I'd even think of trusting voting machine software would be if it was FOSS. It's the only way to be sure that there isn't something in the code that scales the number of votes for a candidate by how much money the machine makers have given them...

Obscurity is an anti-freedom model (2, Insightful)

mlwmohawk (801821) | more than 5 years ago | (#24227641)

In the old argument, freedom requires responsibility, this is a prime example of the conflict.

In a truly freedom based model, you assume and rely on the fact that Linux users are responsible for their systems, and thus WARNING SECURITY BUG FIX NOW is a good title to an important patch.

In the less free "sharecropper" future of Linux where user's rely on upstream vendors to "take care of them" and take no responsibility for their systems, hiding such warning is great security theater to make them feel more secure. They are not more secure, we all know, but they FEEL that they are and the kernel guys pretend to act more responsibly in this "post 9-11" fear based world.

Its all bullshit and everyone who knows anything knows it. What surprised me was Vixie just saying "patch and trust us" without explaining, with specificity, why.

When even the proponents of freedom start to fear freedom, we are in deep shit.

Re:Obscurity is an anti-freedom model (0)

Anonymous Coward | more than 5 years ago | (#24228053)

He's not saying obfuscate security reports, he's just saying he's not going to stick a large flag on the changelog that gets published when the patch does saying SECURITY BUG EXPLOIT ME NOW BEFORE THE SYSADMIN READS THIS!
This way gives you the freedom to either put the work in keeping your system patched for all bugs, or accept the risk inherent, and not.

Re:Obscurity is an anti-freedom model (1)

mlwmohawk (801821) | more than 5 years ago | (#24228135)

He's not saying obfuscate security reports, he's just saying he's not going to stick a large flag on the changelog that gets published when the patch does saying SECURITY BUG EXPLOIT ME NOW BEFORE THE SYSADMIN READS THIS!

I understand what you are saying, but it is a disingenuous use of the English language to propose that titles and descriptions be less descriptive so as to not call attention to the real issue, and NOT call that obfuscation.

Re:Obscurity is an anti-freedom model (0)

Anonymous Coward | more than 5 years ago | (#24228423)

If I may make an analogy, it seems like the difference between a flaming campy queer, and an everyday gay guy who doesn't flaunt his sexuality.

Distributions rely on grep? (1)

calc (1463) | more than 5 years ago | (#24227665)

Since when did distributions rely on grep to find out about security problems?

There are upstream security mailing lists where security problems are disclosed to the various distributions security teams for most projects (and probably including the Linux kernel), so they probably know about these problems before they are even fixed to begin with.

There is a great quote in the thread (1)

jchandra (15040) | more than 5 years ago | (#24227797)

http://thread.gmane.org/gmane.linux.kernel/706950 [gmane.org]

I think the OpenBSD crowd is a bunch of masturbating monkeys, in
that they make such a big deal about concentrating on security to the
point where they pretty much admit that nothing else matters to them.

Re:There is a great quote in the thread (2, Funny)

dotancohen (1015143) | more than 5 years ago | (#24227891)

http://thread.gmane.org/gmane.linux.kernel/706950 [gmane.org]

I think the OpenBSD crowd is a bunch of masturbating monkeys, in
that they make such a big deal about concentrating on security to the
point where they pretty much admit that nothing else matters to them.

http://img136.imageshack.us/img136/7451/poster68251050mx9.jpg [imageshack.us]

Re:There is a great quote in the thread (3, Informative)

spankymm (1327643) | more than 5 years ago | (#24228039)

And if you read about the auditing process here: http://www.openbsd.org/security.html#process [openbsd.org]
We are not so much looking for security holes, as we are looking for basic software bugs...
Shame Linus has his head stuck up his ass, or he could have read that, too.

Wisdom from Ted T'so, as usual. (4, Interesting)

Medievalist (16032) | more than 5 years ago | (#24228059)

Read this post to get some perspective:

http://article.gmane.org/gmane.linux.kernel/707044 [gmane.org]

Linus is being blunt, as usual, and he's telling everybody what his personal policy is towards disclosure. If he finds a bug, he fixes it, and he doesn't rate security bugs as more or less important than other bugs because he's a kernel hacker, and therefore security bugs are not his sole focus in life. He doesn't use any special language to highlight or obscure security fixes in the changelog, he just describes the fix, which is what people are claiming is "security by obscurity".

From that, people looking for something to bitch about have created this kerfuffle; it is a tale told by an idiot, full of storm and fury, and signifying... nothing.(from Macbeth, 5.5)

"Shakespeare really kicks the cap off" -- James Hovenac

Linus does not understand security (-1, Troll)

gweihir (88907) | more than 5 years ago | (#24228077)

True, his achivements are impressive. But he is not the person to look to when security is concerned. Security by obscurity only hinders the defenders, almost never the attackers. Somebody that has problems finding hints to vulnerabilities in the changelogs, will also have problems writing the exploits. But the defenders need to find _all_ vulnerabilities, nit just one. So their job need to be made as easy as possible. Security people understand that, Linus does not. Not the first time he mouths off about something he has no real clue about.

Personally I would put the security fixes in special places, so they can be found fast. The Black Hats already have them, so lets at least level the playing field to some degree.

After using Ubuntu for a year..... (1)

NWJeepn (936583) | more than 5 years ago | (#24228095)

I am considering moving back to Vista, I have a pretty plain install of Ubuntu but almost daily there are a least 4 or more security updates that need to be installed. Then the system usually requires a reboot for the updates to take effect.

Heck, at least Microsoft is only one Tuesday a month and you get them all at once.

Linux meets the Real World (1)

urcreepyneighbor (1171755) | more than 5 years ago | (#24228155)

Season 2, Episode 6.26

Torvalds falsely accused of security coverup .. (5, Informative)

rs232 (849320) | more than 5 years ago | (#24228181)

"so guys (meaning not only Greg but Andrew, Linus, et al.), when will you publicly explain why you're covering up security impact of bugs", pagee...@freemail.hu

"I don't cover them up", Torvalds

"by 'cover up' i meant that even when you know better, you quite consciously do *not* report the security impact of said bugs", pagee...@freemail.hu

"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", Torvalds

"one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important", Torvalds

"I refuse to have anything to even _do_ with organizations like vendor-sec that I think is a corrupt cluster-fuck of people who just want to cover their own ass", Torvalds

http://tinyurl.com/5qyon3 [tinyurl.com]
http://groups.google.co.uk/group/fa.linux.kernel/browse_thread/thread/5bdf2e1b8a90142c/abcf79768bb7ce7f?hl=en&lnk=st&q=#abcf79768bb7ce7f [google.co.uk]

slashdot indulges in provocative headlines .. (2, Insightful)

rs232 (849320) | more than 5 years ago | (#24228351)

This, in my view, is total nonsense, if you don't mand me saying so, CmdrTaco. The full source is out there for anyone to see, bugs are reported in the kernel mailing list, for anyone to see. How is this in any way shape or form 'security through obscurity'

Let the evil begin (1)

gatkinso (15975) | more than 5 years ago | (#24228357)

I knew it couldn't last. Oh well. There is always FreeBSD.

Obscurity does not hurt. (0)

Anonymous Coward | more than 5 years ago | (#24228369)

I think the point is that obscurity does not hurt security. On its own, it cannot substitute for actual security measures, but it doesn't DECREASE the security of a system. (If somebody can think of a counterexample I want to hear it!)

The problem is that not everybody can upgrade right away. The issue might have been fixed in version X.Y.Z but still exists in version X.Y.Z-1. Certainly you should fix the issue, but clearly explaining what it is will only cause harm to people still running X.Y.Z-1.

CmdrTaco indulges in flamebait .. (4, Insightful)

rs232 (849320) | more than 5 years ago | (#24228383)

corrected headline .. :)
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>