Re: [AppArmor 00/44] AppArmor security module overview
David Miller schrieb: 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. Neither of those are reasons why something should go into the tree. I beg to differ. b) is *the* reason cited again and again on LKML for submitting code for inclusion in the tree. Whenever anyone posts anything which is remotely related to out-of-tree code, whether it's a question on the usage of some standard in-tree function, a request for help with a coding or debugging problem, or out-of-tree repercussions of an in-tree change, he or she invariably has to put up with an answer along the lines of: put your code into the tree and all your problems will be solved - or its sarcastic variant: I can't find your code anywhere in the current kernel sources. You can't have it both ways. Either you go around bashing people for maintaining their code out-of-tree or you go around bashing people for trying to get their code into the tree. -- Tilman SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: [AppArmor 00/44] AppArmor security module overview
On Thu, Jun 28, 2007 at 01:27:12PM +0200, Tilman Schmidt wrote: David Miller schrieb: 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. Neither of those are reasons why something should go into the tree. I beg to differ. b) is *the* reason cited again and again on LKML for submitting code for inclusion in the tree. Whenever anyone posts anything which is remotely related to out-of-tree code, whether it's a question on the usage of some standard in-tree function, a request for help with a coding or debugging problem, or out-of-tree repercussions of an in-tree change, he or she invariably has to put up with an answer along the lines of: put your code into the tree and all your problems will be solved - or its sarcastic variant: I can't find your code anywhere in the current kernel sources. You can't have it both ways. Either you go around bashing people for maintaining their code out-of-tree or you go around bashing people for trying to get their code into the tree. You have a point. But: Code in the kernel must fulfill some (not completely fixed) quality criteria. It wouldn't be good to blindly include every bit of GPL'ed kernel code available anywhere in the Internet. As an example, it's highly unlikely that some external device driver will be accepted without the author/maintainer doing some changes for getting it included. If [1] AppArmor is considered to be generally insecure or in all respects inferior to SELinux it doesn't belong into the kernel. Being blessed with some of the holy penguin pee by being included in the kernel is considered by many users as a quality criteria. Sure, this contradicts a bit the get your code upstream mantra, but these are two conflicting goals and there's therefore no ideal solution. If [1] AppArmor is offering required functionality not available through SELinux and it's considered a correct and secure solution for these purposes it should go into the kernel. Otherwise, it should not go into the kernel. cu Adrian [1] note the if -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 00/44] AppArmor security module overview
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 be some differences of opinion over the use of pathname-based-security. I was refreshed to have not been cc'ed on a lkml thread for once. I guess it couldn't last. sorry about that Do you agree with the irreconcilable part? I think I do. I will concede that this may be the case for some. However I am still hopeful (perhaps naive) that this isn't the case in general. 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. Agreed, and I hope any changes that are made are for the benefit of the kernel in general and will find uses in other parts. 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. Sigh. Please don't put us in this position again. Get stuff upstream before shipping it to customers, OK? It ain't rocket science. Indeed, I can only appologize for the past, and offer reassurances that we intend to do our best to do, it right going forward. Are there any other sticking points? The conditional passing of the vfsmnt mount in the vfs, as done in this patch series, has received a NAK. This problem results from NFS passing a NULL nameidata into the vfs. We have a second patch series that we have posted for discussion that addresses this by splitting the nameidata struct. Message-Id: [EMAIL PROTECTED] Subject: [RFD 0/4] AppArmor - Don't pass NULL nameidata to vfs_create/lookup/permission IOPs other issues that have been raised are: - AppArmor does not currently mediate IPC and network communications. Mediation of these is a wip - the use of d_path to generate the pathname used for mediation when a file is opened. - Generating the pathname using a reverse walk is considered ugly - A buffer is alloced to store the generated path name. - The buffer size has a configurable upper limit which will cause opens to fail if the pathname length exceeds this limit. This is a fail closed behavior. - there have been some concerns expressed about the performance of this approach We are evaluating our options on how best to address this issue. OK, useful summary, thanks. I'd encourage you to proceed apace. thankyou pgpRzAH1Flvi8.pgp Description: PGP signature
Re: [AppArmor 00/44] AppArmor security module overview
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 help but see this problem in any reverse-pathname-generation proposal which gets the locking right. Have a look at how __d_path() is implemented (with the fixes): It takes the dcache_lock, and the vfsmount_lock where necessary, and this ensures that the pathname can't change under it, neither because of a rename nor unlink nor remount. The pathname computed is *exactly* the name the file has at that specific point time. A few more details about how pathnames work are explained in the tech doc at: http://forge.novell.com/modules/xfcontent/downloads.php/apparmor/LKML_Submission-May_07 Andreas - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 00/44] AppArmor security module overview
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 that. But for that to be true you'd have to believe _everyone_ using Novell distributions has needs that align exactly with AppArmor. Otherwise, how to explain that you don't offer and support both SELinux and AppArmor to your users? It seems as far as Novell is concerned, AppArmor _is_ meant to replace SELinux. Not that there is really anything wrong with that, but it's a little disingenuous to then argue that they're meant to coexist. Sean - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 00/44] AppArmor security module overview
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. You keep saying that. But for that to be true you'd have to believe _everyone_ using Novell distributions has needs that align exactly with AppArmor. Otherwise, how to explain that you don't offer and support both SELinux and AppArmor to your users? They are meant to co-exist in the Linux kernel source tree. It is a fact that there exist use cases where AppArmor is incapable of meeting the need and SELinux is just the right thing. It is Novell's business judgment that there are not enough of those situations in our customer base to be worth the additional expense at this time. 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. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 00/44] AppArmor security module overview
--- 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 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 00/44] AppArmor security module overview
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 body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[AppArmor 00/44] AppArmor security module overview
This post contains patches to include the AppArmor application security framework, with request for inclusion into -mm for wider testing. These patches are currently against lkml but we will gladly rebase them against -mm so that they will apply cleanly. Any comments and feedback to improve implementation are appreciated. A second post dealing with the issue of passing NULL nameidata, will be posted to lkml for discussion. Changes since previous post: - remove custom pathname mangling - rework apparmor auditing to cleanup message formating and better use audit framework - change permission consistency checks from runtime to once at policy load - add change_profile feature and cleanup change_hat to use change_profile The patch series consists of five areas: (1) Pass struct vfsmount through to LSM hooks. (2) Fixes and improvements to __d_path(): (a) make it unambiguous and exclude unreachable paths from /proc/mounts, (b) make its result consistent in the face of remounts, (c) introduce d_namespace_path(), a variant of d_path that goes up to the namespace root instead of the chroot. (d) the behavior of d_path() and getcwd() remain unchanged, and there is no hidding of unreachable paths in /proc/mounts. The patches addressing these have been seperated from the AppArmor submission and will be introduced at a later date. Part (a) has been in the -mm tree for a while; this series includes an updated copy of the -mm patch. Parts (b) and (c) shouldn't be too controversial. (3) Be able to distinguish file descriptor access from access by name in LSM hooks. Applications expect different behavior from file descriptor accesses and accesses by name in some cases. We need to pass this information down the LSM hooks to allow AppArmor to tell which is which. (4) Convert the selinux sysctl pathname computation code into a standalone function. (5) The AppArmor LSM itself. (See below.) A tarball of the kernel patches, base user-space utilities, example profiles, and technical documentation (including a walk-through) are available at: http://forgeftp.novell.com//apparmor/LKML_Submission-June-07/ Explaining the AppArmor design in detail would take by far too much space here, so let me refer you to the technical documentation for that. Included is a low-level walk-through of the system and basic tools, and some examples. The manual pages included in the apparmor-parser package are worth a read as well. -- - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 00/44] AppArmor security module overview
On Tue, 26 Jun 2007 16:07:56 -0700 [EMAIL PROTECTED] wrote: This post contains patches to include the AppArmor application security framework, with request for inclusion into -mm for wider testing. Patches 24 and 31 didn't come through. Rolled-up diffstat (excluding 2431): fs/attr.c|7 fs/dcache.c | 181 ++- fs/ecryptfs/inode.c | 41 fs/exec.c|3 fs/fat/file.c|2 fs/hpfs/namei.c |2 fs/namei.c | 115 +- fs/nfsd/nfs4recover.c|7 fs/nfsd/nfs4xdr.c|2 fs/nfsd/vfs.c| 89 + fs/ntfs/file.c |2 fs/open.c| 50 fs/reiserfs/file.c |2 fs/reiserfs/xattr.c |8 fs/splice.c |4 fs/stat.c|2 fs/sysfs/file.c |2 fs/utimes.c | 11 fs/xattr.c | 75 - fs/xfs/linux-2.6/xfs_lrw.c |2 include/linux/audit.h| 12 include/linux/fs.h | 27 include/linux/nfsd/nfsd.h|3 include/linux/security.h | 182 ++- include/linux/sysctl.h |2 include/linux/xattr.h| 11 ipc/mqueue.c |2 kernel/audit.c |6 kernel/sysctl.c | 27 mm/filemap.c | 12 mm/filemap_xip.c |2 mm/shmem.c |2 mm/tiny-shmem.c |2 net/unix/af_unix.c |2 security/Kconfig |1 security/Makefile|1 security/apparmor/Kconfig| 10 security/apparmor/Makefile | 13 security/apparmor/apparmor.h | 265 + security/apparmor/apparmorfs.c | 252 + security/apparmor/inline.h | 211 security/apparmor/list.c | 94 + security/apparmor/locking.txt| 68 + security/apparmor/lsm.c | 817 security/apparmor/main.c | 1255 + security/apparmor/match.c| 248 security/apparmor/match.h| 83 + security/apparmor/module_interface.c | 589 +++ security/apparmor/procattr.c | 155 +++ security/commoncap.c |7 security/dummy.c | 43 security/selinux/hooks.c | 94 - 52 files changed, 4701 insertions(+), 404 deletions(-) which seems OK. so... where do we stand with this? Fundamental, irreconcilable differences over the use of pathname-based security? Are there any other sticking points? - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 00/44] AppArmor security module overview
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 be some differences of opinion over the use of pathname-based-security. I was refreshed to have not been cc'ed on a lkml thread for once. I guess it couldn't last. Do you agree with the irreconcilable part? I think I do. 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. Sigh. Please don't put us in this position again. Get stuff upstream before shipping it to customers, OK? It ain't rocket science. Are there any other sticking points? The conditional passing of the vfsmnt mount in the vfs, as done in this patch series, has received a NAK. This problem results from NFS passing a NULL nameidata into the vfs. We have a second patch series that we have posted for discussion that addresses this by splitting the nameidata struct. Message-Id: [EMAIL PROTECTED] Subject: [RFD 0/4] AppArmor - Don't pass NULL nameidata to vfs_create/lookup/permission IOPs other issues that have been raised are: - AppArmor does not currently mediate IPC and network communications. Mediation of these is a wip - the use of d_path to generate the pathname used for mediation when a file is opened. - Generating the pathname using a reverse walk is considered ugly - A buffer is alloced to store the generated path name. - The buffer size has a configurable upper limit which will cause opens to fail if the pathname length exceeds this limit. This is a fail closed behavior. - there have been some concerns expressed about the performance of this approach We are evaluating our options on how best to address this issue. OK, useful summary, thanks. I'd encourage you to proceed apace. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
