linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: David Miller <davem@davemloft.net>, crispin@novell.com
Cc: seanlkml@sympatico.ca, bunk@stusta.de, akpm@linux-foundation.org,
	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 17:27:17 -0700 (PDT)	[thread overview]
Message-ID: <350078.43404.qm@web36601.mail.mud.yahoo.com> (raw)
In-Reply-To: <20070627.160535.71552808.davem@davemloft.net>


--- David Miller <davem@davemloft.net> wrote:

> From: Crispin Cowan <crispin@novell.com>
> Date: Wed, 27 Jun 2007 15:46:57 -0700
> 
> > But we do not want to prevent other people from using SELinux if it
> > suits them. Linux is about choice, and that is especially vital in
> > security. As Linus himself observed when LSM was started, there are a
> > lot of security models, they have various strengths and weaknesses, and
> > often are not compatible with each other. That is why it is important
> > that LSM persist, that SELinux not be the only in-tree user of LSM, and
> > why we think AppArmor should be included upstream, so that non-SUSE
> > users can also use AppArmor if it suits them.
> 
> Anyone can apply the apparmour patch to their tree, they get the
> choice that way.  Nobody is currently prevented from using apparmour
> if they want to, any such suggestion is pure rubbish.

The exact same argument was made prior to SELinux going upstream.
Look, if you can't be right, try at least to be original.

> It is even more incredulious to imply that just by having apparmour
> in the upstream kernel all the userland bits will magically appear
> on every user's distribution.

Just like all the SELinux userland magically appeared in everyone's
distribution? Nope, didn't happen.

> Give me a break.

No. You are out of line and spewing ignorance.

> What you get by the code going into the upstream kernel tree is that
> it a) adds some pseudo legitimacy to AppArmour (which I don't
> personally think is warranted) and b) gets the work of keeping
> apparmour working with upstream largely off of your back and in the
> hands of the upstream community.

Duh. Those are pretty much the reasons anyone goes through the
trouble of getting anything upstream.

> Neither of those are reasons why something should go into the tree.

They reflect the corporate reality of the open source community.
If you're going to go down the "open source isn't for money"
rathole please take it elsewhere. I've heard the arguments so many
times I can sing them to the tune of "Lady Madonna".

> Frankly I think AppArmour is a joke,

"SELinux, AppArmor, and Hilary Clinton walk into a bar ..."

> and all of this integration with
> LSM business is just a face saving effort, nothing more.  And saving
> face is not, and has never been, a reason for something to be put into
> the upstream tree.

Believe what you will. Crispin has been working with LSM from the
inception those many years ago. He's been working on getting this
module in for over a year. If you don't like his module go write
your own and put him out of business.


Casey Schaufler
casey@schaufler-ca.com

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

Thread overview: 67+ 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-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-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
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 [this message]
2007-06-28  0:34                   ` David Miller
2007-06-28 10:23                   ` Alan Cox
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-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=350078.43404.qm@web36601.mail.mud.yahoo.com \
    --to=casey@schaufler-ca.com \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@stusta.de \
    --cc=crispin@novell.com \
    --cc=davem@davemloft.net \
    --cc=jjohansen@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=seanlkml@sympatico.ca \
    /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).