Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Security Linux

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.'"
This discussion has been archived. No new comments can be posted.

Torvalds On Pluggable Security Models

Comments Filter:
  • Re:Well (Score:1, Interesting)

    by QuantumG ( 50515 ) <> on Monday October 01, 2007 @07:47PM (#20817621) Homepage Journal
    Linus is never right.

    He's convincing.

  • Re:Well (Score:5, Interesting)

    by Trillan ( 597339 ) on Monday October 01, 2007 @07:47PM (#20817627) Homepage Journal
    He is right, definitely But being theoretically able to measure something doesn't mean it's practical or the the results are always useful.
  • by Alexander ( 8916 ) on Monday October 01, 2007 @08:21PM (#20817909) Homepage
    I think Linus may want to think hard about creating a distinction there.

    ``...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
  • by kwabbles ( 259554 ) on Monday October 01, 2007 @08:29PM (#20817975)
    The moment I saw the word "scheduler".

    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)

    by Anonymous Coward on Monday October 01, 2007 @09:21PM (#20818377)

    No. Linux is not convincing. He is arrogant and more and more clueless. Unfortunately people seem to be so in awe of him, that allmost nobody is willing to tell him that he has he is "wanking around" about a lot of things he obviously does not really understand.
    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. The user cat gets handed a can opener and while they can chose either source they want some of them complain that they have to chose and open the can. In many cases the distro-cat makes the choice and forks out the tuna from their choice of cans to their user cats. Again, some appreciate the choice and others hiss and threaten to scratch with the target of their threats anywhere from the distro-cat to the security-cats or to Linus.

    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?
  • by FoxconnGuy ( 997669 ) on Monday October 01, 2007 @09:56PM (#20818649) Homepage
    The key here is you have metrics to measure performance of schedulers.

    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.


    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.
  • by Anonymous Coward on Monday October 01, 2007 @10:13PM (#20818787)
    I'll never understand why Linus Torvalds can belittle the developers contributing to the kernel and be praised as a passionate and pragmatic engineer while Theo de Raadt gets schoolyard insults hurled at him every time he voices an opinion (which is admittedly quite often, but no more often than Mr. Torvalds).

    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?
  • by cez ( 539085 ) * <[info] [at] [his ...]> on Monday October 01, 2007 @10:40PM (#20818949) Homepage
    yes but, using that context begs the question of why anyone would ever compare the operation of system security vs. performance to begin with?

    Apples... Oranges...

  • Re:Well (Score:2, Interesting)

    by SL Baur ( 19540 ) <> on Tuesday October 02, 2007 @04:41AM (#20820643) Homepage Journal
    His job is to say "no" to ill-advised "features". Naturally, some people aren't going to like that. If you want ill-advised "features" stay with Microsoft Windows XP or whatever.

    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.
  • by Josef Meixner ( 1020161 ) on Tuesday October 02, 2007 @04:47AM (#20820669) Homepage

    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...

    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.

  • by cmat ( 152027 ) on Tuesday October 02, 2007 @08:24AM (#20821513)
    No, Linus' point about schedulers is that to make a pluggable scheduler, you will need to sacrifice performance just to achieve the plug-ability. Linus believes that the most flexible scheduler (i.e. performance, tune-ability) can be discovered at development time with a set of metrics that are defined currently. In which case he feels that the kernel devs can make the "best" choice of scheduler up front. Yes there will be fringe cases, in which case, you have the code, replace/tune/massacre the scheduler to your particular needs.

    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.
  • by SanityInAnarchy ( 655584 ) <> on Tuesday October 02, 2007 @10:23PM (#20832419) Journal
    Hasn't the work already been done, though?

    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.)

If you suspect a man, don't employ him.