Re: [PATCH 1/4] firmware: generalize "firmware" as "system data" helpers

Just responding to one thing at the moment: On Mon, Oct 05, 2015 at 11:22:22PM +0200, Luis R. Rodriguez wrote: > * we should phase out the usermode helper from firmware_class long term You can "phase out", but you can not delete it as it's a user/kernel api that we have to support for forever,

Re: [PATCH 1/4] firmware: generalize "firmware" as "system data" helpers

On Tue, Aug 04, 2015 at 03:00:01PM -0700, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Historically firmware_class code was added to help > get device driver firmware binaries but these days > request_firmware*() helpers are being repurposed for > general system data

Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote: [PATCH 1/3] add a private data field within kobj_attribute structure. This patch add a private data field, declared as void *, within kobj_attribute structure. The _show() and _store() method in the sysfs attribute entries can

Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

On Mon, Feb 25, 2008 at 03:57:44PM +0900, Kohei KaiGai wrote: Greg KH wrote: On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote: [PATCH 1/3] add a private data field within kobj_attribute structure. This patch add a private data field, declared as void *, within kobj_attribute

Re: [PATCH 2/3] exporting capability name/code pairs (final)

On Fri, Feb 22, 2008 at 06:45:32PM +0900, Kohei KaiGai wrote: I believe it is correct assumption that long type and pointers have same width in the linux kernel. Please tell me, if it is wrong. That is correct, it is one of the assumptions that is safe to make. But you should fix the compiler

