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: [PATCH 2/2] hijack: update task_alloc_security

Serge E. Hallyn wrote: Quoting Crispin Cowan ([EMAIL PROTECTED]): I think that CAP_NS_OVERRIDE|CAP_SYS_PTRACE is a problem because of the Oops, yeah I meant . Cool. With then I have no problem at all. Thanks, Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com

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: [PATCH 2/2] hijack: update task_alloc_security

Serge E. Hallyn wrote: Quoting Crispin Cowan ([EMAIL PROTECTED]): Is there to be an LSM hook, so that modules can decide on an arbitrary decision of whether to allow a hijack? So that this do the right SELinux thing can be generalized for all LSMs to do the right thing. Currently

Re: [PATCH 2/2] hijack: update task_alloc_security

; Is there to be an LSM hook, so that modules can decide on an arbitrary decision of whether to allow a hijack? So that this do the right SELinux thing can be generalized for all LSMs to do the right thing. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary

Re: [PATCH 1/2] namespaces: introduce sys_hijack (v10)

retval; - 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 -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary

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

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: Peter Dolding wrote: Assign application to a cgroup that contains

Object Capabilities for AppArmor

to go straight through unmoderated, please subscribe to apparmor-dev, it is not a high volume list. Well, it wasn't until just now :) Thanks, Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com

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: File descriptor object capability LSM module. Feasability?

Mark Seaborn wrote: Crispin Cowan [EMAIL PROTECTED] wrote: The other issue with the object capability model is analyzability. Stephen Smalley complained about this in some public setting a while ago when someone basically asked for an object capability enhancement to SELinux. Stephen

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

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://crispincowan.com/~crispin CEO, Mercenary Linux

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

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

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

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

Re: File descriptor object capability LSM module. Feasability?

, but the case for including a feature that cannot be utilized by automatic learning had better be compelling. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3

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: Possible missing security checks in usbfs?

-- 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 unsubscribe linux-security-module in the body of a message

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

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)

://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)

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 and Containers

. If you have a solution to it tell me. Since a cut line has be put somewhere with containers. Where as I see it as a very minor problem, and very easy to fix without any re-design of LSM, or of Containers. It only requires container-aware LSM modules. Crispin -- Crispin Cowan, Ph.D

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

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-security-module in the body of a message

Re: [RFC] Can we somehow avoid infinite execve() loop?

if it was not actually malicious. Lying to the program and returning success is suitable if you are trying to forensically determine what the malware will do, but if that is your objective, then running the malware in a honeypot on a virtual machine is a better choice. Crispin -- Crispin Cowan, Ph.D

Re: [RFC] Can we somehow avoid infinite execve() loop?

/bin/true for the original exec request. It has all of the negative consequences of just blocking the exec, and fewer advantages. Perhaps I'm missing something, but I haven't seen it articulated so far. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director

Re: [RFC] Can we somehow avoid infinite execve() loop?

information and share with other hosts). Any opinions? I don't like the /bin/true response at all. I think it is weak if you are sure it is an attack, and it is meddlesome if you are unsure. The exponential slowdown is a much better response if you have a maybe-attack. Crispin -- Crispin Cowan, Ph.D

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: [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

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

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 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

Re: New to LSM list. A few questions.

-SELinux system. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info

Re: Reading files into LSM

/LKML_Submission-April_07/apparmor-kernel-patches-2.0.2-564.tar.gz for details. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com - To unsubscribe from this list: send the line unsubscribe linux-security-module

Re: New to LSM list. A few questions.

the other. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com - 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

Re: AppArmor FAQ

are quite explicit that AppArmor only mediates file access and POSIX.1e capabilities. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com - To unsubscribe from this list: send the line unsubscribe linux-security

Re: AppArmor FAQ

, KeyOS, AS400, to name just a few. This claim seems bogus. Labels may be your method of choice for confinement, but they are far from the only way. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com

Re: AppArmor FAQ

is the main advantage of labels over pathnames for access control. AppArmor does not attempt to manage information flow, allowing it to use pathnames to achieve ease of use. If you want information flow control, then by all means use a label-based system. Crispin -- Crispin Cowan, Ph.D

Re: AppArmor FAQ

content special, not the other way around. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com You cannot say anything that is both simple and complete.--Crispin on Goedel - To unsubscribe from this list: send