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

2015-10-06 Thread Greg KH
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

2015-10-04 Thread Greg KH
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 needed by the ker

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

2008-02-24 Thread Greg KH
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 da

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

2008-02-24 Thread Greg KH
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] exporting capability name/code pairs (final)

2008-02-22 Thread Greg KH
On Fri, Feb 22, 2008 at 10:49:26AM +0900, Kohei KaiGai wrote: > [1/3] Add a private data field within kobj_attribute structure. Your "Subject" did not line up with this description, please change your patch sending format for the next time. > This patch add a private data field, declared as void

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

2008-02-22 Thread Greg KH
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 #6)

2008-02-19 Thread Greg KH
On Wed, Feb 20, 2008 at 02:38:16PM +0900, Kohei KaiGai wrote: > Greg KH wrote: >> On Wed, Feb 20, 2008 at 01:38:59PM +0900, Kohei KaiGai wrote: >>>>> If we can have a private member in kobj_attribute, we can found the >>> content >>>>> to be returne

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

2008-02-19 Thread Greg KH
On Wed, Feb 20, 2008 at 01:38:59PM +0900, Kohei KaiGai wrote: > >> If we can have a private member in kobj_attribute, we can found the > content > >> to be returned in a single step. > > > > Ok, again, just send me a patch that adds this functionality and we will > > be very glad to consider it. >

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

2008-02-19 Thread Greg KH
On Mon, Feb 18, 2008 at 05:45:46PM +0900, Kohei KaiGai wrote: > Greg KH wrote: > >>> Also, this code can be cleaned up a lot by just using the basic kobject > >>> attributes, and not rolling your own types here. > >> I replaced my own defined capability_attri

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

2008-02-17 Thread Greg KH
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 t

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

2008-02-15 Thread Greg KH
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"); > > >> + >

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

2008-01-11 Thread Greg KH
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 s

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

2007-12-21 Thread Greg KH
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'? > >

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

2007-12-21 Thread Greg KH
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 s

Re: Possible missing security checks in usbfs?

2007-11-01 Thread Greg KH
On Thu, Nov 01, 2007 at 10:42:02AM -0500, Tan, Lin wrote: > Thank you so much for the response. :) > > I think a malicious driver (in kernel space) can still call these > functions to create a device node, which is dangerous. If this is not > possible, then there is no security hole. I don't see

Re: Possible missing security checks in usbfs?

2007-10-31 Thread Greg KH
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 violat

Re: eradicating out of tree modules

2007-10-30 Thread Greg KH
On Tue, Oct 30, 2007 at 09:11:11AM -0400, linux-os (Dick Johnson) wrote: > I'm sure that the majority of Linux users would never acquire > the 4-board assembly that we use to acquire X-Ray data and > generate real-time images for the baggage scanners in use > at the world's major airports. That ass

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

2007-10-26 Thread Greg KH
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 > >the

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

2007-10-26 Thread Greg KH
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 > >

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

2007-10-25 Thread Greg KH
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

Re: LSM conversion to static interface

2007-10-23 Thread Greg KH
On Tue, Oct 23, 2007 at 12:12:11AM -0700, Crispin Cowan wrote: > * Some people are not comfortable building kernels from source. It > doesn't matter how easy *you* think it is, it is a significant > barrier to entry for a lot of people. Especially if their day job > is systems

Re: LSM conversion to static interface

2007-10-22 Thread Greg KH
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

Re: LSM conversion to static interface

2007-10-22 Thread Greg KH
On Mon, Oct 22, 2007 at 05:50:43PM +0100, Alan Cox wrote: > > For that reason I think keeping LSM is the right thing to do. Wait, we aren't talking about dropping LSM at all, just the "LSM is a module" option. That's it. And by making LSM not a module, we can then go on to fix some of the repor

Re: LSM conversion to static interface

2007-10-21 Thread Greg KH
On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote: > Yes, I think Crispin has succinctly summed it up: irrevocably closing > the LSM prevents commercial customers from using security modules other > than that provided by their Linux distributor. Any "customer" using a security mode

Re: [PATCH] /proc Security Hooks

