From: "Bill O'Donnell" <billodo@sgi.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: David Miller <davem@davemloft.net>,
crispin@novell.com, seanlkml@sympatico.ca, bunk@stusta.de,
akpm@linux-foundation.org, jjohansen@suse.de,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [AppArmor 00/44] AppArmor security module overview
Date: Thu, 28 Jun 2007 08:50:01 -0500 [thread overview]
Message-ID: <20070628135001.GA11666@sgi.com> (raw)
In-Reply-To: <350078.43404.qm@web36601.mail.mud.yahoo.com>
On Wed, Jun 27, 2007 at 05:27:17PM -0700, Casey Schaufler wrote:
|
| --- 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.
Please.
I really wish this thread would stick to the technical matter and
dispense with the infernile sniping on one hand and stroking of
egos on the other. Sheesh - some of us are actually trying to glean
something useful from all of this.
|
| > 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 ..."
Yawn. Not funny. See above comment.
| > 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.
Now this is getting really boring. See above comment.
Can't we just stay on point?
--
Bill O'Donnell
SGI
billodo@sgi.com
next prev parent reply other threads:[~2007-06-28 13:48 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
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 [this message]
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=20070628135001.GA11666@sgi.com \
--to=billodo@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=bunk@stusta.de \
--cc=casey@schaufler-ca.com \
--cc=crispin@novell.com \
--cc=davem@davemloft.net \
--cc=jjohansen@suse.de \
--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