linux-kernel - Re: [AppArmor 00/44] AppArmor security module overview

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Jun 2007 17:11:14 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	John Johansen <jjohansen@...e.de>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 00/44] AppArmor security module overview

On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen <jjohansen@...e.de> wrote:
> 
> > > 
> > > so...  where do we stand with this?  Fundamental, irreconcilable
> > > differences over the use of pathname-based security?
> > > 
> > There certainly seems to be some differences of opinion over the use
> > of pathname-based-security.
> 
> I was refreshed to have not been cc'ed on a lkml thread for once.  I guess
> it couldn't last.
> 
> Do you agree with the "irreconcilable" part?  I think I do.
> 
> I suspect that we're at the stage of having to decide between
> 
> a) set aside the technical issues and grudgingly merge this stuff as a
>    service to Suse and to their users (both of which entities are very
>    important to us) and leave it all as an object lesson in
>    how-not-to-develop-kernel-features.
> 
>    Minimisation of the impact on the rest of the kernel is of course
>    very important here.
> 
> versus
> 
> b) leave it out and require that Suse wear the permanent cost and
>    quality impact of maintaining it out-of-tree.  It will still be an
>    object lesson in how-not-to-develop-kernel-features.
>...

versus

c) if [1] AppArmor is considered to be something that wouldn't 
   be merged if it wasn't already widely deployed by Suse: leave it out, 
   work on an ideal solution [2], and let Suse wear the one-time cost
   of migrating their users to the ideal solution

One important point is that if AppArmor gets merged there will be much 
more distribution support for it, and many people on !Suse will start 
using it.

I'm not claiming to understand the technical details, but from both 
slightly reading over the previous discussions and the "What are the 
advantages of AppArmor over SELinux?" section in the AppArmor FAQ [3] my 
impression is that a main advantage of AppArmor are more user friendly 
userspace tools. Therefore, if [1] AppArmor is considered technically 
inferior to SELinux, it might still become more popular than SELinux 
simply because it's easier to use - and although it's technically 
inferior.

cu
Adrian

[1] note the "if"
[2] could be, but not necessarily, SELinux
[3] http://developer.novell.com/wiki/index.php/Apparmor_FAQ

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/