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:
  • by cez (539085) * <[info] [at] [his ... ngyesterday.com]> on Monday October 01, 2007 @07: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:Awesome (Score:3, Insightful)

    by jofny (540291) on Monday October 01, 2007 @08:13PM (#20817821) Homepage
    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 gweihir (88907) on Monday October 01, 2007 @08: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.
  • by QuantumG (50515) <qg@biodome.org> on Monday October 01, 2007 @08:16PM (#20817863) Homepage Journal
    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:Well (Score:1, Insightful)

    by Anonymous Coward on Monday October 01, 2007 @08:23PM (#20817931)
    as opposed to wanking around on slashdot complaining about Linus. I know what he has done for us lately, what have you done?
  • by Solra Bizna (716281) on Monday October 01, 2007 @08:27PM (#20817959) Homepage Journal

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

    -:sigma.SB

  • by SanityInAnarchy (655584) <ninja@slaphack.com> on Monday October 01, 2007 @08: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) * <[info] [at] [his ... ngyesterday.com]> on Monday October 01, 2007 @08:41PM (#20818059) Homepage

    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 that people "that at least understand present technology in that area make the decisions". However, that doesn't invalidate his argument of modulization.


    The best of present technology is modular to a certain extent, from a micro and macro perspective of system or network. Why implement a non-defacto standard of secure by including it in the kernel?

    I've run SELinux, and I know that James Morris isn't stating he wants that exact implementation only, but he says choose one. How do we quantify that or any assertion and make an informed decision going forward knowing that there possibly is a more secure path to follow?

  • Re:Well (Score:5, Insightful)

    by rumblin'rabbit (711865) on Monday October 01, 2007 @09:12PM (#20818293) Journal
    I've used lots of software that was arrogant and clueless. Hell, I've written software that was arrogant and clueless.
  • by Jah-Wren Ryel (80510) on Monday October 01, 2007 @09: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 QuantumG (50515) <qg@biodome.org> on Monday October 01, 2007 @09: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 kocsonya (141716) on Monday October 01, 2007 @10:08PM (#20818739)
    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 does not seem to be the case, as a matter of fact. So until the for example "perceived responsiveness" gets a firm definition and a method of quantifying it, scheduling performance is scientificly quantified only with the qualifier "..., neglecting all other factors that we can not quantify or care about."
  • Re:Well (Score:5, Insightful)

    by deek (22697) on Monday October 01, 2007 @10: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.
  • by NullProg (70833) on Monday October 01, 2007 @10: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:Well (Score:5, Insightful)

    by Daishiman (698845) on Monday October 01, 2007 @10: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.

  • by ASBands (1087159) on Monday October 01, 2007 @10: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:Ahem (Score:5, Insightful)

    by GreatBunzinni (642500) on Tuesday October 02, 2007 @02:26AM (#20820139)
    A normalized set of procedures to perform measurements does not a science make. If it was so then phrenology would be almost a pure science.
  • Pidgin (Score:3, Insightful)

    by upside (574799) on Tuesday October 02, 2007 @09:41AM (#20822157) Journal
    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:Well (Score:5, Insightful)

    by mr_mischief (456295) on Tuesday October 02, 2007 @11: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.

While money can't buy happiness, it certainly lets you choose your own form of misery.

Working...