Re: [AppArmor 00/44] AppArmor security module overview

2007-06-27 Thread John Johansen
On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote: On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen [EMAIL PROTECTED] wrote: so... where do we stand with this? Fundamental, irreconcilable differences over the use of pathname-based security? There certainly seems to

[PATCH] [RFC] security: add hook inode_post_removexattr

2007-06-27 Thread Hawk Xu
Add hook inode_post_removexattr for updating inode security field after successful removexattr operation. Signed-off-by: Hawk Xu [EMAIL PROTECTED] --- fs/xattr.c |7 +-- include/linux/security.h | 19 +++ security/dummy.c |6 ++ 3 files

Re: [AppArmor 00/44] AppArmor security module overview

2007-06-27 Thread Andreas Gruenbacher
On Wednesday 27 June 2007 12:58, Kyle Moffett wrote: I seem to recall you could actually end up racing and building a path to the file in those directories as a/d/0/3 or some other path at which it never even remotely existed. I'd love to be wrong, Cheer up, you recall wrong. but I can't

Re: [PATCH try #2] security: Convert LSM into a static interface

2007-06-27 Thread James Morris
On Wed, 27 Jun 2007, Serge E. Hallyn wrote: Patch tests fine for me for expected capability behavior with lsm=n, lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y. So while I'm opposed to the patch, it appears to be safe. I've also tested a bunch of scenarios:

Re: [RFD 0/4] AppArmor - Don't pass NULL nameidata to vfs_create/lookup/permission IOPs

2007-06-27 Thread Andreas Gruenbacher
On Wednesday 27 June 2007 01:46, Trond Myklebust wrote: On Tue, 2007-06-26 at 16:15 -0700, [EMAIL PROTECTED] wrote: To remove conditionally passing of vfsmounts to the LSM, a nameidata struct can be instantiated in the nfsd and mqueue filesystems. This however results in useless

Re: [AppArmor 00/44] AppArmor security module overview

2007-06-27 Thread Sean
On Wed, 27 Jun 2007 14:06:04 -0700 Crispin Cowan [EMAIL PROTECTED] wrote: 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. You keep saying

Re: [AppArmor 00/44] AppArmor security module overview

2007-06-27 Thread Crispin Cowan
Sean wrote: On Wed, 27 Jun 2007 14:06:04 -0700 Crispin Cowan [EMAIL PROTECTED] wrote: 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.

Re: [AppArmor 00/44] AppArmor security module overview

2007-06-27 Thread Casey Schaufler
--- David Miller [EMAIL PROTECTED] wrote: From: Crispin Cowan [EMAIL PROTECTED] 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

Re: [PATCH 1/1] file capabilities: introduce cap_setfcap

2007-06-27 Thread KaiGai Kohei
Serge E. Hallyn wrote: Here's the first patch (of several or many to come) to address some of Andrew's comments. Kaigai, IIUC cap_names.h will eventually be automatically updated? (I had to manually tweak it for testing as the new kernel sources were not located on the test system) The

Re: [PATCH try #2] security: Convert LSM into a static interface

2007-06-27 Thread Serge E. Hallyn
Quoting James Morris ([EMAIL PROTECTED]): On Wed, 27 Jun 2007, Serge E. Hallyn wrote: Patch tests fine for me for expected capability behavior with lsm=n, lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y. So while I'm opposed to the patch, it appears to be safe.

Re: [AppArmor 00/44] AppArmor security module overview

2007-06-27 Thread Andreas Dilger
Any chance you can remove linux-fsdevel from the CC list? I don't think this has anything to do with filesystems. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the