2007-10-16 Thread Greg KH
On Wed, Oct 17, 2007 at 07:13:57AM +0200, Max Kellermann wrote: > On 2007/10/16 21:54, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > On Tue, 16 Oct 2007 21:38:50 +0200 > > Max Kellermann <[EMAIL PROTECTED]> wrote: > > > This patch attempts to unify duplicated code found in modules like > > > Linu

Re: [TOMOYO 04/15](repost) Utility functions and securityfs interface for policy manipulation.

2007-10-02 Thread Greg KH
On Tue, Oct 02, 2007 at 05:05:44PM +0900, Paul Mundt wrote: > On Tue, Oct 02, 2007 at 04:31:48PM +0900, Kentaro Takeda wrote: > > Common functions for TOMOYO Linux. > > > > TOMOYO Linux uses /sys/kernel/security/tomoyo interface for configuration. > > > This seems like a bit of an abuse of sysfs.

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

2007-09-18 Thread Greg KH
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 $NEW_RANDOM_A

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

2007-07-24 Thread Greg KH
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 <[

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

2007-07-24 Thread Greg KH
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': > security/ro

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

2007-07-20 Thread Greg KH
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

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

2007-07-19 Thread Greg KH
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

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

2007-07-19 Thread Greg KH
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", a

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

2007-07-18 Thread Greg KH
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 th

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

2007-06-26 Thread Greg KH
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: > > > > > > > > >

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

2007-06-16 Thread Greg KH
On Sun, Jun 17, 2007 at 12:44:08AM +0900, Tetsuo Handa wrote: > Greg KH wrote: > > A daemon using inotify can "instantly"[1] detect this and label the file > > properly if it shows up. > > > Same daemon can do the re-label. > > Can the daemon usin

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

2007-06-16 Thread Greg KH
On Sat, Jun 16, 2007 at 01:09:06AM -0700, [EMAIL PROTECTED] wrote: > On Fri, 15 Jun 2007, Greg KH wrote: > > >>> Usually you don't do that by doing a 'mv' otherwise you are almost > >>> guaranteed stale and mixed up content for some period of time

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

2007-06-15 Thread Greg KH
On Fri, Jun 15, 2007 at 09:21:57PM -0400, James Morris wrote: > On Fri, 15 Jun 2007, Greg KH wrote: > > > Oh great, then things like source code control systems would have no > > problems with new files being created under them, or renaming whole > > trees. > > I

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

2007-06-15 Thread Greg KH
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

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

2007-06-15 Thread Greg KH
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. > > > &g

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

2007-06-15 Thread Greg KH
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 t

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

2007-06-15 Thread Greg KH
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 SELinu

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

2007-06-15 Thread Greg KH
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 > &g

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

2007-06-15 Thread Greg KH
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

2007-06-15 Thread Greg KH
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

2007-06-15 Thread Greg KH
On Thu, Jun 14, 2007 at 05:18:43PM -0700, [EMAIL PROTECTED] wrote: > On Thu, 14 Jun 2007, Jack Stone wrote: > > > [EMAIL PROTECTED] wrote: > >> On Sun, 10 Jun 2007, Pavel Machek wrote: > >>> But you have that regex in _user_ space, in a place where policy > >>> is loaded into kernel. > >> > >> th

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

2007-06-15 Thread Greg KH
On Sun, Jun 10, 2007 at 10:09:18AM -0700, Crispin Cowan wrote: > Andreas Gruenbacher wrote: > > On Saturday 09 June 2007 02:17, Greg KH wrote: > > > >> On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote: > >> > >>> AppArmor

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

2007-06-08 Thread Greg KH
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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

2007-06-06 Thread Greg KH
On Wed, Jun 06, 2007 at 09:26:26AM -0400, Stephen Smalley wrote: > On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote: > > On Tuesday 15 May 2007 11:20, Pavel Machek wrote: > > > Hi! > > > > > > > Pathname matching, transition table loading, profile loading and > > > > manipulation. > >

Re: Reading files into LSM

2007-05-09 Thread Greg KH
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: http://ker