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.'"
Re:Well (Score:1, Interesting)
He's convincing.
Re:Well (Score:5, Interesting)
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:Well (Score:2, Interesting)
Every time Linus has a decision to make there are two or more tom-cats out screeching and raising hell on the fence outside his window. Sometimes the tom-cats are looking at him like he is a tabby and your suprised if every so often he throws a boot at the tom-cats?
Re:Spot on Torvalds... (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
can't be implemented on Linux because timing requirements. Now the
scheduler supports real time and I can still use any applications
without knowing what the hack they have done to scheduler.
Now.
Give me an example that Linux scheduler can't satisfy your needs, and,
Give me an example that one security architecture satisfies you and me.
Re:If you read all of it ... (Score:1, Interesting)
This is a quintessentially pragmatic decision (if you can't get people to agree make it so that everyone can make the decision for him or herself) but done in what I feel is very rude manner. Look back at many decisions made around OpenBSD, especially as they relate to security policy, and you'll see the same thing.
The "let everyone decide for themselves" mentality is also very different from the stance Mr. Torvalds took on choosing GNOME over KDE ("The GNOME attitude is a disease. Just tell people to use KDE.") In that case he displayed exactly the hubris Mr. de Raadt is constantly accused of.
So at the end of it all, please tell me: Why do two people with very similar attitudes get labeled by the community so differently?
Re:Spot on Torvalds... (Score:3, Interesting)
Apples... Oranges...
Re:Well (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 MLS guys can be real assholes. I cannot fault Linus for the decisions he made. Based on my own reading of the Smack code, I would think it merits inclusion - it looks very clean.
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: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:Spot on Torvalds... (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.)