linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Crispin Cowan <crispin@novell.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	John Johansen <jjohansen@suse.de>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [AppArmor 00/44] AppArmor security module overview
Date: Wed, 27 Jun 2007 14:06:04 -0700	[thread overview]
Message-ID: <4682D13C.6060107@novell.com> (raw)
In-Reply-To: <20070627151114.GM1094@stusta.de>

Adrian Bunk wrote:
> On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
>   
>> Do you agree with the "irreconcilable" part?  I think I do. 
I am hoping for a reconciliation where the people who don't like
AppArmor live with it by not using it. AppArmor is not intended to
replace SELinux, it is intended to address a different set of goals.

>> 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
>   
We argue that the proposed patch is a viable solution for providing
AppArmor functionality. We would be happy for specific suggestions on
how to make it better.

> 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.  
AppArmor's advantages come from the model, not the tools. AppArmor is
not inferior to SELinux, it is different than SELinux. Neither can
replace the other without horrid kludges.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
	AppArmor Chat: irc.oftc.net/#apparmor


  reply	other threads:[~2007-06-27 21:06 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-26 23:07 [AppArmor 00/44] AppArmor security module overview jjohansen
2007-06-26 23:07 ` [AppArmor 01/44] Pass struct vfsmount to the inode_create LSM hook jjohansen
2007-06-30  9:29   ` Christoph Hellwig
2007-07-03 22:28     ` Andreas Gruenbacher
2007-06-26 23:07 ` [AppArmor 02/44] Pass struct path down to remove_suid and children jjohansen
2007-06-26 23:07 ` [AppArmor 03/44] Add a vfsmount parameter to notify_change() jjohansen
2007-06-26 23:08 ` [AppArmor 04/44] Pass struct vfsmount to the inode_setattr LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 05/44] Add struct vfsmount parameter to vfs_mkdir() jjohansen
2007-06-26 23:08 ` [AppArmor 06/44] Pass struct vfsmount to the inode_mkdir LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 07/44] Add a struct vfsmount parameter to vfs_mknod() jjohansen
2007-06-26 23:08 ` [AppArmor 08/44] Pass struct vfsmount to the inode_mknod LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 09/44] Add a struct vfsmount parameter to vfs_symlink() jjohansen
2007-06-26 23:08 ` [AppArmor 10/44] Pass struct vfsmount to the inode_symlink LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 11/44] Pass struct vfsmount to the inode_readlink " jjohansen
2007-06-26 23:08 ` [AppArmor 12/44] Add struct vfsmount parameters to vfs_link() jjohansen
2007-06-26 23:08 ` [AppArmor 13/44] Pass the struct vfsmounts to the inode_link LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 14/44] Add a struct vfsmount parameter to vfs_rmdir() jjohansen
2007-06-26 23:08 ` [AppArmor 15/44] Pass struct vfsmount to the inode_rmdir LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 16/44] Call lsm hook before unhashing dentry in vfs_rmdir() jjohansen
2007-06-26 23:08 ` [AppArmor 17/44] Add a struct vfsmount parameter to vfs_unlink() jjohansen
2007-06-26 23:08 ` [AppArmor 18/44] Pass struct vfsmount to the inode_unlink LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 19/44] Add struct vfsmount parameters to vfs_rename() jjohansen
2007-06-26 23:08 ` [AppArmor 20/44] Pass struct vfsmount to the inode_rename LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 21/44] Add a struct vfsmount parameter to vfs_setxattr() jjohansen
2007-06-26 23:08 ` [AppArmor 22/44] Pass struct vfsmount to the inode_setxattr LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 23/44] Add a struct vfsmount parameter to vfs_getxattr() jjohansen
2007-06-26 23:08 ` [AppArmor 25/44] Add a struct vfsmount parameter to vfs_listxattr() jjohansen
2007-06-26 23:08 ` [AppArmor 26/44] Pass struct vfsmount to the inode_listxattr LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 27/44] Add a struct vfsmount parameter to vfs_removexattr() jjohansen
2007-06-26 23:08 ` [AppArmor 28/44] Pass struct vfsmount to the inode_removexattr LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 29/44] Fix __d_path() for lazy unmounts and make it unambiguous jjohansen
2007-06-26 23:08 ` [AppArmor 30/44] Make d_path() consistent across mount operations jjohansen
2007-06-26 23:08 ` [AppArmor 32/44] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames jjohansen
2007-06-28 16:12   ` James Morris
2007-06-28 18:15     ` Andreas Gruenbacher
2007-07-03 13:49       ` Stephen Smalley
2007-07-03 20:01         ` Andreas Gruenbacher
2007-06-26 23:08 ` [AppArmor 33/44] Pass struct file down the inode_*xattr security LSM hooks jjohansen
2007-06-26 23:08 ` [AppArmor 34/44] Factor out sysctl pathname code jjohansen
2007-06-26 23:08 ` [AppArmor 35/44] Allow permission functions to tell between parent and leaf checks jjohansen
2007-06-26 23:08 ` [AppArmor 36/44] Export audit subsystem for use by modules jjohansen
2007-06-26 23:08 ` [AppArmor 37/44] AppArmor: Main Part jjohansen
2007-06-26 23:08 ` [AppArmor 38/44] AppArmor: Module and LSM hooks jjohansen
2007-06-26 23:08 ` [AppArmor 39/44] AppArmor: Profile loading and manipulation, pathname matching jjohansen
2007-06-26 23:08 ` [AppArmor 40/44] AppArmor: all the rest jjohansen
2007-06-26 23:08 ` [AppArmor 41/44] Add AppArmor LSM to security/Makefile jjohansen
2007-06-26 23:08 ` [AppArmor 42/44] Switch to vfs_permission() in do_path_lookup() jjohansen
2007-06-26 23:08 ` [AppArmor 43/44] Switch to vfs_permission() in sys_fchdir() jjohansen
2007-06-26 23:08 ` [AppArmor 44/44] Fix file_permission() jjohansen
2007-06-26 23:52 ` [AppArmor 00/44] AppArmor security module overview Andrew Morton
2007-06-27  2:24   ` John Johansen
2007-06-27  2:47     ` Andrew Morton
2007-06-27  6:43       ` John Johansen
2007-06-27 15:11       ` Adrian Bunk
2007-06-27 21:06         ` Crispin Cowan [this message]
2007-06-27 21:29           ` Sean
2007-06-27 22:46             ` Crispin Cowan
2007-06-27 23:05               ` David Miller
2007-06-28  0:27                 ` Casey Schaufler
2007-06-28  0:34                   ` David Miller
2007-06-28 10:23                   ` Alan Cox
2007-06-28 13:50                   ` Bill O'Donnell
2007-06-28 11:27                 ` Tilman Schmidt
2007-06-28 12:48                   ` Adrian Bunk
2007-06-27 22:41         ` Andreas Dilger
2007-07-02 16:45         ` Eric W. Biederman
2007-07-02 19:31           ` Casey Schaufler
2007-07-02 20:15             ` Christoph Hellwig
2007-07-02 21:09               ` Casey Schaufler
2007-07-03 16:33               ` Andreas Gruenbacher
2007-06-29 18:06       ` Pavel Machek
2007-07-03  6:20       ` Dave Jones
2007-06-27 10:58     ` Kyle Moffett
2007-06-27 13:37       ` Andreas Gruenbacher
2007-06-27  0:32 ` [AppArmor 24/44] Pass struct vfsmount to the inode_getxattr LSM hook jjohansen
2007-06-27  0:32 ` [AppArmor 31/44] Add d_namespace_path() to compute namespace relative pathnames jjohansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4682D13C.6060107@novell.com \
    --to=crispin@novell.com \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@stusta.de \
    --cc=jjohansen@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).