All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: jjohansen@suse.de, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [AppArmor 00/45] AppArmor security module overview
Date: Fri, 26 Oct 2007 14:13:58 -0700	[thread overview]
Message-ID: <20071026141358.38342c0f@laptopd505.fenrus.org> (raw)
In-Reply-To: <200710262244.57147.agruen@suse.de>

On Fri, 26 Oct 2007 22:44:56 +0200
Andreas Gruenbacher <agruen@suse.de> wrote:

> On Friday 26 October 2007 16:37, Arjan van de Ven wrote:
> > In addition, I'd like to ask you to put a file in Documentation/
> > somewhere that describes what AppArmor is intended security
> > protection is (it's different from SELinux for sure for example);
> > by having such a document for each LSM user, end users and distros
> > can make a more informed decision which module suits their
> > requirements... and it also makes it possible to look at the
> > implementation to see if it has gaps to the intent, without getting
> > into a pissing contest about which security model is better; but
> > unless the security goals are explicitly described that's a trap
> > that will keep coming back... so please spend some time on getting
> > a good description going here..
> 
> Hmm, I agree that it makes sense to give a short overview of each
> LSM. A description of the AppArmor model and implementation can be
> found in the directory that John referred to actually. I'm unsure how
> much of that makes sense under Documentation/ -- what do you think? 
> 
>  http://forgeftp.novell.com/apparmor/LKML_Submission-Oct-07/techdoc.pdf
> 
> I guess actual end user information doesn't belong in the kernel
> sources; that really seems wrong.
> 

My main concern for now is a description of what it tries to protect
against/in what cases you would expect to use it. THe reason for asking
this explicitly is simple: Until now the LSM discussions always ended
up in a nasty mixed up mess around disagreeing on the theoretical model
of what to protect against and the actual implementation of the threat
protection. THe only way I can think of to get out of this mess is to
have the submitter of the security model give a description of what his
protection model is (and unless it's silly, not argue about that), and
then only focus on how the code manages to achieve this model, to make
sure there's no big gaps in it, within its own goals/reference.

On the first part (discussion of the model) I doubt we can get people
to agree, that's pretty much phylosophical... on the second part (how
well the code/design lives up to its own goals) the analysis can be
objective and technical.


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

  reply	other threads:[~2007-10-26 21:18 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-26  6:40 [AppArmor 00/45] AppArmor security module overview jjohansen
2007-10-26  6:40 ` [AppArmor 01/45] Pass struct vfsmount to the inode_create LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 02/45] Pass struct path down to remove_suid and children jjohansen
2007-10-26  6:40 ` [AppArmor 03/45] Add a vfsmount parameter to notify_change() jjohansen
2007-10-26  6:40 ` [AppArmor 04/45] Pass struct vfsmount to the inode_setattr LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 05/45] Add struct vfsmount parameter to vfs_mkdir() jjohansen
2007-10-26  6:40 ` [AppArmor 06/45] Pass struct vfsmount to the inode_mkdir LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 07/45] Add a struct vfsmount parameter to vfs_mknod() jjohansen
2007-10-26  6:40 ` [AppArmor 08/45] Pass struct vfsmount to the inode_mknod LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 09/45] Add a struct vfsmount parameter to vfs_symlink() jjohansen
2007-10-26  6:40 ` [AppArmor 10/45] Pass struct vfsmount to the inode_symlink LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 11/45] Pass struct vfsmount to the inode_readlink " jjohansen
2007-10-26  6:40 ` [AppArmor 12/45] Add struct vfsmount parameters to vfs_link() jjohansen
2007-10-26  6:40 ` [AppArmor 13/45] Pass the struct vfsmounts to the inode_link LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 14/45] Add a struct vfsmount parameter to vfs_rmdir() jjohansen
2007-10-26  6:40 ` [AppArmor 15/45] Pass struct vfsmount to the inode_rmdir LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 16/45] Call lsm hook before unhashing dentry in vfs_rmdir() jjohansen
2007-10-26  6:40 ` [AppArmor 17/45] Add a struct vfsmount parameter to vfs_unlink() jjohansen
2007-10-26  6:40 ` [AppArmor 18/45] Pass struct vfsmount to the inode_unlink LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 19/45] Add struct vfsmount parameters to vfs_rename() jjohansen
2007-10-26  7:37   ` Al Viro
2007-10-26 18:23     ` John Johansen
2007-10-26 20:33       ` Al Viro
2007-10-26  6:40 ` [AppArmor 20/45] Pass struct vfsmount to the inode_rename LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 21/45] Add a struct vfsmount parameter to vfs_setxattr() jjohansen
2007-10-26  6:40 ` [AppArmor 22/45] Pass struct vfsmount to the inode_setxattr LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 23/45] Add a struct vfsmount parameter to vfs_getxattr() jjohansen
2007-10-26  6:40 ` [AppArmor 24/45] Pass struct vfsmount to the inode_getxattr LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 25/45] Add a struct vfsmount parameter to vfs_listxattr() jjohansen
2007-10-26  6:40 ` [AppArmor 26/45] Pass struct vfsmount to the inode_listxattr LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 27/45] Add a struct vfsmount parameter to vfs_removexattr() jjohansen
2007-10-26  6:40 ` [AppArmor 28/45] Pass struct vfsmount to the inode_removexattr LSM hook jjohansen
2007-10-26  6:40 ` [AppArmor 29/45] Fix __d_path() for lazy unmounts and make it unambiguous jjohansen
2007-10-26  6:40 ` [AppArmor 30/45] Make d_path() consistent across mount operations jjohansen
2007-10-26  6:40 ` [AppArmor 31/45] Add d_namespace_path() to compute namespace relative pathnames jjohansen
2007-10-26  6:40 ` [AppArmor 32/45] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames jjohansen
2007-10-26 11:30   ` Miklos Szeredi
2007-10-26 11:45     ` Miklos Szeredi
2007-10-26 18:49     ` John Johansen
2007-10-26 20:24     ` Andreas Gruenbacher
2007-10-26 20:58       ` Miklos Szeredi
2007-10-26 21:56         ` Andreas Gruenbacher
2007-10-26  6:40 ` [AppArmor 33/45] Pass struct file down the inode_*xattr security LSM hooks jjohansen
2007-10-26  6:40 ` [AppArmor 34/45] Factor out sysctl pathname code jjohansen
2007-10-26  9:24   ` James Morris
2007-10-26  6:40 ` [AppArmor 35/45] Allow permission functions to tell between parent and leaf checks jjohansen
2007-10-26 12:32   ` Stephen Smalley
2007-10-26 18:26     ` John Johansen
2007-10-26  6:41 ` [AppArmor 36/45] Export audit subsystem for use by modules jjohansen
2007-10-26  6:41 ` [AppArmor 37/45] AppArmor: Main Part jjohansen
2007-10-26  6:41 ` [AppArmor 38/45] AppArmor: Module and LSM hooks jjohansen
2007-10-26  6:41 ` [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching jjohansen
2007-10-26  6:41 ` [AppArmor 40/45] AppArmor: all the rest jjohansen
2007-10-26  6:41 ` [AppArmor 41/45] add simple network toggles to apparmor jjohansen
2007-10-26  6:41 ` [AppArmor 42/45] Add AppArmor LSM to security/Makefile jjohansen
2007-10-26  6:41 ` [AppArmor 43/45] Switch to vfs_permission() in do_path_lookup() jjohansen
2007-10-26  6:41 ` [AppArmor 44/45] Switch to vfs_permission() in sys_fchdir() jjohansen
2007-10-26  6:41 ` [AppArmor 45/45] Fix file_permission() jjohansen
2007-10-26  7:04 ` [AppArmor 00/45] AppArmor security module overview John Johansen
2007-10-26 14:37 ` Arjan van de Ven
2007-10-26 18:34   ` John Johansen
2007-10-26 20:15     ` Arjan van de Ven
2007-10-26 20:44   ` Andreas Gruenbacher
2007-10-26 21:13     ` Arjan van de Ven [this message]
2007-10-26 21:24       ` Andreas Gruenbacher
2007-10-26 22:16       ` Crispin Cowan
2007-10-26 22:23         ` Arjan van de Ven
2007-10-27 20:47   ` Christoph Hellwig
2007-10-28 14:25     ` Andreas Gruenbacher
  -- strict thread matches above, loose matches on Subject: below --
2007-05-14 11:06 jjohansen
2007-05-14 13:50 ` John Johansen

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=20071026141358.38342c0f@laptopd505.fenrus.org \
    --to=arjan@infradead.org \
    --cc=agruen@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=jjohansen@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.