Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

ess. > libapparmor exists. It only had one API, and now it has 2, but just 2 versions on the same concept (change_hat and change_profile). This is the API for change_hat http://man-wiki.net/index.php/2:change_hat What does the corresponding API in SELinux look like? Crispin -- Crispin Co

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

gt; That semantically maps well to the AppArmor change_profile() API, so conceptually it should work. It would be easier if you did that in user space instead of in the kernel, I don't know if it causes a problem to attempt to kind-of call change_profile() from within the kernel. Notably, change

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

, change_profile can fail, so what does your kernel module do when the attempt to change security context fails? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

it has 2, but just 2 versions on the same concept (change_hat and change_profile). This is the API for change_hat http://man-wiki.net/index.php/2:change_hat What does the corresponding API in SELinux look like? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO

Re: Out of tree module using LSM

James Morris wrote: > On Fri, 30 Nov 2007, Crispin Cowan wrote: >> restored faces a lot of challenges, but I hope that some kind of >> solution can be found, because the alternative is to effectively force >> vendors like Sophos to do it the "dirty" way by fishi

Re: Out of tree module using LSM

offers you a way to do what you need to do than force you to do nasty things. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscri

Re: Out of tree module using LSM

James Morris wrote: On Fri, 30 Nov 2007, Crispin Cowan wrote: restored faces a lot of challenges, but I hope that some kind of solution can be found, because the alternative is to effectively force vendors like Sophos to do it the dirty way by fishing in memory for the syscall table. I

Re: Out of tree module using LSM

need to do than force you to do nasty things. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line

Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree

Kyle Moffett wrote: > On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote: >> Andrew Morgan wrote: >>> It feels to me as if a MAC "override capability" is, if true to its >>> name, extra to the MAC model; any MAC model that needs an 'override' >>> to fun

Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree

I don't get the difference. Both seem to permit the process to violate the MAC policy. I could make up a meaning for MAC_ADMIN that is different from MAC_OVERRIDE in the AppArmor sense, but I don't want to :-) and worse, I suspect the distinction would be different for each LSM. So let not, and just have one

Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree

of MAC_READ vs. MAC_WRITE, and especially MAC_RELABEL_SUBJECT, becomes murky, e.g. I have no clue WtF "relabel subject" means to AppArmor. But I can very easily understand what "CAP_MAC_OVERRIDE" means to AppArmor. So I'm with Casey; I support a simple 1-bit capability for MAC

Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree

with Casey; I support a simple 1-bit capability for MAC override. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send

Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree

in the AppArmor sense, but I don't want to :-) and worse, I suspect the distinction would be different for each LSM. So let not, and just have one MAC_OVERRIDE capability. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http

Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree

Kyle Moffett wrote: On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote: Andrew Morgan wrote: It feels to me as if a MAC override capability is, if true to its name, extra to the MAC model; any MAC model that needs an 'override' to function seems under-specified... SELinux clearly feels no need

Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

Peter Dolding wrote: > On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote: > >> --- Peter Dolding <[EMAIL PROTECTED]> wrote: >>> On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote: >>> >>>> P

Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

Peter Dolding wrote: On Nov 18, 2007 5:22 AM, Casey Schaufler [EMAIL PROTECTED] wrote: --- Peter Dolding [EMAIL PROTECTED] wrote: On Nov 17, 2007 11:08 AM, Crispin Cowan [EMAIL PROTECTED] wrote: Peter Dolding wrote: Assign application to a cgroup that contains

More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

per container? What makes sense to me is to ensure that it is easy for an LSM module to have a policy per container. This is relatively easy to do, and maps very well to the primary use of containers for hosting virtual domains. Crispin -- Crispin Cowan, Ph.D. http://c

More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

. This is relatively easy to do, and maps very well to the primary use of containers for hosting virtual domains. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3

Re: [Apparmor-dev] Re: AppArmor Security Goal

rocess anyway. > It counts as a surprising result, and so is specifically disclaimed. I can tell it is surprising, because it surprised Andi Kleen :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/

Re: [Apparmor-dev] Re: AppArmor Security Goal

either be trusted, or be mallicious and fall inside the influence of the confined process anyway. It counts as a surprising result, and so is specifically disclaimed. I can tell it is surprising, because it surprised Andi Kleen :) Crispin -- Crispin Cowan, Ph.D. http

Re: AppArmor Security Goal

way to do it is what JJ posted: enhance the rule language so you can have one rule for files that you own, and a different rule for files owned by others. The AppArmor community (well, JJ and I :) are debating the cost/benefit of this: is the added flexibility worth the added complexity? C

Re: AppArmor Security Goal

