On Tue, 2008-09-23 at 11:56 -0400, G. Matthew Rice wrote: > A few metrics for you, too: > google search results: > "AppArmor" - about 300,000 hits > "SELinux" - about 2,590,000 hits > "Tomoyo" - about 1,400,000 hits (you'll have to do the search to find out > why :))
We'll know more by the next revision (in 2+ years). > Can anyone speak to the future of AppArmor, though? For example, this just > came out today: > http://etbe.coker.com.au/2008/08/23/apparmor-is-dead/ Check out the AppArmor's own maintainer/originator comments to that very blog post. Also see the subsequent blog entry. One thing that gets old is the "oh, we should have one approach." Not only is there a loadable security module (LSM) framework, not only is there a "working group" for its API where people can "sell their views" and "put their code where their mouth is," but saying SELinux is a single approach and that's bad is like saying NetFilter is a single approach and that is bad. Anyone can write tools build around NetFilter in the kernel. Yes, most people use iptables and the iptools, but you do not have to. You can plug into NetFilter. Likewise, SELinux is a facility, just like NetFilter. A lot of people, especially in and outside of Red Hat, are extremely open to some "cookbook" tools and rules that address many things outside what has been developed. Same goes for the LSM if you don't want to deal with SELinux. The problem is code, implementations, maintainers and related effort. Red Hat has put its coders where its mouth is, and others have joined. IBM obtained EAL-4 with 3 specialties in a fairly generic server install of RHEL 5 -- totally unheard of before in a generic client/server platform. Red Hat works with upstream, heeds the ruling of those project leaders (who do not always work for Red Hat, despite common rhetoric at times, even if Red Hat has the majority of developers), and sides with upstream over customers in many cases. Not because it's "right," but because it's "sustainable." A lot of the other options don't even conform to the LSM API and their maintainers work outside it. Vendors then fork from upstream and it becomes a serious effort. Forking temporarily in updates while you work with upstream is one thing, although it should be avoided by default for "sustainability." Forking because upstream won't do what you want really sets your project up for a fall. > I don't think that I can really answer this with specifics. Like religion, I > generally don't query individuals on their preferred distro, editor, > programming language, etc. > The main way for SUSE users to get more attention is to speak up during the > objective review processes and participate in the JTAs. I encourage you to > invite anyone that you know to join this list, too. > That said, our most active Technical Advisory Committee meetings are > generally in Germany and I have a feeling that a bunch of them are SUSE > users. In fact, that's where the AppArmor topic first came up for the 303 > exam. This is the same argument that is thrown at security implementations that don't even work with LSM. If you want it to work with the LSM API, work with the LSM maintainers. Or what most people are doing is just working with SELinux. Not merely just rules for the reference implementation, but getting projects to think about SELinux in their packaging and deployment in the first place is really the attitude to have. More and more projects are starting to agree. -- Bryan J Smith Professional, Technical Annoyance mailto:[EMAIL PROTECTED] http://www.linkedin.com/in/bjsmith ------------------------------------------------------------- Fission Power: An Inconvenient Solution _______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
