Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Torvalds On Pluggable Security Models

Posted by kdawson on Mon Oct 01, 2007 06:40 PM
from the plain-speaking dept.
Security Software Linux
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.'"
+ -
story

Related Stories

[+] Linux: Torvalds Explains Scheduler Decision 411 comments
Firedog writes "There's been a lot of recent debate over why Linus Torvalds chose the new CFS process scheduler written by Ingo Molnar over the SD process scheduler written by Con Kolivas, ranging from discussing the quality of the code to favoritism and outright conspiracy theories. KernelTrap is now reporting Linus Torvalds' official stance as to why he chose the code that he did. 'People who think SD was "perfect" were simply ignoring reality,' Linus is quoted as saying. He goes on to explain that he selected the Completely Fair Scheduler because it had a maintainer who has proven himself willing and able to address problems as they are discovered. In the end, the relevance to normal Linux users is twofold: one is the question as to whether or not the Linux development model is working, and the other is the question as to whether the recently released 2.6.23 kernel will deliver an improved desktop experience."
Submission: Torvalds on Pluggable Security Models by eldavojohn (898314)
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Torvalds On Pluggable Security Models 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

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

      • 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

        • Re:Well (Score:5, Funny)

          by HeavensTrash (175514) on Monday October 01 2007, @07:23PM (#20817929) Homepage
          Linux is arrogant and clueless? I didn't know an OS could have human traits.

          • Re:Well (Score:5, Insightful)

            by rumblin'rabbit (711865) on Monday October 01 2007, @08:12PM (#20818293) Journal
            I've used lots of software that was arrogant and clueless. Hell, I've written software that was arrogant and clueless.
          • Didn't you know? Software wants to be free. Information wants to be anthropomorphized.

            • Re: (Score:3, Informative)

              by DrXym (126579)
              Linus is an asshole.

              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:Well (Score:5, Insightful)

          by deek (22697) on Monday October 01 2007, @09:08PM (#20818745) Homepage Journal

          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.


          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)

              by mr_mischief (456295) on Tuesday October 02 2007, @10:44AM (#20823963) Journal
              Security is not a package. Say it with me now, "Security is not a package".

              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:Well (Score:5, Insightful)

          by Daishiman (698845) on Monday October 01 2007, @09:40PM (#20818943)

          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)

    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.

  • Spot on Torvalds... (Score:4, Insightful)

    by cez (539085) * <cezsolutions@gmaiTIGERl.com minus cat> 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 ?

    • Re:Spot on Torvalds... (Score:5, Insightful)

      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

      • Re:Spot on Torvalds... (Score:5, Informative)

        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

      • Re:Spot on Torvalds... (Score:5, Insightful)

        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

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

        • Re:Spot on Torvalds... (Score:5, Insightful)

          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.

              • Re:Spot on Torvalds... (Score:4, Informative)

                by fabs64 (657132) <beaufabry+slashdot,org&gmail,com> on Monday October 01 2007, @08:54PM (#20818633)
                Did you even read the freakin discussion? The whole thing was about whether security should be modular, linus was arguing that it should stay modular, someone else was arguing that it should not and cited the scheduler as an example of linus preferring a singular option.

                  • Re: (Score:3, Interesting)

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

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

      • Re:So we can quantify scheduling performance? (Score:5, Insightful)

        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.

        • Re:So we can quantify scheduling performance? (Score:5, Interesting)

          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.

    • 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

      • My question is not should we add pluggable everything, but why NOT?

        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)

          by fimbulvetr (598306)
          You're right, AFAICT, but you've missed the emphasis on "more" code. From what I've read, the scheduler's tentacles touch just about every portion of vital linux code and making something "pluggable" on the order of this would require an enormous amount of effort - effort that would be pointless for all but very small minorities that can apply a patch easily.

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

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

  • Cold Hard Engineering Measurement, or Science? (Score:3, Interesting)

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

  • If you read all of it ... (Score:5, Informative)

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

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

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

  • Scheduler vs Security Plugins (Score:3, Insightful)

    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,

    • Re: (Score:3, Informative)

      by NullProg (70833)

      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,

      • Pidgin (Score:3, Insightful)

        by upside (574799)
        Never having used that software, I had a look at http://www.pidgin.im/about/ [pidgin.im]. It says

        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:like object oriented? (Score:5, Insightful)

      by ASBands (1087159) on Monday October 01 2007, @09:49PM (#20819007) 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...

      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)

        by Josef Meixner (1020161) on Tuesday October 02 2007, @03: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.

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

          The reason why the scheduler is so performance sensitive, is that it uses close to the worst case

      • Speaking as someone from the same demographics as Linus, I can assure you that he's familiar with the meaning of the word.
        Newsflash! Two nerds are familiar with wanking.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.