Weekly Edition
Return to the Front page
| |||||||||||||
Linux fragmenting at last?
Back in January, Novell announced that it was releasing
the "AppArmor" security framework under the GPL. AppArmor had been
developed by Immunix, and acquired by Novell last year. Novell makes a
number of claims about AppArmor, but the one at the top of the list appears
to be relative simplicity: AppArmor is said to be easier to understand, configure, and
maintain than SELinux.
Dan Walsh, a Red Hat developer working on SELinux, has criticized this move:
Couldn't Novell have spent their money on making SELinux easier to
use? No, [Novell] chooses to split the user and developer community. I
am not sure what their goals are, but I feel this hurts Linux and
the open source movement.
For years, critics have claimed that Linux would fragment much like Unix did, and that would be the downfall of the system. So far, Linux has steadfastly refused to fragment in this manner. But now we have a Linux developer saying that the same thing is happening. Red Hat and Novell also appear to be taking different approaches to 3D-enhanced window systems. Novell is pushing Xgl, Red Hat has AIGLX, and Linux users are left wondering when and how all that activity will yield better graphics support for them. At this level, too, it looks like Linux might finally be heading for a breakup. Or is it? Perhaps we are simply seeing the development community at work. With regard to SELinux, it is important to note that there is no real consensus, yet, on how the security problem should be solved. SELinux is a powerful system, beyond doubt; it allows the capabilities of users and programs to be specified in great detail. But SELinux is also highly complex, to the point that a large percentage of system administrators find themselves unable to cope with it. The fedora-devel list just had a discussion on how to get administrators to keep SELinux enabled on their systems. One participant, who teaches administration courses, noted:
By no means is this limited to home users. I would say that the
*vast* majority of corporate admins just turn off SELinux. The story
behind how & why they learned to do that to begin with only vary in
details. It's almost always, "I had problems installing X or doing
Y and I found a document on the Internet that said that SELinux was
in the way and didn't work right anyway and was too complicated and
didn't do me any good and that I couldn't learn enough about it to
even understand what was happening, let alone deal with it, in less
than a month and ... well, so I just turn off SELinux and then I
don't have to deal with it."
The point here is not to criticize SELinux; that has been adequately done elsewhere. Instead, the real point is there is not, at this time, any sort of broad consensus that SELinux is the right tool for everybody's security problems. It may turn out that the best solution is to put more effort into making SELinux easier to deal with, but it seems premature to claim that SELinux will be the answer to security problems on Linux. It makes sense, in other words, to spend some time considering other approaches - especially those which are already implemented and relatively stable. If SELinux is truly a superior solution, that will eventually become clear and users will vote with their keyboards. But to claim, at this point, that SELinux is the only solution and that looking at alternatives hurts the community would be a mistake. This community thrives on choices, and, to an extent, it thrives on competition between related projects. Since the alternatives are all free software, users are able to choose what works for them, and the best ideas (and code) can move from one project to another. The process would be helped, however, if Novell would pull together the AppArmor source and submit it properly for review and eventual merging into the mainline kernel. The story with Xgl and AIGLX is the same. There is no real consensus, yet, on how 3D graphics will be best supported in the X window system. So two groups have put together two different implementations, each with its advantages. It is easy to present this story as a classic developer flamewar, but that does not seem to match the reality of the situation. A look at the X.org mailing list, for example, shows Xgl developer David Reveman agreeing to adopt some interfaces put forward by the AIGLX group. Over the long term, the development community will almost certainly coalesce around the approach which seems to work best, but, for now, it is too early to say which one (if either) will be most successful. If there is a problem here at all, it is that the distributors are being quick to make products out of technology which may not be entirely ready for prime time. Red Hat has operated this way for a very long time; anybody who remembers being pushed into, for example, the ELF or glibc2 transitions by Red Hat Linux upgrades knows that some of that code was a little rough around the edges then. But, by pushing that code out to the users, Red Hat almost certainly accelerated the stabilization process. What we are seeing now is that Novell wants to get into the same game and put more leading technology into the traditionally conservative (by comparison) SUSE distribution. When things work well, Novell will be able to claim leading-edge features and the code will get wider testing, sooner. There is nothing that requires Novell, as it moves SUSE Linux toward the leading edge, to follow Red Hat's decisions on which approaches to adopt. The risk is that each distributor's user base will find itself locked in to a different set of still-green technologies, making it harder for the development community to settle on a single choice. In the cases of security policies and 3D acceleration, however, the potential for lock-in seems low; most users will not care about which approach they use, as long as the system works well. So, most likely, those critics who have predicted the death by fragmentation of Linux will have to wait a while longer yet. (Log in to post comments)
Choices, choices... Posted Feb 28, 2006 20:15 UTC (Tue) by freeio (guest, #9622) [Link] The thing to remember is that neither RedHat nor Novell/suse represent gnu/linux by themselves. Yes, they are a couple of popular distributions, but they nevertheless do not define what the users can or must use. If the code is free/libre, then there is the possibility that others will develop it further, or it is possible that it will wilt and die. But so what? Each approach to solving a preceived problem is useful, if for no ther reson than that it provides something to try and see if it is the best solution, or even a good one.
The great benefit to free software is that no one is forced to use any particular commerical distribution's preferred methods. We have the choice. That, in and of itself, is not fragmentation. It is merely part of the evolutionary process which is inherent to free software.
Choices, choices... Posted Feb 28, 2006 20:34 UTC (Tue) by mrshiny (subscriber, #4266) [Link] It's true that we have a choice, but then, users often had the choice to switch to a different version of Unix in the past. The only read advantage that a fragmented Linux has over a fragmented Unix is that the various Linux fragments will work with the hardware you have, whereas changing Unixes often implies changing hardware.
But choice is often illusory as well: Users have a choice of Windows or Linux (or whatever), but often the choice isn't a true choice since there is something that locks a user into a particular system. For example, a company may widely deploy RedHat or Suse, then get "locked" into that system by inertia caused by accumulated staff experience and management tools. So it's not always easy or even possible to switch to a different distro without incurring a high cost.
Forward looking Posted Feb 28, 2006 21:39 UTC (Tue) by man_ls (subscriber, #15091) [Link] Your statement seems to me rather a wish than a necessity; things can possibly work out that way, but we must fight for it to be true. If we just stand by and don't watch Red Hat and Novell closely (or Mandriva and Ubuntu, for that matter), they might try a plethora of tricks to lock users in, starting with the tools that differentiate them -- and following with certifications, specifications...True, there's always community-based distros to counter-balance corporate distributions; but they are an even bigger reason to participate and not let them languish.
Community-based distributions as the answer Posted Mar 1, 2006 1:43 UTC (Wed) by freeio (guest, #9622) [Link] "True, there's always community-based distros to counter-balance corporate distributions; but they are an even bigger reason to participate and not let them languish."
Free software prospered even before there was commercial support. The well-known commercial distributions have helped various parts of the development along, to meet their own commercial needs, but it is indeed well to remember that even if the major vendors dropped all support today, that free software in general, and linux in particular would continue to develop.
So, yes, my most recent installs have been using the traditional community-based distribution (debian) not only for philosophical reasons, but because none of the high-dollar distributions support the Sun U5 hardware I run, while debian does. That profit-motive makes it not worth their time to support anything but the potentially high-volume architectures, and so the last version of Red Hat which supported Sun 5U was 6.2, and the last version of SuSE which supported Sun 5U was 7.3.
If we use only the few commercial distributions, then we are well on our way to lock-in and monoculture. Free/libre software development not only does not require that outcome, but provides the means to avoid it. That is not the feared fragmentation, but rather the healthy operation of a free software ecology.
Community-based distributions as the answer Posted Mar 1, 2006 17:02 UTC (Wed) by smoogen (subscriber, #97) [Link] I think that saying "Free software prospered before ..." should be added with the caveat "in a completely different way than now." Most of the people I knew who were doing Free Software were doing it at universities or in their spare time and the number of people was MUCH MUCH less than is currently doing it. This is because of communication changes (a larger percentage of programmers on the Internet), culture changes (more risk-averse managers feeling ok with non-propietary software), and a lot of other socio/politico/economic changes that have made things the way they are now.
The second caveat is that if Red Hat and Novell were plundered in medieval fashion by some unscrupulous company tomorrow, their programmers put on stakes in the public commons, managers who accepted Free Software in their business publically whipped, etc.. Free Software would survive. It just wouldnt survive in the way it currently does, and very less likely in the way it did in the past. From what one can tell in various other population culture shifts.. people will find some completely new way to subvert the older system using Free Software.
Just NOW fragmenting? Sure... Posted Feb 28, 2006 20:28 UTC (Tue) by elanthis (guest, #6227) [Link] Linux is already pretty fragmented. Different directory locations, custom patches kernels and libcs and compilers, different init systems, different library versions and ABIs, etc.
Getting a binary that runs on multiple Linux distros isn't as easy as it should be.
Getting a script that works properly on multiple Linux distros can also be hard if you touch one of a handful of taboo areas.
Yet, it all still works well enough.
SELinux vs AppArmor isn't breaking or diversing anything. Neither is AIGLX and XGL.
This whole topic is just pointless panicking.
Just NOW fragmenting? Sure... Posted Mar 1, 2006 0:29 UTC (Wed) by bk (guest, #25617) [Link] Getting a binary that runs on multiple Linux distros isn't as easy as it should be.This seems like an irrelevant argument to me. Binary distribution is basically broken. Unless you are a proprietary software vendor (and I don't believe that their priorities should be a free software concern) there is little reason to concentrate on binary distribution. Major distributions are (slowly) converging upon the repository/package-manager modality. There's a master package tree maintained by the distribution (who usually handles compilation and integration) and a suite of tools for end users to utilize that repository. Consequently, there is less and less justification for individual developers or projects to worry about the details of binary packaging. Let the distributions worry about that; after all, they are the experts in how their system works. Furthermore I think it is often (but not necessarily) more secure for users to install software from an authenticated upstream repository as opposed to downloading and installing binary blobs from random websites. That is the Windows way of doing things and it's antiquated and, arguably, technically inferior.
Just NOW fragmenting? Sure... Posted Mar 1, 2006 1:05 UTC (Wed) by cventers (subscriber, #31465) [Link] Exactly. One thing that I always saw as great value in systems likePortage is that a user who uses Portage exclusively simply isn't vulnerable to most things out there. You can mount your CDs noexec, emerge all of your software (which is MD5 hashed [and slowly becoming PGP signed]), etc. And while I'm still one of those punks that uses root for everything under the sun (hey, I'm allowed to because I know my system), I'm glad that distributions like Ubuntu are working to make people regular users on their own systems. Security is fantastic in our source code only world.
Just NOW fragmenting? Sure... Posted Mar 1, 2006 11:43 UTC (Wed) by dmantione (guest, #4640) [Link] Perhaps there exist users that don't want to handle compilers, but dowant to install external software? Being author of such software (Free Pascal compiler) I can say it ain't easy to support a lot of distributions. And we're one of the few projects that can support multiple Linux distributions with a single download, because we do not depend on the compatibility horror that libc is.
Just NOW fragmenting? Sure... Posted Mar 1, 2006 17:13 UTC (Wed) by ewan (subscriber, #5533) [Link] And how many users that don't want to handle compilers find themselvesinstalling your compiler?
Just NOW fragmenting? Sure... Posted Mar 1, 2006 17:26 UTC (Wed) by dmantione (guest, #4640) [Link] Ok, lets test it, you sound like a professional user, which is able toinstall a program from source code. Here is documentation how to compile it from source: http://www.stack.nl/~marcov/buildfaq.pdf ... and the source code: ftp://ftp.freepascal.org/pub/fpc/dist/source-2.0.2 You can find a distribution independend binary distribution here: ftp://ftp.freepascal.org/pub/fpc/dist/i386-linux-2.0.2 ... which one do you prefer? Oh, and you don't want to tell to someone who needs to learn programming that he's going to need to compile Free Pascal from source code to install it.
Just NOW fragmenting? Sure... Posted Mar 1, 2006 19:35 UTC (Wed) by wilck (subscriber, #29844) [Link] As Elanthis already said, the problem not only applies to binaries, but shell scripts as well. Writing an app that correctly installs e.g. rc scripts with dependencies on Red Hat, Suse, and Debian is a nightmare.
While the priorities of proprietary vendors may not be a "free software concern", they are a distribution concern, and they should be. Unfortunately, at the current state of fragmentation, it's often impossible for authors to support more than RedHat and SUSE Enterprise distros, and the rest of the world must see for themselves.
Having everything a user might need in a distibution repository is impossible. Even with Debian's 15000 or so packages you encounter stuff they don't have. In the enterprise market where the distibutions need to _support_ all official packages, there is a strong trend towards "less is more" (compare the package lists for SLES9 and SUSE 9.1, for example).
And please, explain why downloading a binary installer that smoothly integrates a software into your system is "technically inferior" to "configure; make; make install".
Just NOW fragmenting? Sure... Posted Mar 2, 2006 0:23 UTC (Thu) by bk (guest, #25617) [Link] You are missing the point entirely. The goal of developers should not be getting their software into the hands of users but rather into the hands of the distributors. Make your application as easy to package (use autoconf and not some homebrew build system if possible) as possible and let the packagers do their job. Whether it is written in C/C++ or Perl or Ada is irrelevant.And please, explain why downloading a binary installer that smoothly integrates a software into your system is "technically inferior" to "configure; make; make install". If you re-read my original post you'll see that that is precisely the opposite of what I wrote.
Just NOW fragmenting? Sure... Posted Mar 2, 2006 17:42 UTC (Thu) by wilck (subscriber, #29844) [Link] You are right, using official packages from the distribution is always first choice. But...
Being "easy to package" in the way you describe doesn't warrant that a distribution will package an application. Distributors can't package everything, and they make their own choices about what applications and which versions thereof they include. The SELinux/Apparmor example in the original article illustrates this.
Moreover, once a distribution is released, most distributions don't update the packages. If you stick with packages, you are soon forced to either use outdated software or upgrade the entire distribution every few months - or use a 3rd party package. (Talking about "stable" distributions of course. Gentoo or Sid users aren't affected, but they have other problems).
What do you do if your favourite distribution just won't ship the app you like, or sticks with an old version that doesn't have the features you need? Change the distribution? Or build the app from source?
I, at least, prefer a clean 3rd party binary package, and I'd find it highly desirable to have standards would make it possible for skilled 3rd party developers to build clean packages that actually work on different distributions.
A few years ago, that used to be fairly simple. It's getting harder every year. That's the road to fragmentation.
Just NOW fragmenting? Sure... Posted Mar 3, 2006 1:07 UTC (Fri) by bk (guest, #25617) [Link] My broader point was that distributions in general are moving toward a dynamic repository approach (and this is a good thing). The packages available constantly update as software becomes available. Even static commercial distributions (with the eternal exception of Slackware) may even get 3rd party repository support, so that even if you pay for RHEL you can get bleeding edge packages (and void your expensive support contract...).
Just NOW fragmenting? Sure... Posted Mar 3, 2006 17:21 UTC (Fri) by wilck (subscriber, #29844) [Link] Fedora and OpenSuse may have a "dynamic" approach, but the derived enterprise products most probably won't. They are "frozen", and my guess is that a large part of their target customers appreciates that.
Just NOW fragmenting? Sure... Posted Mar 4, 2006 17:01 UTC (Sat) by arafel (subscriber, #18557) [Link] > What do you do if your favourite distribution just won't ship the app> you like, or sticks with an old version that doesn't have the features > you need? Change the distribution? Or build the app from source?
Personally, I use apps in this order:
a) from distribution servers, unless there's a compelling reason to move to a version they don't have, in which case
Using a pre-built binary is something which I almost never do. I think the only non-distro, free software pre-built binaries I have on here are Wine and transcode.
If there are a sufficient number of programs which either aren't available, or I'm fed up with having an old version, I'll migrate distribution. This is one reason why moving back to Debian from Kubuntu is on my list of things to do.
Just NOW fragmenting? Sure... Posted Mar 3, 2006 17:07 UTC (Fri) by KaiRo (subscriber, #1987) [Link] You mean, if I'm developing a new app, and no distributor does (yet) include my package, my project is completely doomed?
Thanks, that's not what I have in mind thinking of an open software community.
In this case, I rather set up some box with a really old distro to compile binaries that are still working on newer systems, and distribute them as tarball or whatever.
And yes, I know what I'm talking about, I'm running build machines for the SeaMonkey project, that has just recently released its first stable version...
Just NOW fragmenting? Sure... Posted Mar 9, 2006 16:15 UTC (Thu) by markhb (guest, #1003) [Link] Furthermore I think it is often (but not necessarily) more secure for users to install software from an authenticated upstream repository as opposed to downloading and installing binary blobs from random websites."Random websites" are one thing, but what of off-the-shelf, shrinkwrapped software? I know you don't think much of proprietary software, but I for one know many people who use their computers regularly for World of Warcraft, or Jumpstart 2nd Grade, or Punch Home Design, none of which I see as likely to be replaced by superior (or even equivalent) FLOSS alternatives in the near-to-midterm future. The lack of binary filesystem consistency is probably a major barrier to greater off-the-shelf availability, and the lack of Linux software on the shelves of Best Buy is yet another reason for home users to view Linux as "on the fringes" for their wants/needs.
This is GOOD(TM) Posted Mar 2, 2006 11:03 UTC (Thu) by hummassa (subscriber, #307) [Link] If it's more difficult to put a binary in every single system, it's moredifficult (to the point of being not really viable) to write effective malware. And this is waaaay good.
Linux fragmenting at last? Give me a break. Posted Feb 28, 2006 20:29 UTC (Tue) by proski (subscriber, #104) [Link] The difference from UNIX fragmentation is that major players in the GNU/Linux field can easily abandon their approach and take the competitor's technology. For example, Novell can abandon AppArmor in favor of SELinux is the former fails to achieve community support. Likewise, Red Hat can ship Xegl if it has better hardware support. Moreover, RedHat can implement AIGLX on top of Xegl and keep using its patched Metacity. In a similar vein, Novell could provide some compatibility layers for the software relying on AppArmor.In the UNIX world, anything like that would involve big money changing hands. That's why UNIX companies kept working on their own software even if it was inferior in some serious aspects.
Linux fragmenting at last? Give me a break. Posted Feb 28, 2006 21:05 UTC (Tue) by smitty_one_each (subscriber, #28989) [Link] >The difference from UNIX fragmentation is that major players in the GNU/Linux field can easily abandon their approach and take the competitor's technology.
Conversely, if everyone used exactly the same thing, we would see
Linux fragmenting at last? Give me a break. Posted Mar 3, 2006 14:26 UTC (Fri) by addw (guest, #1771) [Link] Quite. The main cost of one distribution recognising that another is using better technology (and thus adopting it) is: loss of face.It also means that their users will feel a change - which might involve some pain. I suspect that loss of face is the more important issue, although the second point will be the most often quoted.
_Adequately_ criticised? Not sure. Posted Feb 28, 2006 21:39 UTC (Tue) by linuxbox (subscriber, #6928) [Link] I'd be interested in links to such criticism. So far, I have been unsuccessful in locating in-depth critical analysis of the detailed design decisions of SELinux (security models in TE vs. those supported by other systems, consequences of file labeling, reliance on M4 macros, and others) that would let me feel confident in it.
I do find myself wishing for a more streamlined system, and so far, I have much preferred the other systems (eg, LIDS [but found it not stable] and Grsecrity [my current preference], haven't evaluated Subdomain/AppArmor) to SELinux).
It has occurred me that while may be the ideal system for a certain type of (US government?) customer, it might not be the ideal system for a large class of users. The citations in this article tend to strengthen my impression.
Fear of forking Posted Feb 28, 2006 22:50 UTC (Tue) by adren (guest, #20906) [Link] There is an old article (1999) from Rick Moen on the subject called "Fear of forking" which explains that most forks eventually end up with a merge back to the original project or at least bring some improvements. Examples of such forks are : Unixes, emacs, gcc, glibc etc.
Fear of forking Posted Feb 28, 2006 23:58 UTC (Tue) by Baylink (subscriber, #755) [Link] Indeed.
And while Rick and I don't like each other much this month (:-), he's still one of the 20 smartest people on the Internet, and I think he's right here, as well, as far as his piece applies.
I do, myself, tend to lean towards the guy who said that this is Pointless Panic (which wbagnfarb, BTW); and that the Red Hat guy is just fudslinging.
All The Smart People Don't Work For $YOUR_PET_PROJECT, guy.
Fear of forking Posted Mar 1, 2006 0:26 UTC (Wed) by drag (subscriber, #31333) [Link] I agree...
If this guy was worried about forking then he would be bitching about Redhat working on AIGLX rather then XGLX... which came first and needs work also.
With Apparmor I see it fuffilling a seperate nitch then what I've seen with SELinux. SELinux seems very restrictive, very limiting. I see it as usefull for interent servers and high security enterprise items. Relatively static deployments with highly skilled administrators with the time and budgets to make SELinux work. With AppArmor I see that more for higher security Desktop or Workstation enviroments were a administrator can simply run the profiler or however it works to lock down applications. Then it's easy enough to go and run again and again as applications evolve and roles change.
That and AppArmor was a existing application that Novell bought and GPL'd.
On the flip side why did Redhat buy out Netscape directory services and GFS stuff rather then working on existing items like Lustre or OpenLDAP?
I don't see any problems here.
And anyways in the long run AIGLX and XGLX are doomed. They are part of a evolution from 2-D desktop to 3-D one. It's needed and the work that both companies are putting into them is required and will probably be used to provide a 3rd more advanced/evolved X server.
It's probably the same thing with SELinux and AppArmor.. I can see these things evolving and lessons and code gained from both developements will provide a superior and more evolved solution in the future.
I mean that all of this stuff is very cutting edge.
Essentially with XGL-related items your taking networkable graphic display system and giving it full 3D acceleration, while maintaining backward compatability and a comfortable upgrade path for end users and developers.. and in the other case your trying make a Mandatory Access Control system and trying to make it usefull for the mainstream.
Nobody outside the Free/Open Source Software community is trying to do things like this. I don't think that anybody outside the Free/Open Source community is even capable of doing something like this.
And how it works in the community in the past is that you talk with your code. If you have a fantastic idea for the kernel, for instance, you can't just talk the Kernel developers into doing what you want.. You have to prove that your idea is superior to what they currently have and that is done with patches.
So in the case of both these companies they will choose one or another or a 3rd fork of either or both projects... Or the community will. Neither Novell or Redhat can hope to survive on their own, they absolutely need the support of programmers and such that operate completely outside their control. Either way I don't see a huge division forming.
Fear of forking Posted Mar 1, 2006 20:05 UTC (Wed) by rickmoen (subscriber, #6943) [Link] Jay, you're quite welcome to flatter me any time, but in truth I'm just an easily confused astygmatic Scandihoovian with a big mouth and a Web site. And thank you for mentioning that old essay, which does (still) seem a propos. All the Best,
Linux fragmenting at last? Posted Mar 1, 2006 1:13 UTC (Wed) by cventers (subscriber, #31465) [Link] I think the idea that Linux is forking is rather silly. The fact that thesystem is made up of little tiny pieces means that it is inherently forky. It's up to the distributors to play fork. If the distributors don't differentiate, there's no reason to choose one over another. What holds it together, I think, is rather ironic - it's ability to fork. Since it's a part of the very nature of Linux, it just works. The important pieces - glibc and the kernel - stay in tact. Glibc I don't know a lot about, but I'm betting its because doing a libc isn't fun to a lot of people. (And besides, when libc exists to uphold a standard, forking seems kind of silly). As for the kernel, Linus has the right personality and the right attitude. And anyone who gets too far from home either ends up coming back or quitting. The fact that there's really very little in terms of management structure - just anyone can walk in and say "here's my code", needing nothing but good ideas and a solid implementation, well, it's really a blessing.
Linux fragmenting at last? Posted Mar 1, 2006 1:15 UTC (Wed) by erich (subscriber, #7127) [Link] It's way too early to talk about fragmentation yet.Noone has proven that these things can't just coexist. That one Distribution could support both SELinux and AppArmor, for example. or that AIGLX can't run on top of Xgl. These are just different approaches to solve outstanding issues (higher security, better graphics, ...)
The real issues I see here, is that these projects are often developed behind closed doors. There were many people complaining about the way Novell has handled the Xgl development, for example.
I've just these days blogged about AppArmor and SELinux:
But here, too, development is done largely behind closed doors at e.g. Tresys, which is just very unhealthy.
Linux fragmenting at last? Posted Mar 1, 2006 11:23 UTC (Wed) by nix (subscriber, #2304) [Link] I don't understand. What's `mostly useless' about AppArmor? The largest problem that I can see is the absence of per-user profiles (fixes planned but tricky). It certainly seems useful to *me*.
Linux fragmenting at last (blog post) Posted Mar 1, 2006 17:58 UTC (Wed) by linuxbox (subscriber, #6928) [Link] Some interesting points in the blog post. Have you also worked with Grsecurity or RSBAC?
Linux fragmenting at last (blog post) Posted Mar 2, 2006 13:14 UTC (Thu) by erich (subscriber, #7127) [Link] I've used grsecurity, but it's ACLs were almost as bad to setup.And they are pretty hard to define properly. E.g. it makes a difference between calling "somescript.pl" and "perl somescript.pl"
Which totally sucks, but applies to all languages with runtime environments, including Perl, Python, Java, Mono.
"Transitions" in SELinux are a really nice thing, most other ACL systems are lacking. and while I personally have little use for MCS and MLS (Multiple class security, multiple level security), they make perfect sense for corporate environments with multiple "trustedness" user levels.
Linux fragmenting at last (blog post) Posted Mar 3, 2006 4:53 UTC (Fri) by ab (subscriber, #788) [Link] Still, what about RSBAC? It is far richer model than Grsecurity and comparable (even richer) with SELinux, yet easier to setup.
Linux fragmenting at last? Posted Mar 1, 2006 3:06 UTC (Wed) by job (guest, #670) [Link] I haven't tried AppArmor, but I have made a serious effort to understand SELinux. I sort of did get it mostly working, but I never went so far as to use it in a production system. It's extremely complex and touches almost every part of the code. It's like it was designed by committee.
Most people only use it as a process based ACL system anyway, making the complexity useless. If that's what you want you'd better go with RSBAC, grsecurity or any of a dozen such systems. They are much simpler to understand and implement. It's not obvious which solution is better.
Oh, and you forget(?) the most important flame source of them all: KDE vs Gnome. If Novell hadn't acquired Ximian, it would be a much more KDEsque desktop, diverging from Red Hat on another important point.
Some of these chasms that take a lot of time to unite again, if ever. KDE and Gnome finally shares some libraries, but they still reinvent most software. This despite only one of them actually turned out to be the object oriented desktop both set out to be.
Linux fragmenting at last? Posted Mar 1, 2006 4:47 UTC (Wed) by ruin8tr (guest, #16593) [Link] Some of these chasms that take a lot of time to unite again, if ever. KDE and Gnome finally shares some libraries, but they still reinvent most software. This despite only one of them actually turned out to be the object oriented desktop both set out to be. Which one?
Whats the problem? Posted Mar 1, 2006 6:15 UTC (Wed) by b7j0c (subscriber, #27559) [Link] If the codebases used by competing distro vendors is licensed adequately, the market will choose the individual codebases they prefer, and someone out there will put them together into yet-another-distro.s.
Not while the source is open... Posted Mar 1, 2006 10:13 UTC (Wed) by trithemius (guest, #18658) [Link] Comparing the Linux world to the old UNIX world falls down in one major area: Licensing. The old UNIX world saw companies jealously hoarding their expertise and sources. Even if someone wanted to try to pull a best-of-breed system, they simply couldn't. If a customer was happy on a version of the software they were still forced to upgrade when support for their version was dropped (even if they were willing to buy a support contract!)
Contrast that with the Linux world where no matter what a vendor does with any major part of their system is an open book to everyone - customers and competitors alike. You like something a 'competing' distro patched into their kernel? Apply the same patch. A desktop competitor you secretly admire pulled an architectural trick that makes you envious, and you can crawl their system to your heart's content - imitation being the sincerest form of flattery. Don't want to be stuck paying $$ for upgrades for systems that are work damn fine and don't want to be changed? Plenty of people are willing to support what is transparent - for the right price of course.
No matter what idealogical direction you're coming to the party from, the bottom line is the same: The walls that were built in the UNIX world cannot be built here.
Nothing to see here. Move along.
Linux fragmenting at last? Posted Mar 1, 2006 10:35 UTC (Wed) by nix (subscriber, #2304) [Link] Well, Crispin said last night (in the pub after a thoroughly pleasant arranged-at-the-last-minute talk on AppArmor) that submission of the kernel parts to the mainline is imminent, probably 'next month' (i.e. March given that he said this very late on Feb 28 ;) ), and that packaging the userspace parts up more conventionally is also desirable.
Anyone willing to do it? (I might well do it if nobody else can find the time.)
(One other point is that AppArmor is wonderfully easy to configure. Not only are the profiles easy to edit but you hardly ever need to edit them anyway because the automatic learning tools are so flexible.)
(As an aside, SELinux and AppArmor use the *same hooks* in the kernel, the LSM hooks, and those hooks were designed with both systems in mind from the start. So this is hardly a sign of catastrophic kernel fragmentation.)
Linux fragmenting at last? Posted Mar 1, 2006 10:37 UTC (Wed) by nix (subscriber, #2304) [Link] Oh, and finally, AppArmor predated SELinux by a considerable time (I think AppArmor started out in 1999?), so if anyone is to blame for a fork it would be SELinux.
But as a fork isn't happening, no 'blame' need be assigned.
Linux fragmenting at last? Posted Mar 1, 2006 12:26 UTC (Wed) by nsoranzo (subscriber, #34668) [Link] Oh, and finally, AppArmor predated SELinux by a considerable time (I think AppArmor started out in 1999?), so if anyone is to blame for a fork it would be SELinux.With the difference that SELinux was GPL from the start, while AppArmor wasn't at that time.
Linux fragmenting at last? Posted Mar 1, 2006 20:24 UTC (Wed) by nix (subscriber, #2304) [Link] Yes, but it would still be peculiar to point to the earlier implementation as signs of fragmentation. Non-free or not the AppArmor hackers didn't see into the future and decide to make something extra-different to that SELinux thing ;)
Linux fragmenting at last? Posted Mar 2, 2006 7:37 UTC (Thu) by danieldk (guest, #27876) [Link] Anyone willing to do it? (I might well do it if nobody else can find the time.) FWIW, packages for Slackware Linux are available from: http://danieldk.org/apparmor/
Linux fragmenting at last? Posted Mar 4, 2006 18:12 UTC (Sat) by job (guest, #670) [Link] Interesting. What has the AppArmor developers to say about the LSM hook critique voiced by the grsec and RSBAC developers?
Linux fragmenting at last? Posted Mar 5, 2006 15:01 UTC (Sun) by nix (subscriber, #2304) [Link] I didn't ask, not being aware until now of the existence of said critique.
Got any pointers.
Linux fragmenting at last? Posted Mar 10, 2006 19:40 UTC (Fri) by PaXTeam (subscriber, #24616) [Link] http://www.grsecurity.net/lsm.phphttp://www.rsbac.org/documentation/why_rsbac_does_not_use...
Standard behavior... Posted Mar 1, 2006 17:33 UTC (Wed) by gmaxwell (subscriber, #30048) [Link] This is just standard behavior for any Linux company which has gone anywhere near Novell. Caldera played the same games with their own in house enhancement to Linux. As is the case with anyone else, some were widely adopted, some were not... The things that Caldera which were in direct opposition to the trends in the rest of the community were ignored, and the same will be true of these recent developments by Novell.
Money can by resources. But obtaining control is actually a lot more complex than simple resources.
Standard behavior... Posted Mar 1, 2006 20:25 UTC (Wed) by nix (subscriber, #2304) [Link] Um, if AppArmor is in-house, why does it have public devel lists, publically visible source code and so on?
It *was* a lot more in-house than it is now. I'd say it's in transition.
Linux fragmenting at last? Posted Mar 2, 2006 5:14 UTC (Thu) by stock (guest, #5849) [Link] stick to open source and all of the above goes away. This may not alwaysbe possible, but at least try to use open source for all the public internet and network services on your Linux server.
Fragmenting or choice? Posted Mar 3, 2006 17:18 UTC (Fri) by KaiRo (subscriber, #1987) [Link] Interesting, we have long-lived different Linux desktop environment project, mainly KDE and GNOME, along withg a few others, we have different browser project with even different rendering backends, see Firefox, Konqueror, SeaMonkey, etc. (not to mention proprietary variants), we have lots of different applications for mail, media, and a plethora of other things.
And we all keep praising that as a good thing that open source brings, having the choice of what to use!
So, now we have that choice in security frameworks and 3D graphics support as well, what's the difference? Just that the two major distributors are putting work into different solutions and that a developer of one of them is complaining about it? Don't sound new to me, we had that with KDE vs. GNOME some while back as well, before they decided to work together via freedesktop.org...
No fragmentation, just an interweaving... Posted Mar 7, 2006 0:18 UTC (Tue) by filker0 (guest, #31278) [Link] There was a time when a corporate ethernet might have Novell, IP, Decnet, appleTalk, or IBM LanMan running, but in many cases, they had to run over separate wires because even if the protocol supported typed packets, a lot of systems where not using them. In the old days of Unix when the two dominantflavors were BSD and SysV, there were systems that had multiple "universes". Some programs ran under the SysV universe, others under the BSD universe. A user could select their universe in the shell, but if they ran an application that used the other universe, it would still run, as it was tagged to use a specific set of semantics on the system calls. The hooks used by SELinux and AppArmor are the same. I can see a future where, either through virtualization (Xen or some other system) or simply having an overall policy or profile, both sets of semantics might coexist on the same system at the same time. This will happen if the community sees a need for it. My guess is that one of the security systems would control the layer used by the other, but I have not studied either extensively. In the same way, even though Xgl and AIGLX use different approaches, eventually they'll support the same hardware. I don't see how having applications that depend on either one excludes the use of the other on the same system. If they conflict at a hardware level, some motivated group of developers will figure out a way to make them coexist, or to build a veineer for one that looks, to an application, like the other. Once again, there will be peace in the bazzar, and the veterans of the old code wars will sit at the bar talking about how it was in the old days, and how much better one was than the other before they went and bloated it to appease those other miscreants who didn't know a deferred reference from an atomic operation. It is not fragmentation. New approaches arise, compete, blend, and then return. The fragementation in the Unix world happened because the code was proprietary, and vendors were not willing to give away the code to those unique kernel features they saw as competitive advantages that, for the most part, helped them sell their proprietary hardware. Each hardware platform was its own little world, and for a time, the vendors got away with it. That is not the model of the Linux corporate world. Uniqueness comes from packaging and support. So I don't think that Novell and Red Hat's current spat over SELinux/AppArmor and Xgl and AIGLX is a sign of a fragmentation any more than Gnome/KDE is. Now, then, emacs vs. vi is another matter entirely, and is destined to destroy the world as we know it. :-)
AIGLX vs. Xgl Posted Mar 8, 2006 14:36 UTC (Wed) by daenzer (✭ supporter ✭, #7050) [Link] Let me point out that the sentence 'AIGLX could work on top of Xgl' makes no sense. Xgl has supported accelerated indirect GLX (as have some proprietary GLX implementations) for a long time (way before Novell took its development behind closed doors for a while), in fact I believe it was one of David's main motivations to start working on Xgl. What is currently referred to as 'AIGLX' is not really a new concept but just extending the XFree86/X.org DDX with the capability of accelerated indirect GLX, which has been talked about for years but only now with GLX based compositing managers has become important enough to actually be done (but will be useful for other applications as well).
All of this is based on open protocols (X11, GLX, the Composite extension, ...) and APIs (OpenGL, ...) that are explicitly designed for interoperability, so there's definitely very little if any risk for fragmentation. Just good old choice, with all its (dis)advantages. :)
Hope this helps clear up some confusion.
|
|||||||||||||