Torvalds On Pluggable Security Models 216
eldavojohn writes "The KernelTrap highlights an interesting discussion on pluggable security models including some commentary by Linus Torvalds. While Torvalds argued against pluggable schedulers, he's all for pluggable security. Other members were voicing concerns with the pluggable nature of the Linux Security Model, but Torvalds put his foot down and said it stays. When asked why his stance was different between schedulers and security, he replied, 'Schedulers can be objectively tested. There's this thing called 'performance,' that can generally be quantified on a load basis. Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is hard science. The other one is people wanking around with their opinions.'"
Well (Score:3, Funny)
Re:Well (Score:5, Interesting)
Re: (Score:2)
But being theoretically able to measure something doesn't mean it's practical or the the results are always useful.
The thing is that Linus isn't talking about the general case here, he's referring specifically to these two cases. If you've got some kind of performance consideration for scheduling that's not being measured, or have good evidence that the current measurements aren't relevant to the user experience, you should bring it up. If you're just speaking in a general philosophic way, that's nice an
No, he doesn't understand (Score:2)
Possibly (Score:2)
Re:Well (Score:5, Funny)
Re:Well (Score:5, Insightful)
Re: (Score:2)
Near all my software is arrogant, but I try to make it cluefull :)
Re: (Score:3, Funny)
I think he wrote Clippy.
Re: (Score:2, Informative)
Linus is an asshole.
Re: (Score:2)
But he's an asshole in a good way.
Re: (Score:2)
But he's an asshole in a good way.
Even when you do, getting dressed down by someone who knows WTF is up and is goal oriented and not just fucking with you hurts more, but is less humiliating than the usual abuse we (people) take from know nothing assholes who just want to ruin you for shits and giggles.
Re: (Score:2, Interesting)
Saying "no" is the toughest job in the world, but in this case it's a bit different. If you read further down in the thread this article was quoted from, you'd see that the purpose of LSM was so that Linux could keep going forward rather than being engaged in endless security flame wars.
Security is hard and in my own experience M
Re: (Score:3, Informative)
To some perhaps. To others he's just an effective team leader who makes decisions to focus efforts. The alternative is usually a lot of people flapping around like headless chickens since they don't know which way to go. Worse yet if the thing is run by an ineffective person or committee where development slows to a glacial pace because no patches are accepted or bogged down in protracted politics and debate. If you want to see what the kernel development would look like in those circu
Re: (Score:2)
If it takes one to know one, there's one thing I can't figure out, would you be Colonel or Captain Asshole ?
Re: (Score:3, Funny)
Re:Well (Score:5, Funny)
Re: (Score:2)
though the version I know is "don't anthropomorphize $objects, they hate that"
Re: (Score:2, Interesting)
How would you sound if you had been herding cats for years? Linus refuses in this case to chose whether the user cats get their tuna from Starkist or Chicken of the Sea. This makes the cat from Starkist and the cat from Chicken of the Sea mad at him.
Re:Well (Score:5, Insightful)
You're not being very convincing either. You call Linus all sorts of things, without actually saying specifically why you think he is arrogant, clueless, and has no understanding. I'm open to the idea that he may be, but your post certainly does nothing to convince me of it.
At least Linus has specifically stated why he thinks security guys are "wanking around". It's because security people state that "only my version is correct", when they don't quantify exactly why this is the case. That certainly meets my criteria for "wanking around". Linus appears to have made a good judgement call.
Re:Well (Score:5, Insightful)
Security is a process. You make the effort needed to crack or crash a system beyond the value to the attacker, and they won't attack.
There's simply no need of SELinux in a coffee pot or an MP3 player. It's overkill. Linus is concerned with all the targets of the kernel, and not just the Sewper Seekret Survur next to the dresser in some kid's room.
Now _you_ might be using Linux to keep millions of credit card numbers or to process satellite intelligence for some national government, but that's not what everyone does with it. So long as there are reasons to focus more or less on security and different needs among those focusing on it, pluggable security models make sense.
For the vast majority of Linux targets, SELinux in particular is probably overkill. The scheduler effects everyone. If your main goal is security at all costs, use SELinux (it's not hard) or use OpenBSD instead of Linux.
Re: (Score:2)
I think Linus should read this and he, of course, would find it very agreeable since that's *exactly* how he defines his leadership model.
You can read it here (http://lwn.net/Articles/105375/), if you don't believe me.
Just look at its very first paragraph:
"Everybody thinks managers make decisions, and that decision-making is important. The bigger and more painful the decision, the bigger the manager mus
Re:Well (Score:5, Insightful)
There is no security model that's better than others for all cases. They're all tradeoffs between convenience and security at the user level, and no, a security model is not quantifiable, as the amount of variation between specifications is mindboggling. Do you know the difference between RBAC, RAS, SELinux, AppArmor? Between the dozens of different and incompatible security systems used in AIX, Solaris, i5/OS, QNX, z/OS, and VMS? They all have their places, they all have their own advantages and disadvantages. Security doesn't stop with setting the "sticky bit".
But most importantly, security models are not CPU-intensive. Even the most demanding model will check file access permissions once in a blue moon in comparison to a scheduler. Schedulers store and use differnt information in very different ways which makes it difficult to make a generic framework that will support every possible datum they might need without making a significant impact on performance (it's a piece of code called thousands of times a second, performing rather complex computations).
Besides, it doesn't mean that Linux doesn't have several schedulers. It does, but they're kept under different branches, and they're sufficiently tunable to meet all your usual requirements, and CFS is a sufficiently superior alternative with the right stuff to warrant its maintenance in the mainline.
wanking around (Score:5, Funny)
Re: (Score:2)
Spot on Torvalds... (Score:4, Insightful)
If not, an artificial limit onto the integrity of the system would be created. Sure SELinux is a viable option, but why should we think it is the best ?
Re:Spot on Torvalds... (Score:5, Insightful)
So, no, security folks are not "wanking around" as some specific asshole seems to claim, they are using the best tools available to evaluate adequacy of different security solutions. Those that do not get this are not getting what security is about and what the state of the art is. These people should better stay far away from security-relevant decisions and let people that at least understand present technology in that area make the decisions.
Re: (Score:3, Insightful)
"Wanking around" was a poor word choice at best, and I agree tha
Re: (Score:2)
Security cannot be quantified in hard numbers, since security is always relative to the resources the adversary has.
I don't think anyone is asking for hard numbers for some general case. I think people are just asking for numbers for some specific cases. Lots of things in computing vary with one factor or another. I fail to see why one or many factors changing the outcome of what "best" is means you can't supply hard numbers.
Not that I think that hard numbers on which security model is really possible.
Re:Spot on Torvalds... (Score:5, Informative)
Re: (Score:2, Insightful)
Re:Spot on Torvalds... (Score:5, Insightful)
Yeah, because modularizing the scheduler doesn't have any performance or implementation or maintainance or QA problems.
-:sigma.SB
Re: (Score:2)
Now, if we can only kill off Daylight Savings Time. (seriously, if you want to get up an hour earlier, just GET UP AN HOUR EARLIER)
Re: (Score:2)
besides bonfire tales from the bearded ones on peyote during burning man.
Re:Spot on Torvalds... (Score:5, Insightful)
Re: (Score:2)
Ok, agreed... but, you can provide numbers to back that up. Statistics can always lie, regardless of if they are true. It's the fact that they are there and can be seen and visualized that is important. That being the case, it doesn't matter which way you lean towards schedulers. The fact that you cannot quantify security is an argument for
Re:Spot on Torvalds... (Score:4, Informative)
Re: (Score:2)
Re: (Score:3, Interesting)
Apples... Oranges...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Interesting)
I think some of the key scheduler performance metrics includes:
1. Context switch time.
2. Fair scheduling
3. Interactive tasks are interactive.
4. Certain applications always get larger portion of time if needed.
5. Real time.
There are things called "parameters" that you can adjust to adopt Linux
to your need.
This doesn't say Linux scheduler is perfect. It is evolving, too.
A few years ago, many embedded systems that needs real time scheduler
ca
Re: (Score:2)
So we can quantify scheduling performance? (Score:5, Insightful)
If we don't keep scheduling modular, an artificial limit on the performance of the system will be created. Sure, CFS is a viable option, but why should we think it is the best ?
What's more, "wanking around with your settings" has often been what Linux has always been about. Ubuntu never uses chroot in a normal situation; does that mean it should be taken out? My GUI and hotplug utilities can automount anything I plug in; should
We haven't used anything but ELF for probably 5-10 years, yet, last I checked, a.out is still supported.
Why should the system be made non-modular?
Re: (Score:2)
You are right, there always could possibly be a faster scheduler for a given system / task / embedded system.
One analogy however malformed uneducated and abysmal is:
Sure, it would be cool if you put NOS kit on a ferrari, but once you hit a wall it won't matter if you are going 150 or 225 if you aren't wearing a seatbelt or ther
Re:So we can quantify scheduling performance? (Score:5, Insightful)
Re:So we can quantify scheduling performance? (Score:5, Interesting)
The security realm however is completely different. For one, the performance requirement does not exist. So the performance penalty that modular architecture brings is largely irrelevant. And since there exist no metrics that can be used to determine whether one security model is better than another without the usage context, a plug-able architecture is the best road to go down to let something that users CAN and WILL want to implement completely differently from one use-case to the next.
Re: (Score:2)
If it had to be hot-pluggable -- as I believe some of these are -- then yes.
But just run "make menuconfig" and take a look at the insane number of options you have for compiling a Linux kernel. It seems to me that slapping some #ifdef statements around some code isn't going to make it perform any worse.
It might, however, be harder to maintain.
Re: (Score:2, Informative)
I wasn't aware we'd completely solved problems of responsiveness vs throughput, or of normal vs soft realtime vs hard realtime.
Hard realtime usually implies severe perfomance penalties. People who really need something like that probably dont use a vanilla kernel.
If we don't keep scheduling modular, an artificial limit on the performance of the system will be created. Sure, CFS is a viable option, but why should we think it is the best ?
Torvalds usually doesnt care about something being the best. Its supposed to be good enough.
Using the word best requires you to say for what, otherwise you might as well use a word such as coolest, most geeky, most whatsoever.
Since Torvalds usually cares a lot about efficiency i guess that a plugable scheduler would be less performant.
Re: (Score:2)
Using the word best requires you to say for what, otherwise you might as well use a word such as coolest, most geeky, most whatsoever.
So one is required to say for what something is best for, but not for what something is good for?
Maybe you want to think about this a bit more?
Re: (Score:2)
Well, I was commenting on the format structure of your argument: my point is, if you are required to say what something is best for, I see no reason why you should not be able to be required to say what something is good for. Your reply may be cogent or not, I really do not have a strong opinion. I was only pointing that you may want to find a stronger argumentation.
Re: (Score:2)
True enough, or at least, they don't use a kernel compiled with vanilla options.
The whole point of wanting a pluggable scheduler is to let the end-user answer that "for what" question, instead of having Linus answer it for you, or have t
Ew, redundancy... (Score:2)
Yay for creative grammar... I apologize to anyone else who caught that. Preview is not my friend today :(
Re: (Score:2)
Bingo.
.... taste.
Security is, in fact, quantifyable - you can tell if your data is or is not secure in either absolute or relative terms. But that still misses one basic, very important element
Yes, taste *is* involved in security. Just as there are many different ways to sort data, and still wind up with an alphabeticalized list, there are also many d
Re: (Score:3, Insightful)
Re: (Score:2)
Because that means more code to maintain. Code that might be broken later.
However, I do think there's sufficient reason to keep it pluggable. We have all kinds of other things pluggable that don't need to be, and plenty of other cruft in the kernel -- think binary formats other than ELF, old filesystems that nobody uses, and completely depricated systems like OSS for sound.
This reeks of politics, something I thought Linus was good at avoi
Re: (Score:3, Informative)
Indeed, it's also been showing (RTFML) that scheduler improvements are mostly trivial and generally don't warrant such an effort.
Finally, one must cons
Re: (Score:3, Interesting)
I understand that it needs to be maintainable, but I would think a flexible architecture would be MORE maintainable, not less.
(I admit that I don't have enough experience to make such a statement, at least about Linux and C.)
Re: (Score:2)
Re: (Score:2)
Linus simply stopped accepting patches from either of them until they sorted out their differences.
He could have chosen sides, but he didn't.
Re: (Score:2)
<sarcasm>They only think they need them. Really, they're just wanking around with their settings.</sacrams>
Consider if we only supported, say, ext3 for the root filesystem, and the only filesystem supported for mounting. Anyone who wanted to work on new and exciting stuff, like, say, ext4, would do so with a fork. Access to other filesystems, like network,
Re: (Score:2)
Yeah. Sounds like ALSA/OSS.
In fact, there already are a few notable instances of this -- NTFS being the obvious example. The userspace NTFS implementation is actually much more robust and featureful.
Moreover, this is already true of every filesystem that I know of, to some extent. Remember that the userspace implementation need not provide everything the k
Re: (Score:2)
Indeed. Nothing about the system I proposed requires more duplication than we have, except for people wishing to run a different filesystem as root.
That's a fair point, but then...
Are you saying that what people want should dictate the
Awesome (Score:3, Funny)
Thanks Linus, that cracked me up. I've always felt that way about a lot of the stuff the security guys do. I'm gonna forward that to our local security guys and see what they think!
Re: (Score:3, Insightful)
Re: (Score:2)
You're mixing types here and -fail- at logic. Process and Methodology are synonyms. Results can be from processes and methodologies. Results can be both objective and false/actual/perceived all at the same time. Etc. Were you trying to say "security is a lot of different things"? Thanks captain obvious.
SECURITY is (especially because of the obvious truth you pointed out) a concept wi
Re: (Score:2)
There is a fact of the matter whether a particular model or implementation can be breached by an adversary, even with infinite resources.
"No adversary should gain access to any resource unless implicitly or explicitly authorized to use it".
Both of these are true. But they both assume someone has (subjectively) identified which resources to protect and how much cost/effort should be spent to pr
Re: (Score:2)
I think someone missed the memo with "don't piss off the guys that could make your life hell". Have you any idea how quickly everything would come to a grinding halt if they were really anal about applying every detail in the security policies? No, I don't mean the normal terror regime, I mean the kind that'd actually kill the business and force change if they ever tried to apply it company-wide. Now, instead imagine that they make a
Re: (Score:2)
Your comments have thus proven Linus's original comment perfectly valid. Security guys are wankers.
"don't piss off the guys that could make your life hell"
No...
Re: (Score:2)
Cold Hard Engineering Measurement, or Science? (Score:3, Interesting)
``...the subjectivist states his judgments, whereas the objectivist sweeps them under the carpet by calling assumptions knowledge, and he basks in the glorious objectivity of science.'' - I.J. Good
I stopped reading TFA (Score:2, Interesting)
Damn I'm sick of scheduler FUD. It makes its way into every single linux conversation now, now matter how unrelated.
Re:I stopped reading TFA (Score:4, Funny)
You'll reprioritize when your starving children become zombies and your parent tries to kill you.
What about (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Yes, but that's an iterative solution with a known end condition.
If you read all of it ... (Score:5, Informative)
His complete email reads:
Schedulers can be objectively tested. There's this thing called "performance", that can generally be quantified on a load basis.
Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers.
So the difference between them is simple: one is "hard science". The other one is "people wanking around with their opinions".
If you guys had been able to argue on hard data and be in agreement, LSM wouldn't have been needed in the first place.
BUT THAT WAS NOT THE CASE.
And perhaps more importantly:
BUT THAT IS *STILL* NOT THE CASE!
Sorry for the shouting, but I'm serious about this.
Al I alone in thinking that Linux basically says:
"Look I'm no security expert, and I'd be happy to follow your collective expert guidance if only:
(a) you could quantify what you're saying and turn it into engineering instead of a religious argument
(b) the lot of you could agree on *one* set of guidelines/features as being best all-around
Unfortunately it appears you can't do either. That being so, I'm not going to burn my fingers and blindly choose one security boondoggle over all the others. I'll just make them pluggable so that every one of you can have his own personal security system. End of discussion. Now go away and be happy."
Re: (Score:2)
> we'll have to continue dealing with several unpleasant issues, such as the
> abuse of the API by out of tree vendors,
Re: (Score:3, Funny)
Perhaps if people read all of Linus's email they would be more understanding and less quick to condemn him.
If I could read all of Linus's email, I think I would be more understanding of him wanting to be able to work with security models :p.
Re: (Score:2)
Bring deRaadt in for a consult (Score:2, Funny)
Ahem (Score:3, Informative)
Re:Ahem (Score:5, Insightful)
Scheduler vs Security Plugins (Score:3, Insightful)
As for the Linux scheduler, I wouldn't mind a choice in desktop vs server tweak settings in (a)
Enjoy,
irony (Score:2, Informative)
Re: (Score:3, Informative)
I can't videoconference, edit videos, make mp3s, play video games or make a slideshow in Linux. How about a couple of kernel devs drop off and help Linux go the last mile.
Other than video conferencing (haven't tried), my wife and 13 year old son can do everything on your list (using SuSE, Fedora or Ubuntu).
Shouldn't you be posting questions to http://www.linuxquestions.org/ [linuxquestions.org] or http://www.justlinux.com/ [justlinux.com] ?
You wont get a RTFM response.
Slashdot isn't a Linux help forum.
Enjoy,
Re: (Score:2)
Re: (Score:2)
Just because you can't does not mean Linux can't.
VideoConference http://ekiga.org/ [ekiga.org]
Edit Video http://www.kdenlive.org/ [kdenlive.org]
Make mp3s: Insert CD copy mp3 folder with kde.org [slashdot.org] or Create new with http://audacity.sourceforge.net/ [sourceforge.net]
play video games with http://www.winehq.org/ [winehq.org] or http://www.transgaming.com/ [transgaming.com] or god forbid you play open source games designed for linux. Too many to list see here http://icculus.org/lgf [icculus.org]
Re: (Score:2)
Maybe not as helpful, but it cracked me up.
Pidgin (Score:3, Insightful)
Pidgin is an instant messaging program for Windows, Linux, BSD, and other Unixes.
How is a shortcoming of this software a shortcoming of Linux? You may be right to say there is no combined im/VOIP/video conferencing suites for Linux. Sounds strange to me, though. Perhaps you can make a feature request for Pidgin.
Re: (Score:2, Funny)
Re: (Score:2)
Re: (Score:3, Funny)
Re:like object oriented? (Score:5, Insightful)
At some point, you have to deal with the fact that there is going to be some overhead in dealing with an object-oriented approach. Even if the significance is near 0, the scheduler is pushing operations on the CPU on an incredibly large scale, which might show its ugly face in performance. IMHO, it wouldn't, but I guess Linus knows better than I...
Anyway, there is this great site called the Linux Kernel Archives [kernel.org], which has the source code for every version of the Linux kernel ever put out. If somebody was really serious about using their own CPU scheduler, all they have to do is take the latest version of the kernel, download the source code and modify sched.c to fit their needs. Even if it isn't object-oriented, that doesn't change the fact that everything else in the kernel only cares that default_wake_function tries to wake up a thread - it doesn't matter how it works on the inside. All the other parts know about is the sched.h header file.
Sure, it isn't on-the-fly pluggable, but different distributions could easily use different schedulers if they simply compile the kernel. A distribution could make a sched.c that is pluggable (it would have an interesting look to it, but it could be done). I wouldn't want to debug it, but for all this complaining, you'd think somebody would do something about it.
Re:like object oriented? (Score:5, Interesting)
Ahh, the "when in doubt claim OO is expensive" defense. Please tell me, how long does a modern CPU need to take a branch to an address in a well known fixed memory cell which is guaranteed to be in L1-cache? Do you think it is longer than a conditional branch needed to handle the case single core dual core? Is it longer than the combined times needed to additionally handle the case one CPU-chip two CPU-chips? I don't know, I haven't done the measuring, but I have doubts the first is the slowest as the opcode scheduler should be able to handle the first and especially has the advantage of an always taken jump. We are heading in a parallel future, there are scheduling differences between single core/dual core and single CPU/multiple CPU. Why on earth should the scheduler written for the most complicated case (it has to handle cases like one dual core and two triple cores and one quad core efficiently or it is not the best scheduler, no?) be more efficient than a single core scheduler on a machine with only a single core? Or are the benchmarks "tweaked" so the first is the "right" case to benchmark?
As written by multiple posters, yes, you can get benchmark results for schedulers, but what is the correct benchmark? Is it the maximum throughput model you don't want to have as a desktop box or the minimum waiting time for interactive jobs you don't want on a compute server? And if you need numbers to come up with the best security model, count line numbers, it is about as relevant.
Re: (Score:3)
The reason why the scheduler is so performance sensitive, is that it uses close to the worst case
Re: (Score:2)
And why would that be relevant in this case? The kernel is written in C, not an OO language so it would have to be simulated in any case. What I would do is to define the interface as a sequence of jump sl
Re: (Score:2)
Says somebody that, it seems, never tried that on real life.
Good luck with any functionality change in sched.c. And if you really want to mess with the scheduler, not thread wake up, I really desire you a lot of luck to keep the informati
Re: (Score:2)
This is Slashdot. Nudity.
Re: (Score:3, Funny)