Re: [PATCH] exporting capability code/name pairs (try #5.1)

On Mon, Feb 18, 2008 at 04:12:53PM +0900, Kohei KaiGai wrote: Greg KH wrote: On Fri, Feb 15, 2008 at 12:38:02PM -0600, Serge E. Hallyn wrote: This patch enables to export code/name of capabilities supported on the running kernel. A newer kernel sometimes adds new capabilities

Re: [PATCH] exporting capability code/name pairs (try #5.1)

On Fri, Feb 15, 2008 at 12:38:02PM -0600, Serge E. Hallyn wrote: Quoting Kohei KaiGai ([EMAIL PROTECTED]): Li Zefan wrote: - snip - +error1: +kobject_put(capability_kobj); +error0: +printk(KERN_ERR Unable to export capabilities\n); + +return 0;

Re: [TOMOYO #6 retry 08/21] Utility functions and policy manipulationinterface.

On Sat, Jan 12, 2008 at 11:06:17AM +0900, Tetsuo Handa wrote: Hello. James Morris wrote: TOMOYO Linux uses /sys/kernel/security/tomoyo interface for configuration. Why aren't you using securityfs for this? (It was designed for LSMs). Doh, it is using securityfs, don't

Re: [PATCH] Allow Kconfig to set default mmap_min_addr protection

On Fri, Dec 21, 2007 at 11:04:19PM +0100, Jan Engelhardt wrote: On Dec 21 2007 22:16, Willy Tarreau wrote: Hi Jan, +config SECURITY_DEFAULT_MMAP_MIN_ADDR +int Low address space to protect from user allocation Hm, should not this be 'hex'? I guess it could be, but

Re: [PATCH] Allow Kconfig to set default mmap_min_addr protection

On Fri, Dec 21, 2007 at 10:10:24PM +0100, Jan Engelhardt wrote: On Dec 21 2007 15:31, Eric Paris wrote: On Thu, 2007-12-20 at 00:29 +0100, Jan Engelhardt wrote: On Dec 19 2007 16:59, Eric Paris wrote: +config SECURITY_DEFAULT_MMAP_MIN_ADDR +int Low address space to protect

Re: Possible missing security checks in usbfs?

On Wed, Oct 31, 2007 at 07:02:27PM -0500, Tan, Lin wrote: Hello, I found several places performing mknod and mkdir operations without the proper security_inode_permission/mknod/mkdir checks. But I am not sure if it is that usbfs does not use LSM at all or there are real security violations.

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

On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote: On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote: I'm trying to compile a list of all known external modules and drivers and work to get them included in the main kernel tree to help prevent these kinds of things. If you know

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

On Fri, Oct 26, 2007 at 09:09:05AM +0200, Jan Engelhardt wrote: On Oct 25 2007 19:56, Greg KH wrote: I'm trying to compile a list of all known external modules and drivers and work to get them included in the main kernel tree to help prevent these kinds of things. If you know of any

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

On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote: Am 25.10.2007 00:31 schrieb Adrian Bunk: Generally, the goal is to get external modules included into the kernel. [...] even though it might sound harsh breaking external modules and thereby making people aware that their code

Re: LSM conversion to static interface

On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote: To possibly save bandwidth, I'll also respond to another of Greg's points: Greg KH [EMAIL PROTECTED] wrote: Any customer using a security model other than provided by their Linux distributor instantly voided all support from

Re: [TOMOYO 14/15] Conditional permission support.

On Tue, Sep 18, 2007 at 08:25:28PM +0900, Tetsuo Handa wrote: Hello. Kyle Moffett wrote: This is probably not acceptable; I doubt there's a chance in hell that TOMOYO will get merged as long as it has text-based-language parsing in the kernel. You also have

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

On Tue, Jul 24, 2007 at 01:02:24AM -0700, Andrew Morton wrote: On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris [EMAIL PROTECTED] wrote: Convert LSM into a static interface allmodconfig broke security/built-in.o: In function `rootplug_bprm_check_security':

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

On Tue, Jul 24, 2007 at 01:58:46AM -0700, Andrew Morton wrote: On Tue, 24 Jul 2007 01:53:58 -0700 Greg KH [EMAIL PROTECTED] wrote: On Tue, Jul 24, 2007 at 01:02:24AM -0700, Andrew Morton wrote: On Sat, 14 Jul 2007 12:37:01 -0400 (EDT) James Morris [EMAIL PROTECTED] wrote

Re: [RFC][PATCH] Simplified mandatory access control kernel implementation

On Fri, Jul 20, 2007 at 07:56:05AM -0400, James Morris wrote: On Thu, 19 Jul 2007, Greg KH wrote: Why not do it here on this list? It is security related and I'm sure that other security model implementations will be interested in it. Labeled NFS is aimed at being cross platform, and we

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

On Wed, Jul 18, 2007 at 10:42:09PM -0400, James Morris wrote: On Wed, 18 Jul 2007, Andrew Morton wrote: aww man, you passed over an opportunity to fix vast amounts of coding style cruftiness. GregKH-esque :-) Yeah, sorry, that was when I was young and foolish and liked to bang on the

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

On Thu, Jul 19, 2007 at 09:19:56AM -0400, James Morris wrote: On Thu, 19 Jul 2007, James Morris wrote: On Thu, 19 Jul 2007, Jim Kovaric wrote: IBMs TAMOS (Tivoli Access Manager for Operating systems) contains a loadable module, which is an out of tree module, and registers

Re: [RFC][PATCH] Simplified mandatory access control kernel implementation

On Thu, Jul 19, 2007 at 10:15:53AM -0400, James Morris wrote: On Thu, 19 Jul 2007, Joshua Brindle wrote: I also see an effort that's SELinux specific. Should be fun. The SELinux part is going to be a profile on top of the generic part so there shouldn't be any conflicts in

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

On Tue, Jun 26, 2007 at 09:06:44AM -0500, Serge E. Hallyn wrote: Quoting Adrian Bunk ([EMAIL PROTECTED]): On Mon, Jun 25, 2007 at 10:57:31PM -0500, Serge E. Hallyn wrote: Quoting James Morris ([EMAIL PROTECTED]): On Mon, 25 Jun 2007, Andreas Gruenbacher wrote: It's useful for

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

On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote: Hi! And before you scream races, take a look. It does not actually add them: Hey, I never screamed that at all, in fact, I completly agree with you :) I agree that the in-kernel implementation could use different

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

On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote: Yup, I see that once you accept the notion that it is OK for a file to be misslabeled for a bit and that having a fixxerupperd is sufficient it all falls out. My point is that there is a segment of the security community

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

On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote: On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote: On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote: Yup, I see that once you accept the notion that it is OK for a file to be misslabeled for a bit

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

On Fri, Jun 15, 2007 at 05:42:08PM -0400, James Morris wrote: On Fri, 15 Jun 2007, Greg KH wrote: Or just create the files with restrictive labels by default. That way you fail closed. From my limited knowledge of SELinux, this is the default today so this would happen by default

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

On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote: Greg KH wrote: On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote: * Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy

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

On Fri, Jun 15, 2007 at 05:18:10PM -0700, Seth Arnold wrote: On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote: We have built a label-based AA prototype. It fails because there is no reasonable way to address the tree renaming problem. How does inotify not work here? You

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

On Fri, Jun 15, 2007 at 05:01:25PM -0700, [EMAIL PROTECTED] wrote: On Fri, 15 Jun 2007, Greg KH wrote: On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote: Greg KH wrote: On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote: Only case where attacker _can't_ be keeping

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

On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote: AppArmor is meant to be relatively easy to understand, manage, and customize, and introducing a labels layer wouldn't help these goals. Woah, that describes the userspace side of AA just fine, it means nothing when it comes

Re: Reading files into LSM

On Wed, May 09, 2007 at 04:10:57PM +0800, Cliffe wrote: This question is similar to my first. I have multiple files (in separate locations) containing policies for confining the same application. How can I read the contents of these files into my LSM? You don't: