Forgot your password?
typodupeerror
Security Linux

Torvalds On Pluggable Security Models 216

Posted by kdawson
from the plain-speaking dept.
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:
  • Well (Score:3, Funny)

    by homey of my owney (975234) on Monday October 01, 2007 @06:44PM (#20817591)
    He's right.
    • Re:Well (Score:5, Interesting)

      by Trillan (597339) on Monday October 01, 2007 @06: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 Vellmont (569020)

        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
    • Actually, this tells me he doesn't understand one or the other. The only difference between scheduling and security numbers is how you measure. Security can be measured too, if you know what you're measuring -- number of attackers who gain access, number of attacks detected, compromises detected, etc. It's just the same in scheduling -- you can measure scheduling IF you know what you're measuring: realtime desktop performance, IO performance, etc. But similar conflicts arise in both: realtime latency vs
  • by Anonymous Coward on Monday October 01, 2007 @06:47PM (#20817625)
    I've been wanking around with pluggable opinions for years, and I turned out okay.
    • I've just been wanking around for years because finding some one to plug into is just too hard as a bonafide nerd.
  • by cez (539085) * <info@historystartingyes t e r d a y.com> on Monday October 01, 2007 @06:54PM (#20817675) Homepage
    I think Torvalds is right on this one. Until we can quantify security as we can scheduling performance, which he argues for, why shouldn't he keep LSM modular?


    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 ?

    • by gweihir (88907) on Monday October 01, 2007 @07:14PM (#20817835)
      Security cannot be quantified in hard numbers, since security is allways relative to the resources the adversary has. True, you could plan for some specific adversary. But that would be pretty meaningless. Also resources of an adversary is not a simple number that can be compared. Some thinks are limited to pecific attackers. Other stuff depends on money and/or time. Yet other stuff requires a specific type of competence. That is also why there typically is no "best" solution.

      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)

        by cez (539085) *

        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.

        "Wanking around" was a poor word choice at best, and I agree tha

      • by Vellmont (569020)

        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.
      • by RedWizzard (192002) on Monday October 01, 2007 @08:20PM (#20818361)

        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.
        If you actually read the article instead of just reacting to the sensationalist quote you'd know that this is exactly what Linus is saying. Security people don't agree and he is not qualified to make a decision so modularization needs to stay. In the case of the scheduler he feels he is qualified to make decisions and has done so. However he does bemoan the fact that the arguments presented by the security experts often don't make a lot of sense. This is where the "wanking around" quote comes from.
    • Re: (Score:2, Insightful)

      by QuantumG (50515)
      Blah. That's a totally backasswards way of looking at it. Why do you want to make something non-modular? Other than to make it hard for people to make competing implementations. No scheduler is optimal for all applications. You either make the scheduler modular so it can be replaced easily for a given application or you settle for less than optimal performance. Linus knows this too, so I don't know what game he is playing - probably trying to lock out that scheduler implementation that he doesn't like
      • by Solra Bizna (716281) on Monday October 01, 2007 @07:27PM (#20817959) Homepage Journal

        Yeah, because modularizing the scheduler doesn't have any performance or implementation or maintainance or QA problems.

        -:sigma.SB

        • by Kaenneth (82978)
          Even Microsoft knows by now, screwing with the sceduler is a bad idea... See the Vista/Gigabit/Audio issue, where because the system thread scheduler used a different 'mode' while playing multimedia content, it caused problems with high-speed networking.

          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)
      • by cez (539085) *
        Not arguing for his reasoning of adding scheduler to kernel space, just for his viewpoint that security should remain outside it as a module. You are right, "No scheduler is optimal for all applications", but that is something we can determine. How exactly are we to determine, hey that security module is much better for application X as this one is for Y.


        besides bonfire tales from the bearded ones on peyote during burning man.

        • by QuantumG (50515) <qg@biodome.org> on Monday October 01, 2007 @08:13PM (#20818309) Homepage Journal
          Wow, Linus should go into politics. The point of the argument is that Linus refuses to make the scheduler modular. He's taken the argument that he isn't opposed to security modules being modular but he is opposed to the scheduler being modular and turned it around to say that he can't make the security modules not modular because there's no good metrics for determining which is better than the other. This is an irrelevant truth. The fact that you can measure which scheduler is better than another for a particular application supports the notion that schedulers should be pluggable modules.. so you can easily use the one which is most appropriate for the given application.

          • by cez (539085) *

            The fact that you can measure which scheduler is better than another for a particular application supports the notion that schedulers should be pluggable modules..

            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: (Score:2, Interesting)

            by FoxconnGuy (997669)
            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
            ca
    • by Zigurd (3528)
      I don't think the pluggable security model is the controversial part. The controversy is about whether measures of scheduler performance are universal, or whether responsiveness metrics are different from, say, throughput metrics.
    • by SanityInAnarchy (655584) <ninja@slaphack.com> on Monday October 01, 2007 @07:28PM (#20817965) Journal
      I wasn't aware we'd completely solved problems of responsiveness vs throughput, or of normal vs soft realtime vs hard realtime.

      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 /etc/fstab be removed?

      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?
      • by cez (539085) *

        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 ?

        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

      • by Jah-Wren Ryel (80510) on Monday October 01, 2007 @08:13PM (#20818301)

        I wasn't aware we'd completely solved problems of responsiveness vs throughput, or of normal vs soft realtime vs hard realtime.
        And I don't think we ever will. I think Linus's point that scheduler performance can be measured is the strongest reason to go with pluggable schedulers. I want the scheduler that performs best for the way that I use my system. I don't think anyone gives a ratsass about how well the scheduler works for someone else. I want it to work best for me and my workloads.
        • by cmat (152027) on Tuesday October 02, 2007 @07: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.
          • No, Linus' point about schedulers is that to make a pluggable scheduler, you will need to sacrifice performance just to achieve the plug-ability.

            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.

            For one, the perfo

      • Re: (Score:2, Informative)

        by mrwolf007 (1116997)

        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.

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

          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?

        • Hard realtime usually implies severe perfomance penalties. People who really need something like that probably dont use a vanilla kernel.

          True enough, or at least, they don't use a kernel compiled with vanilla options.

          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.

          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

      • has often been what Linux has always been about.

        Yay for creative grammar... I apologize to anyone else who caught that. Preview is not my friend today :(

    • by Gorshkov (932507)

      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 ?

      Bingo.

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

      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)

      by kocsonya (141716)
      Well, scheduling performance can only be quantified to a degree. When I'm editing a document while running two computationally and disk intensive tasks in the background (e.g big simulations) I don't really care if the background calculations will finish 5 minutes later, but I do care about the editor and every GUI thing I have on the screen being snappy, just as snappy as if there was nothing running in the background. I'm not running the latest&greatest, just some older version of 2.6.??? but that doe
  • Awesome (Score:3, Funny)

    by obeythefist (719316) on Monday October 01, 2007 @07:01PM (#20817723) Journal
    "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"

    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)

      by jofny (540291)
      If they're any good, they'll agree with him...security is fundamentally subjective (what you want your box to do vs how much what you have on it is worth vs etc)
    • by Kjella (173770)
      I'm gonna forward that to our local security guys and see what they think!

      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
      • Hilarious, considering I have the same credentials than they do and I know which OU's are exempt from policies anyway. I like how they strut around so self-importantly despite this. If they even tried such a half-arsed scheme I'd be revoking their access to the domain quicker than you can blink. I'd cite a security threat to make it more amusing.

        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...
  • by Alexander (8916) on Monday October 01, 2007 @07: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)
    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.
  • What about (Score:5, Funny)

    by sokoban (142301) on Monday October 01, 2007 @07:32PM (#20817993) Homepage
    That hot chick on Television who asks if I have worms, and sells antivirus software. That's one pluggable security model right there.
    • by goombah99 (560566)
      I'll wank to that!
    • That hot chick on Television who asks if I have worms, and sells antivirus software. That's one pluggable security model right there.

      Yes, but that's an iterative solution with a known end condition.
  • by golodh (893453) on Monday October 01, 2007 @07:44PM (#20818085)
    Perhaps if people read all of Linux's email they would be more understanding and less quick to condemn him.

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

    • by TubeSteak (669689)
      FTFA

      LSM's weak semantics and pervasive deep hooking of the kernel means that
      > we'll have to continue dealing with several unpleasant issues, such as the
      > abuse of the API by out of tree vendors,
      Exactly what kind of API abuse are they talking about?
    • Re: (Score:3, Funny)

      by Ari Rahikkala (608969)

      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.

  • I mean, Theo's the security guy, right? I'm sure Linus would have no problem whatsoever agreeing to abide by his decision...
  • Ahem (Score:3, Informative)

    by deblau (68023) <slashdot.25.flickboy@spamgourmet.com> on Monday October 01, 2007 @08:38PM (#20818531) Journal
    Computer security isn't hard science? Someone should point Linus to the Orange Book [wikipedia.org] or the Common Criteria [wikipedia.org].
  • by NullProg (70833) on Monday October 01, 2007 @09:12PM (#20818769) Homepage Journal
    Correct me if I'm wrong, wouldn't a security plugin have to be authenticated? That would add a couple of extra layers not required for a scheduler. A "Rock Solid" built in security scheme might be better (Unlike the Windows address relocation method). Linus is correct in the fact that there is a new security method every week. Whats the correct one to choose?

    As for the Linux scheduler, I wouldn't mind a choice in desktop vs server tweak settings in (a) /proc/sys/scheduler (if it existed). RedHat, Ubuntu, SuSE, etc. could set the defaults based on user selection at install (Work Station vs Server).

    Enjoy,
  • irony (Score:2, Informative)

    by cycoj (1010923)
    I think there's some real irony here. Linus says that scheduling performance is "hard science" therefore it is easy to make a decision. But he did not make his scheduler decision based on "hard science" he based it on personal preference.

What this country needs is a dime that will buy a good five-cent bagel.

Working...