hing else and edit it a bit, and then load it. The big difference between the former and latter is that the former is inflexible (it either works or it doesn't) and the latter requires privilege. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Lin

Re: AppArmor Security Goal

Dr. David Alan Gilbert wrote: > * Crispin Cowan ([EMAIL PROTECTED]) wrote: > >> I mostly don't see this as a serious limitation, because almost everyone >> has their own workstation, and thus has root on that workstation. There >> are 2 major exceptions: &g

Re: AppArmor Security Goal

Dr. David Alan Gilbert wrote: * Crispin Cowan ([EMAIL PROTECTED]) wrote: I mostly don't see this as a serious limitation, because almost everyone has their own workstation, and thus has root on that workstation. There are 2 major exceptions: * Schools, where the workstations are thin

Re: AppArmor Security Goal

difference between the former and latter is that the former is inflexible (it either works or it doesn't) and the latter requires privilege. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com

Re: AppArmor Security Goal

the rule language so you can have one rule for files that you own, and a different rule for files owned by others. The AppArmor community (well, JJ and I :) are debating the cost/benefit of this: is the added flexibility worth the added complexity? Crispin -- Crispin Cowan, Ph.D. http

Re: AppArmor Security Goal

hat I want?" but merely "is it non-silly, such that clearly it provides value to some users?" * Does the code live up to the model? I submit that the AppArmor model is valid, even if it totally failed all of David Gilbert's questions (I think AppArmor can actually provide

Re: AppArmor Security Goal

Dr. David Alan Gilbert wrote: > * Crispin Cowan ([EMAIL PROTECTED]) wrote: > >> I don't get the problem: if you want your web browser to be able to >> access where you commonly store your documents, then give it that >> permission. The above rule says that your web b

Re: AppArmor Security Goal

Dr. David Alan Gilbert wrote: > * Crispin Cowan ([EMAIL PROTECTED]) wrote: > > * Manipulating AppArmor policy requires being both root privileged >> and not being confined by AppArmor, thus there is explicitly no >> capability for non-privileged users to c

Re: AppArmor Security Goal

Andi Kleen wrote: > Crispin Cowan <[EMAIL PROTECTED]> writes: > > The document should be a good base for a merge. > > >> * A confined process can operate on a file descriptor passed to it >> by an unconfined process, even if it manipulates a file not i

Re: AppArmor Security Goal

Andi Kleen wrote: Crispin Cowan [EMAIL PROTECTED] writes: The document should be a good base for a merge. * A confined process can operate on a file descriptor passed to it by an unconfined process, even if it manipulates a file not in the confined process's profile

Re: AppArmor Security Goal

Dr. David Alan Gilbert wrote: * Crispin Cowan ([EMAIL PROTECTED]) wrote: snip * Manipulating AppArmor policy requires being both root privileged and not being confined by AppArmor, thus there is explicitly no capability for non-privileged users to change AppArmor policy

Re: AppArmor Security Goal

Dr. David Alan Gilbert wrote: * Crispin Cowan ([EMAIL PROTECTED]) wrote: I don't get the problem: if you want your web browser to be able to access where you commonly store your documents, then give it that permission. The above rule says that your web browser doesn't get to go change

Re: AppArmor Security Goal

up to the model? I submit that the AppArmor model is valid, even if it totally failed all of David Gilbert's questions (I think AppArmor can actually provide about half of what he asked for). Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux

AppArmor Security Goal

re-sent due to a typo in addressing. AppArmor Security Goal Crispin Cowan, PhD MercenaryLinux.com This document is intended to specify the security goal that AppArmor is intended to achieve, so that users can evaluate whether AppArmor will meet their needs, and kernel developers can evaluate

Re: Problem with accessing namespace_sem from LSM.

ting, you can do that with any policy system. To show "dangerous" you would have to show how a reasonable policy that should be secure is in fact bypassable. This threat from mount point aliases, this has often been conjectured but has never been shown. Crispin -- Crispin Cowan, Ph.D.

Re: Problem with accessing namespace_sem from LSM.

. This threat from mount point aliases, this has often been conjectured but has never been shown. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work

AppArmor Security Goal

re-sent due to a typo in addressing. AppArmor Security Goal Crispin Cowan, PhD MercenaryLinux.com This document is intended to specify the security goal that AppArmor is intended to achieve, so that users can evaluate whether AppArmor will meet their needs, and kernel developers can evaluate

Re: Defense in depth: LSM *modules*, not a static interface

rimary LSM to check the security_ops of the > secondary LSM(s) and complain if it considers there to be an incompatiblity. > That is what I advocate. Restore the modular feature immediately, this static interface is lots of cost (mostly opportunity cost) and very little benefit (mostly defense against contrived FU

Re: Defense in depth: LSM *modules*, not a static interface

advocate. Restore the modular feature immediately, this static interface is lots of cost (mostly opportunity cost) and very little benefit (mostly defense against contrived FUD threats). Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

ux and load TOMOYO. Oh, you can't because someone has made modules not be loadable :( Hmmm, perhaps someone could fix that by reverting the static interface patch ... :) > May be we should consider stackable LSM again? > Exactly. Stacker was shelved, so to speak :) because of the l

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

stackable LSM again? Exactly. Stacker was shelved, so to speak :) because of the lack of in-kernel modules. Soon it will be time to reconsider that. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

d especially not without a clear design that addresses clearly stated problems that lots of people are having. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity a

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

http://crispincowan.com/~crispin/FOSDEM2006-apparmor.avi * Similar talk at linux.conf.au 2007 http://youtube.com/watch?v=EgrfmSm0NWs * Similar talk at Defcon 2007 http://video.google.com/videoplay?docid=-1731833784646588861=en Crispin -- Crispin Cowan, Ph.D.

Re: Defense in depth: LSM *modules*, not a static interface

ban syringes and demand that everyone be born with a strong immune system. Why is it that security flame wars always end up reasoning with absurd analogies? :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.co

Re: Defense in depth: LSM *modules*, not a static interface

is it that security flame wars always end up reasoning with absurd analogies? :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

://crispincowan.com/~crispin/FOSDEM2006-apparmor.avi * Similar talk at linux.conf.au 2007 http://youtube.com/watch?v=EgrfmSm0NWs * Similar talk at Defcon 2007 http://video.google.com/videoplay?docid=-1731833784646588861hl=en Crispin -- Crispin Cowan, Ph.D. http

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

clearly stated problems that lots of people are having. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

Rob Meijer wrote: > On Mon, October 29, 2007 11:24, Crispin Cowan wrote: > >>> Thus IMHO it may be a good idea to instead of a maintainer for LSM >>> modules as proposed, alternatively a maintainer for each formal model >>> may be more appropriate. This a

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

so should we exclude one and keep the other? No, of course not, because in practice they are very different. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complex

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

in practice they are very different. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

Rob Meijer wrote: On Mon, October 29, 2007 11:24, Crispin Cowan wrote: Thus IMHO it may be a good idea to instead of a maintainer for LSM modules as proposed, alternatively a maintainer for each formal model may be more appropriate. This also would require module builders to first think

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

e useful. But IMHO that bar of "too narrow" should be very, very low. Defenses against specific modes of attack would be a fine thing to build up in the library of LSMs, especially if we got a decent stacking module so that they could be composed. Crispin -- Crispin Cowan, Ph.D.

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

be a fine thing to build up in the library of LSMs, especially if we got a decent stacking module so that they could be composed. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista

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

ive to be both clear and precise, achieving both is challenging. So, if someone discovers a mis-match between the description and the code, would a patch to the description be an acceptable resolution, if it did not render the model silly? Crispin -- Crispin Cowan, Ph.D. http://mercenar

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

, if someone discovers a mis-match between the description and the code, would a patch to the description be an acceptable resolution, if it did not render the model silly? Crispin -- Crispin Cowan, Ph.D. http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

reat, and it is wonderful that you *can* hack the source if you need to, but demanding that end users patch their source code when all they want to do is load a module is really, really sad. Please revert this patch. Its benefits are no where near its costs. Crispin -- Crispin Cowan, Ph.D.

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

if you need to, but demanding that end users patch their source code when all they want to do is load a module is really, really sad. Please revert this patch. Its benefits are no where near its costs. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin

Re: LSM conversion to static interface

device and device driver. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majord

Re: LSM conversion to static interface

-- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org

Re: LSM conversion to static interface

ybe, but I don't know. Again, I'm strictly opposed to the loss of flexibility until the performance issue is documented, and then I would rather see it be a configuration option you can choose to inline your module of choice, rather than the default behavior. Crispin -- Cr

Re: LSM conversion to static interface

astrophe, it is just tedious. It does not kill baby seals, and it does not make Linux utterly useless. OTOH, I think it is strictly negative: it takes away user choice in 2 dimensions, and adds zero value. So apply it if you must to bake the kernel developer's lives easier, but it really is

Re: LSM conversion to static interface

it is strictly negative: it takes away user choice in 2 dimensions, and adds zero value. So apply it if you must to bake the kernel developer's lives easier, but it really is a net loss in Linux kernel capability. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin

Re: LSM conversion to static interface

is documented, and then I would rather see it be a configuration option you can choose to inline your module of choice, rather than the default behavior. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity

Re: Re: LSM conversion to static interface

in, etc, to get exposure to enterprise users. So I don't think I am being self-serving in arguing against this patch. I just think it is bad for Linux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubsc

Re: Re: LSM conversion to static interface

just think it is bad for Linux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

ave never considered the idea of separate LSM modules per container. The idea doesn't really make sense to me. It is kind of like asking for private device drivers, or even a private kernel, per name space. If that's what you want, use virtualization like KVM, Xen, or VMware. Crispin -- Crispin Co

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

considered the idea of separate LSM modules per container. The idea doesn't really make sense to me. It is kind of like asking for private device drivers, or even a private kernel, per name space. If that's what you want, use virtualization like KVM, Xen, or VMware. Crispin -- Crispin Cowan, Ph.D

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

not the case. > And you claim you are not a security expert :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the bo

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

. And you claim you are not a security expert :-) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL

Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel

so users can decide on an appropriate mechanism. 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 l

Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel

on an appropriate mechanism. 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-kernel in the body of a message

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 in

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

- and although it's technically > inferior. AppArmor's advantages come from the model, not the tools. AppArmor is not inferior to SELinux, it is different than SELinux. Neither can replace the other without horrid kludges. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~c

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

. 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-kernel in the body of a message to [EMAIL PROTECTED

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

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

Or even easier, LSMs that don't want to be unloaded can just block rmmod, and simple LSMs that can be unloaded safely can permit it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oft

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

r issue to solve, not ours. I think it is a little more fundamental than that. If you are going to do pathname based access control at all, you need access to sufficient information to compute the path name. Can we have a discussion about the best way to do that? Crispin -- Crispin C

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

access to sufficient information to compute the path name. Can we have a discussion about the best way to do that? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor

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

with, and preserve user choice, how about we *only* remove the ability to rmmod, and leave in place the ability to modprobe? Or even easier, LSMs that don't want to be unloaded can just block rmmod, and simple LSMs that can be unloaded safely can permit it. Crispin -- Crispin Cowan, Ph.D

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

issue, right? > So if the document said "confinement with respect to direct file access and POSIX.1e capabilities" and that list got extended as AA got new confinement features, would that address your issue? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

that address your issue? 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-kernel in the body

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

Greg KH wrote: > On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote: > >> Then there's all the other problems, such as file systems that don't >> support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable >> to network attack, but that is not the

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

Greg KH wrote: On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote: Then there's all the other problems, such as file systems that don't support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable to network attack, but that is not the threat AA is addressing. AA

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

vulnerable to network attack, but that is not the threat AA is addressing. AA is preventing an application with access to an NFS mount from accessing the *entire* mount. There is lots of practical security value in this, and label schemes cannot do it. Well, mostly; you could do it with a dynamic labe

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

into kernel memory, but that requires an AA-style regexp parser in the kernel to apply the labels. 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

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

o default-allow system wide: unconfined processes are allowed to do anything that classic DAC permissions allow. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

nt AA. Some have alleged that AA layered on top of SELinux is the best way. I think that is clearly wrong; AA layered on top of SELinux is possible, but would require a bunch of enhancements to SELinux first, and the result would be more complex than the proposed AA patch and have weaker f

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

rmor's ability to change policies on a live system more difficult. * The necessary extensions would not be appealing to the SELinux community. LSM is the common code that AA and SELinux have agreed to be mutually useful. Forcing AA to sit on top of SELinux would harm both AA and SELin

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

is the common code that AA and SELinux have agreed to be mutually useful. Forcing AA to sit on top of SELinux would harm both AA and SELinux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

layered on top of SELinux is possible, but would require a bunch of enhancements to SELinux first, and the result would be more complex than the proposed AA patch and have weaker functionality and performance. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

anything that classic DAC permissions allow. 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-kernel

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

alling software. This isn't what users want, so they invariably bypass security and install shiny things if they own the box. SELinux and AppArmor can't help but fail if you put them in that kind of harm's way. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

ntentional, and contributes to AppArmor's ease of use, and does not generate a hole if you consider every process exposed to (say) network attack and confine it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.co

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

not generate a hole if you consider every process exposed to (say) network attack and confine it. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's not linear - To unsubscribe from

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

and AppArmor can't help but fail if you put them in that kind of harm's way. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's not linear - To unsubscribe from this list: send the line

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

gement problems of both AppArmor and SELinux; you would have to solve both the new file problem, and the file alias problem. Think about what you would have to do to accommodate (say) a text editor's file save procedure of "write new file.tmp, rename oldfile to oldfile.old, rename newfile.tmp to oldfil

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

be done, but AFAICT, with small benefit and large cost. More security may be more secure, but it isn't necessarily better. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Security: It's

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

hope this explains how we detect which of multiple hard links to a file you used to access the file without mucking about with argv[0]. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com Sec

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

that if it did there's a Consultant's Retirement to be made fixing the security hole it points out. AppArmor does address it, and I hope this explains how we detect which of multiple hard links to a file you used to access the file without mucking about with argv[0]. Crispin -- Crispin

  1   2   >