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

[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, sorry.

Also, for some devices / use cases, the usermode helper is the solution
(think async loading of firmware when the host wants to do it.)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 kernel.
> 
> Annotate this before we extend firmare_class more,
> as this is expected. We want to generalize the code
> as much as possible.

No, let's leave this as "firmware", as that is what the code does.

If you want to create a "load a resource from the filesystem into the
kernel" subsystem, then let's do that and then port the firmware loader
code over to use that api.

But until then, let's not try to morph the firmware code into something
that it really is not at all at the moment, just because it looks like
this might be a nice thing to do someday in the future.

sorry,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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
 refer this information to identify what entry is accessed.
 It makes easier to share a single method implementation with several similar
 entries, like ones to export the list of capabilities the running kernel
 supports.
 
 Signed-off-by: KaiGai Kohei [EMAIL PROTECTED]
 --
  Documentation/kobject.txt |6 ++

That's good, but you didn't modify the sample/kobject/ file to use the
new void pointer, instead of the strcmp() call.

thanks,

greg k-h
-
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: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)

[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 data field, declared as void *, within 
 kobj_attribute
 structure. The _show() and _store() method in the sysfs attribute entries 
 can
 refer this information to identify what entry is accessed.
 It makes easier to share a single method implementation with several 
 similar
 entries, like ones to export the list of capabilities the running kernel
 supports.

 Signed-off-by: KaiGai Kohei [EMAIL PROTECTED]
 --
  Documentation/kobject.txt |6 ++
 That's good, but you didn't modify the sample/kobject/ file to use the
 new void pointer, instead of the strcmp() call.

 The 3/3 of patches updates sample/kobject to use the new void pointer.
 Do you want it to replace strcmp() examples completly?

Doh, I totally missed that one, very sorry.  I'll be glad to take
patches 1 and 3 in my tree, if you want me to.

thanks,

greg k-h
-
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: [PATCH 2/3] exporting capability name/code pairs (final)

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

thanks,

greg k-h
-
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: [PATCH] exporting capability code/name pairs (try #5.1)

[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 the running kernel.
 
  A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN
  at 2.6.25. However, we have no interface to disclose what capabilities
  are supported on this kernel. Thus, we have to maintain libcap version
  in appropriate one synchronously.
 
  This patch enables libcap to collect the list of capabilities on
  run time, and provide them for users.
  It helps to improve portability of library.
 
  It exports these information as regular files under 
  /sys/kernel/capability.
  The numeric node exports its name, the symbolic node exports its code.
 
  Please consider to put this patch on the queue of 2.6.25.
  Looks good, except don't you need to put the code in commoncap.c under a
  #ifdef SYSFS?
 
 Fair enough.
 I added the #ifdef - #endif block in this patch.

Not needed, if SYSFS is not build in, all of that code pretty much
compiles away to nothing.  So you can drop that.

 
  ===
  [EMAIL PROTECTED] ~]$ ls -R /sys/kernel/capability/
  /sys/kernel/capability/:
  codes  names  version
 
  /sys/kernel/capability/codes:
  0  10  12  14  16  18  2   21  23  25  27  29  30  32  4  6  8
  1  11  13  15  17  19  20  22  24  26  28  3   31  33  5  7  9
 
  /sys/kernel/capability/names:
  cap_audit_controlcap_kill  cap_net_raw cap_sys_nice
  cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
  cap_chowncap_linux_immutable   cap_setgid  cap_sys_ptrace
  cap_dac_override cap_mac_admin cap_setpcap cap_sys_rawio
  cap_dac_read_search  cap_mac_override  cap_setuid  
  cap_sys_resource
  cap_fowner   cap_mknod cap_sys_admin   cap_sys_time
  cap_fsetid   cap_net_admin cap_sys_boot
  cap_sys_tty_config
  cap_ipc_lock cap_net_bind_service  cap_sys_chroot
  cap_ipc_ownercap_net_broadcast cap_sys_module
  [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/version
  0x20071026
  [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/30
  cap_audit_control
  [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_sys_pacct
  20
  [EMAIL PROTECTED] ~]$
  ===
  
  As you are adding new sysfs entries, please also add the needed
  Documentation/ABI/ entries as well.
 
 OK, I'll add a short description at Documentation/ABI/sysfs-kernel-capability 
 .

Thank you.

  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_attribute by kobj_attribute.
 
 It made the patch cleaned up, however, it also impossible to share a single
 _show() method instance, because kobj_attribute does not have any private 
 member.
 Is there any reason why kobj_attribute does not have void *private;?

Because no one has asked for it?  :)

Or you can just do as the example in samples/kobject/ does it, no need
for the void pointer as that code shows.



 
 Thanks,
 Signed-off-by: KaiGai Kohei [EMAIL PROTECTED]
 --
  Documentation/ABI/testing/sysfs-kernel-capability |   23 +
  scripts/mkcapnames.sh |   44 +
  security/Makefile |9 ++
  security/commoncap.c  |  102 
 +
  4 files changed, 178 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/ABI/testing/sysfs-kernel-capability 
 b/Documentation/ABI/testing/sysfs-kernel-capability
 index e69de29..402ef06 100644
 --- a/Documentation/ABI/testing/sysfs-kernel-capability
 +++ b/Documentation/ABI/testing/sysfs-kernel-capability
 @@ -0,0 +1,23 @@
 +What:/sys/kernel/capability
 +Date:Feb 2008
 +Contact: KaiGai Kohei [EMAIL PROTECTED]
 +Description:
 + The entries under /sys/kernel/capability are used to export
 + the list of capabilities the running kernel supported.
 +
 + - /sys/kernel/capability/version
 +   returns the most preferable version number for the
 +   running kernel.
 +   e.g) $ cat /sys/kernel/capability/version
 +0x20071026
 +
 + - /sys/kernel/capability/code/numerical representation
 +   returns its symbolic representation, on reading.
 +   e.g) $ cat /sys/kernel/capability/codes/30
 +cap_audit_control
 +
 + - /sys/kernel/capability/name/symbolic representation
 +   returns its numerical representation, on reading.
 +   e.g) $ cat /sys/kernel/capability/names/cap_sys_pacct
 +20
 +
 diff --git a/scripts/mkcapnames.sh b/scripts

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

[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);
   +
   +return 0;
   
   Should return -EFXXX ..
  
  Oops,
  I fixed it as follows. Thanks for your pointed out.
  
  
  This patch enables to export code/name of capabilities supported
  on the running kernel.
  
  A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN
  at 2.6.25. However, we have no interface to disclose what capabilities
  are supported on this kernel. Thus, we have to maintain libcap version
  in appropriate one synchronously.
  
  This patch enables libcap to collect the list of capabilities on
  run time, and provide them for users.
  It helps to improve portability of library.
  
  It exports these information as regular files under /sys/kernel/capability.
  The numeric node exports its name, the symbolic node exports its code.
  
  Please consider to put this patch on the queue of 2.6.25.
 
 Looks good, except don't you need to put the code in commoncap.c under a
 #ifdef SYSFS?
 
 thanks,
 -serge
 
  
  Thanks,
  ===
  [EMAIL PROTECTED] ~]$ ls -R /sys/kernel/capability/
  /sys/kernel/capability/:
  codes  names  version
  
  /sys/kernel/capability/codes:
  0  10  12  14  16  18  2   21  23  25  27  29  30  32  4  6  8
  1  11  13  15  17  19  20  22  24  26  28  3   31  33  5  7  9
  
  /sys/kernel/capability/names:
  cap_audit_controlcap_kill  cap_net_raw cap_sys_nice
  cap_audit_write  cap_lease cap_setfcap cap_sys_pacct
  cap_chowncap_linux_immutable   cap_setgid  cap_sys_ptrace
  cap_dac_override cap_mac_admin cap_setpcap cap_sys_rawio
  cap_dac_read_search  cap_mac_override  cap_setuid  cap_sys_resource
  cap_fowner   cap_mknod cap_sys_admin   cap_sys_time
  cap_fsetid   cap_net_admin cap_sys_boot
  cap_sys_tty_config
  cap_ipc_lock cap_net_bind_service  cap_sys_chroot
  cap_ipc_ownercap_net_broadcast cap_sys_module
  [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/version
  0x20071026
  [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/codes/30
  cap_audit_control
  [EMAIL PROTECTED] ~]$ cat /sys/kernel/capability/names/cap_sys_pacct
  20
  [EMAIL PROTECTED] ~]$
  ===

As you are adding new sysfs entries, please also add the needed
Documentation/ABI/ entries as well.

Also, this code can be cleaned up a lot by just using the basic kobject
attributes, and not rolling your own types here.

thanks,

greg k-h
-
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: [TOMOYO #6 retry 08/21] Utility functions and policy manipulationinterface.

[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 securityfs, don't worry.
  
 I got a mm-commits mail titled
 + sysfs-make-sysfs_deprecated-depend-on-sysfs.patch added to -mm tree .
 
 Is sysfs going to be deprecated?

No, there is a config option, CONFIG_SYSFS_DEPRECATED which enables some
older sysfs symlinks and layouts.  That patch from Randy Dunlap was just
fixing up some config dependancies that were found, that's all.

 If sysfs becomes not available at /sys/ , where securityfs is going to be 
 mounted?

sysfs is not going away any time soon, don't worry :)

thanks,

greg k-h
-
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: [PATCH] Allow Kconfig to set default mmap_min_addr protection

[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'?
  
  I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is
  base 10 as well
  
  sysfs is autobase, i.e. echo 0xb000 /sys/foo will Do The Right Thing.
 
 yes but if you cat  /proc/sys/vm/mmap_min_addr, it returns in base 10.
 
 sysfs should probably be tuned to output it in a preferred base.

Again, this is sysctl, not sysfs.  two very different things...
-
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: [PATCH] Allow Kconfig to set default mmap_min_addr protection

[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 space to protect from user allocation
  
  Hm, should not this be 'hex'?
 
 I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is
 base 10 as well
 
 sysfs is autobase, i.e. echo 0xb000 /sys/foo will Do The Right Thing.

Hm, no, that is not sysfs doing this, and sysfs is not autobase in all
places.  That is sysctl (/proc/sys/), not sysfs.

thanks,

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

[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 violations.
 
 One such example is as follows.
 
 In linux-2.6.21.5/drivers/usb/core/inode.c, function usbfs_mknod()
 accesses sensitive inode data structure, but is not authorized by a
 security check, at least in one of the call chains: usbfs_mknod -
 usbfs_mkdir - fs_create_by_name - fs_create_file -
 usbfs_add_device- usbfs_notify
 
 Considering the mknod operation for many files systems, such as ext2,
 ext3, and jfs, is authorized by a security check via the vfs_mknod()
 function call, the missing checks in usbfs might be a problem.

As author of usbfs in its current implementation, I don't see where the
problem is.  Only the kernel itself creates files, no userspace process
does, so there is no need to do any kind of security check, right?

Do you see some way an unprivilidged user can create a device node in
usbfs?

thanks,

greg k-h
-
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: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[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
  these kinds of things.  If you know of any that are not on the list at:
  http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
  please feel free to add them, or email me with the needed information
  and I will add them to the list.
 
 That's certainly helpful, but I still think there will always be
 a number of external modules that cannot be merged right now or at
 all, and deliberately making life difficult for out-of-tree code
 maintainers in order to coerce them into submitting their code for
 inclusion in the kernel will not work, it'll only create bad
 feelings.

Do you have examples of proof of this?  Read
Documentation/stable_api_nonsense.txt for how we already make
out-of-tree code developer's lives hell :)

thanks,

greg k-h
-
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: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[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
 these kinds of things.  If you know of any that are not on the list at:
  http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
 please feel free to add them, or email me with the needed information
 and I will add them to the list.
 
 Do I have to at least try to submit it to LKML first before it is
 even considered for the OOT wiki page? :-)

No, you can go hide on your own, that's what the majority of projects on
that page have done :)

But of course, it would be good for you to at least submit it and get
feedback.  Or, if you don't want to do it, the linuxdriverproject
developers would be glad to help you out...

thanks,

greg k-h
-
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: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[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 code should 
  get into the kernel is IMHO a positive point.
 
 This argument seems to start from the assumption that any externally
 maintained kernel code *can* get into the kernel, which doesn't stand
 up to  reality. Once you admit that there is code which, for very good
 reasons, won't ever be accepted into the mainline kernel tree, what you
 are saying amounts to: Code that isn't fit to be included in the
 mainline kernel isn't fit to exist at all.

What kind of code is not accepted into the mainline kernel tree for good
reasons?  What are these reasons?  What specific code are you talking
about?

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 that are not on the list at:
http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
please feel free to add them, or email me with the needed information
and I will add them to the list.

thanks,

greg k-h
-
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: LSM conversion to static interface

[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 by their Linux
  distributor instantly voided all support from that distro by doing that.
 
 This isn't necessarily true.  In fact, I don't think it's even _remotely_
 likely to be typical.

But that is completly true _today_ and is the way that the enterprise
distros work.  Do you have any evidence of it not being the case?

 Security is big business, as is compliance with regulatory law.  Large
 enterprise customers are NOT going to either void their system support
 contracts, or place themselves in jeopardy of failing a SOX audit.

I agree, that is why customers do not load other random security modules
in their kernel today, and why they will not do so tomorrow.  So,
because of that, this whole point about compliance with regulatory law
seems kind of moot :)

Again, LSM isn't going away at all, this is just one config option for
allowing LSM to work as a module that is changing.  If a customer
demands that this feature come back, I'm sure that the big distros will
be the first to push for it.  But currently, given that there are no
known external LSMs being used by customers demanding support, I don't
see what the big issue here really is.

thanks,

greg k-h
-
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: [TOMOYO 14/15] Conditional permission support.

[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_ABUSE_OF_PROCFS and
   $PATH_BASED_LSM_ISSUES.  See the long flamewars on AppArmor for
   discussion on the latter.
  
  Regarding /proc/tomoyo , this is not a big problem.
  It will be possible to create a dedicated filesystem
  after all other remaining problems are solved.
 
 Today, I found that I can use securityfs instead of procfs.
 Creating entry inside securityfs is more preferable way than
 developing a dedicated filesystem, am I right?

Yes, that it what it is there for.

thanks,

greg k-h
-
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: [PATCH try #3] security: Convert LSM into a static interface

[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/root_plug.c:64: undefined reference to `usb_find_device'
 security/root_plug.c:70: undefined reference to `usb_put_dev'

That's wierd, who would have disabled the exports of those functions or
removed the #include linux/usb.h from this file?

thanks,

greg k-h
-
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: [PATCH try #3] security: Convert LSM into a static interface

[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 [EMAIL PROTECTED] 
   wrote:
   
Convert LSM into a static interface
   
   allmodconfig broke
   
   security/built-in.o: In function `rootplug_bprm_check_security':
   security/root_plug.c:64: undefined reference to `usb_find_device'
   security/root_plug.c:70: undefined reference to `usb_put_dev'
  
  That's wierd, who would have disabled the exports of those functions or
  removed the #include linux/usb.h from this file?
  
 
 root_plug is linked into vmlinux and usb is modular.  I did this:
 
 --- a/security/Kconfig~security-convert-lsm-into-a-static-interface-fix-2
 +++ a/security/Kconfig
 @@ -82,7 +82,7 @@ config SECURITY_CAPABILITIES
  
  config SECURITY_ROOTPLUG
   bool Root Plug Support
 - depends on USB  SECURITY
 + depends on USB=y  SECURITY
   help
 This is a sample LSM module that should only be used as such.
 It prevents any programs running with egid == 0 if a specific

That looks correct to me.

thanks,

greg k-h
-
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: [RFC][PATCH] Simplified mandatory access control kernel implementation

[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 aimed at being cross platform, and we hope to have 
 non-Linux folk particpiating actively.  The LSM list may not be the best 
 place for it.

Ah, ok, yeah, that would not make sense then, sorry.

  It's not like we need yet-another-list :)
 
 I'm only subscribed to about 130 lists (on this account).

I don't even want to count mine :)

thanks,

greg k-h
-
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: [PATCH try #3] security: Convert LSM into a static interface

[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
the spacebar more than I should have :)

greg k-h
-
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: [PATCH try #3] security: Convert LSM into a static interface

[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,  and registers itself  as a security 
   module during the TAMOS startup
   process. It also requires that SElinux  be disabled
  
  Please provide a link to the source code, so we can understand how you're 
  using the API.
 
 I think I've found it:
 
 ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_6.0.0/6.0.0-TIV-PDO-FP0007/6.0.0-TIV-PDO-Linux.i386-FP0007.tar
 
 Is that correct?

If so, that code seems to have been run through a code obfuscator and
as such, is not abiding by the GPL.  Can IBM please post the real code
as the GPL requires?

Jim, if you are not the person to make this request too, can you point
me at the correct person?

thanks,

greg k-h
-
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: [RFC][PATCH] Simplified mandatory access control kernel implementation

[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 conflicts in the implementation.
 
 I wonder if it'd be worth setting up a mailing list specifically for this.  
 We currently have too much off-list discussion happening, and nowhere 
 really good to have it on-list.
 
 Thoughts?

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.

It's not like we need yet-another-list :)

thanks,

greg k-h
-
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: [PATCH try #2] security: Convert LSM into a static interface

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

 It's useful for some LSMs to be modular, and LSMs which are y/n 
 options won't 
 have any security architecture issues with unloading at all. 

Which LSMs?  Upstream, there are SELinux and capabilty, and they're not 
safe as loadable modules.

 The mere fact 
 that SELinux cannot be built as a module is a rather weak argument 
 for 
 disabling LSM modules as a whole, so  please don't.

That's not the argument.  Please review the thread.
   
   The argument is 'abuse', right?
   
   Abuse is defined as using the LSM hooks for non-security applications,
   right?
   
   It seems to me that the community is doing a good job of discouraging
   such abuse - by redirecting the wrong-doers to implement proper
   upstream solutions, i.e. taskstats, the audit subsystem, etc.
   
   Such encouragement seems a far better response than taking away freedoms
   and flexibility from everyone.
  
  We are not living in a world where everyone had good intentions...
 
 Oh no, i took a wrong turn somewhere  :)
 
  For _some_ wrong-doers your approach works.
  
  But how do you convince the wrong-doers who do things like putting 
  MODULE_LICENSE(GPL) into their binary-only modules and who ignore you 
  and get away because noone sues them?
 
 Do these really exist?

Yes they do.

 Maybe noone sues them because noone knows who they are...

Maybe no one knows because the people doing the legal action against
them are trying to be nice and do it quietly.

And legal action takes time, it is quite slow going unfortunatly.

Heck, I've seen code that is even properly licensed under the GPL abuse
this security layer for things it was not ment to do at all, and that
stuff comes from _very_ big companies that really should know better...

So I agree that we should unexport it.  It will make people who want to
abuse the interface at least think twice about it.

thanks,

greg I want to mark structures read-only k-h
-
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 39/45] AppArmor: Profile loading and manipulation, pathname matching

[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 
abstractions 
than user-space, provided that the underlying implementation details 
can be 
hidden well enough. The key phrase here is if possible, and in fact 
if 
possible is much too strong: very many things in software are 
possible, 
including user-space drives and a stable kernel module ABI. Some things 
make 
sense; others are genuinely bad ideas while still possible.
  
   In particular, to layer AppArmor on top of SELinux, the following
   problems must be addressed:
   
   * New files: when a file is created, it is labeled according to the
 type of the creating process and the type of the parent directory.
 Applications can also use libselinux to use application logic to
 relabel the file, but that is not 'mandatory' policy, and fails in
 cases like cp and mv. AppArmor lets you create a policy that e..g
 says /home/*/.plan r to permit fingerd to read everyone's .plan
 file, should it ever exist, and you cannot emulate that with 
   SELinux.
  
  A daemon using inotify can instantly[1] detect this and label the file
  properly if it shows up.
 
 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.  Anyone with more SELinux experience want to
verify or fix my understanding of this?

   * Renamed Files: Renaming a file changes the policy with respect to
 that file in AA. To emulate this in SELinux, you would have to
 have a way to instantly re-label the file upon rename.
  
  Same daemon can do the re-label.
 
 ...and no, race there is not important. Attacker may have opened the
 file under old name and is keeping open file descriptor. So this does
 not add a new race relative to AA.

Agreed.

   * Renamed Directory trees: The above problem is compounded with
 directory trees. Changing the name at the top of a large, bushy
 tree can require instant relabeling of millions of files.
  
  Same daemon can do this.  And yes, it might take a ammount of time, but
  the times that this happens in real-life on a production server is
  quite small, if at all.
 
 And now, if you move a tree, there will be old labels for a while. But
 this does not matter, because attacker could be keeping file
 descriptors.

Agreed.

 Only case where attacker _can't_ be keeping file descriptors is newly
 created files in recently moved tree. But as you already create files
 with restrictive permissions, that's okay.
 
 Yes, you may get some -EPERM during the tree move, but AA has that
 problem already, see that when madly moving trees we sometimes
 construct path file never ever had.

Exactly.

I can't think of a real world use of moving directory trees around
that this would come up in as a problem.  Maybe a source code control
system might have this issue for the server, but in a second or two
everything would be working again as the new files would be relabled
correctly.

Can anyone else see a problem with this that I'm just being foolish and
missing?

thanks,

greg k-h
-
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 39/45] AppArmor: Profile loading and manipulation, pathname matching

[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
 that had not found this acceptable, even under the conditions
 outlined. If it meets your needs, I say run with it.

If that segment feels that way, then I imagine AA would not meet their
requirements today due to file handles and other ways of passing around
open files, right?

So, would SELinux today (without this AA-like daemon) fit the
requirements of this segment?

thanks,

greg k-h
-
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 39/45] AppArmor: Profile loading and manipulation, pathname matching

[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
   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
   that had not found this acceptable, even under the conditions
   outlined. If it meets your needs, I say run with it.
  
  If that segment feels that way, then I imagine AA would not meet their
  requirements today due to file handles and other ways of passing around
  open files, right?
  
  So, would SELinux today (without this AA-like daemon) fit the
  requirements of this segment?
  
 
 Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC
 using the features of SELinux where appropriate.

Great, but is there the requirement in the CC stuff such that this type
of delayed re-label that an AA-like daemon would need to do cause that
model to not be able to be certified like your SELinux implementation
is?

As I'm guessing the default label for things like this already work
properly for SELinux, I figure we should be safe, but I don't know those
requirements at all.

thanks,

greg k-h
-
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 39/45] AppArmor: Profile loading and manipulation, pathname matching

[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 SELinux, this is the default today so this
  would happen by default.  Anyone with more SELinux experience want to
  verify or fix my understanding of this?
 
 This is entirely controllable via policy.  That is, you specify that newly 
 create files are labeled to something safe (enforced atomically at the 
 kernel level), and then your userland relabeler would be invoked via 
 inotify to relabel based on your userland pathname specification.
 
 This labeling policy can be as granular as you wish, from the entire 
 filesystem to a single file.  It can also be applied depending on the 
 process which created the file and the directory its created in, ranging 
 from all processes and all directories, to say, just those running as 
 user_t in directories labeled as public_html_t (or whatever).

Oh great, then things like source code control systems would have no
problems with new files being created under them, or renaming whole
trees.

So, so much for the it's going to be too slow re-labeling everything
issue, as it's not even required for almost all situations :)

thanks for letting us know.

greg k-h
-
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 39/45] AppArmor: Profile loading and manipulation, pathname matching

[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 trees. Changing the name at the top of a large, bushy
tree can require instant relabeling of millions of files.
  
  Same daemon can do this.  And yes, it might take a ammount of time, but
  the times that this happens in real-life on a production server is
  quite small, if at all.

  And now, if you move a tree, there will be old labels for a while. But
  this does not matter, because attacker could be keeping file
  descriptors.
  
  Agreed.

 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 are notified that the tree is
moved, your daemon goes through and relabels things as needed.  In the
meantime, before the re-label happens, you might have the wrong label on
things, but somehow SELinux already handles this, so I think you
should be fine.

  Only case where attacker _can't_ be keeping file descriptors is newly
  created files in recently moved tree. But as you already create files
  with restrictive permissions, that's okay.
 
  Yes, you may get some -EPERM during the tree move, but AA has that
  problem already, see that when madly moving trees we sometimes
  construct path file never ever had.
  
  Exactly.

 You are remembering old behavior. The current AppArmor generates only
 correct and consistent paths. If a process has an open file descriptor
 to such a file, they will retain access to it, as we described here:
 http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
 
 Under the restorecon-alike proposal, you have a HUGE open race. This
 post http://bugs.centos.org/view.php?id=1981 describes restorecon
 running for 30 minutes relabeling a file system. That is so far from
 acceptable that it is silly.

Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
only problem we have here, it isn't an issue.

 Of course, this depends on the system in question, but restorecon will
 necessarily need to traverse whatever portions of the filesystem that
 have changed, which can be quite a long time indeed. Any race condition
 measured in minutes is a very serious issue.

Agreed, so we fix that.  There are ways to speed those kinds of things
up quite a bit, and I imagine since the default SELinux behavior doesn't
use restorecon in this kind of use-case, no one has spent the time to do
the work.

  I can't think of a real world use of moving directory trees around
  that this would come up in as a problem.
 Consider this case: We've been developing a new web site for a month,
 and testing it on the server by putting it in a different virtual
 domain. We want to go live at some particular instant by doing an mv of
 the content into our public HTML directory. We simultaneously want to
 take the old web site down and archive it by moving it somewhere else.
 
 Under the restorecon proposal, the web site would be horribly broken
 until restorecon finishes, as various random pages are or are not
 accessible to Apache.

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, not to
mention the issues surrounding paths that might be messed up.

 In a smaller scale example, I want to share some files with a friend. I
 can't be bothered to set up a proper access control system, so I just mv
 the files to ~crispin/public_html/lookitme and in IRC say get it now,
 going away in 10 minutes and then move it out again. Yes, you can
 manually address this by running restorecon ~crispin/public_html. But
 AA does this automatically without having to run any commands.

I'm saying that the daemon will automatically do it for you, you don't
have to do anything on your own.

 You could get restorecon to do this automatically by using inotify.

Yes.

 But to make it as general and transparent as AA is now, you would have
 to run inotify on every directory in the system, with consequences for
 kernel memory and performance.

What kernel memory and performance issues are there?  Your SLED
machine already has inotify running on every directory in the system
today, and you don't seem to have noticed that :)

 This problem does not exist for SELinux, because SELinux does not expect
 access to change based on file names.

Agreed.

 This problem does not exist in the proposed AA implementation, because
 the patch makes the access decision based on the current name of the
 file, so it doesn't have a consistency problem between the file and its
 label; there is no label.

No, that's not the issue here.  The issue is if we can use the model
that AA is exporting to users and apply it to the model that the kernel
uses internally to access internal data

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

[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.
  
  How does inotify not work here?  You are notified that the tree is
  moved, your daemon goes through and relabels things as needed.  In the
  meantime, before the re-label happens, you might have the wrong label on
  things, but somehow SELinux already handles this, so I think you
  should be fine.
 
 SELinux does not relabel files when containing directories move, so it
 is not a problem they've chosen to face.
 
 How well does inotify handle running attached to every directory on a
 typical Linux system?

Look at SLED and Beagle (taking the indexing logic out of the equation.)
It runs good enough that a major Linux vendor is willing to stake its
reputation on it :)

   Under the restorecon-alike proposal, you have a HUGE open race. This
   post http://bugs.centos.org/view.php?id=1981 describes restorecon
   running for 30 minutes relabeling a file system. That is so far from
   acceptable that it is silly.
  
  Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
  only problem we have here, it isn't an issue.
 
 Restorecon traverses the filesystem from a specific down. In order to
 apply to an entire system (as would be necessary to try to emulate
 AppArmor's model using SELinux), restorecon would need to run on vast
 portions of the filesystem often. (mv ~/public_html ~/archived; or tar
 zxvf linux-*.tar.gz, etc.)
 
 I'm not sure we need to run restorecon every time rename(2) is called.

Ok, so we optimize it.  Putting speed issues aside right now as a mere
implementation details, I'm looking for logical reasons the AA model
will not work in this type of system.

   Of course, this depends on the system in question, but restorecon will
   necessarily need to traverse whatever portions of the filesystem that
   have changed, which can be quite a long time indeed. Any race condition
   measured in minutes is a very serious issue.
  
  Agreed, so we fix that.  There are ways to speed those kinds of things
  up quite a bit, and I imagine since the default SELinux behavior doesn't
  use restorecon in this kind of use-case, no one has spent the time to do
  the work.
 
 The time for restorecon is probably best imagined as a kind of 'du' that
 also updates extended attributes as it does its work. It'd be very
 difficult to improve on this.

Is that a bet?  :)

  What kernel memory and performance issues are there?  Your SLED
  machine already has inotify running on every directory in the system
  today, and you don't seem to have noticed that :)
 
 I beg to differ. :)

The Beagle index backend is known to slow things down at times, yes, but
is that the fault of the inotify watches, or the use of mono and a
big-ass database on the system at the same time?

In the original inotify development, the issue was not inotify at all,
unless you have some newer numbers in this regard?

And Crispin mentioned that you all already implemented this.  Do you
have the code around so that we can take a look at it?

thanks,

greg k-h
-
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 39/45] AppArmor: Profile loading and manipulation, pathname matching

[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:
  Only case where attacker _can't_ be keeping file descriptors is newly
  created files in recently moved tree. But as you already create files
  with restrictive permissions, that's okay.
 
  Yes, you may get some -EPERM during the tree move, but AA has that
  problem already, see that when madly moving trees we sometimes
  construct path file never ever had.
 
  Exactly.
 
  You are remembering old behavior. The current AppArmor generates only
  correct and consistent paths. If a process has an open file descriptor
  to such a file, they will retain access to it, as we described here:
  http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
 
  Under the restorecon-alike proposal, you have a HUGE open race. This
  post http://bugs.centos.org/view.php?id=1981 describes restorecon
  running for 30 minutes relabeling a file system. That is so far from
  acceptable that it is silly.
 
  Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
  only problem we have here, it isn't an issue.
 
  how do you 'fix' the laws of physics?
 
  the problem is that with a directory that contains lots of files below it 
  you have to access all the files metadata to change the labels on it. it can 
  take significant amounts of time to walk the entire three and change every 
  file.

Agreed, but you can do this in ways that are faster than others :)

  I can't think of a real world use of moving directory trees around
  that this would come up in as a problem.
  Consider this case: We've been developing a new web site for a month,
  and testing it on the server by putting it in a different virtual
  domain. We want to go live at some particular instant by doing an mv of
  the content into our public HTML directory. We simultaneously want to
  take the old web site down and archive it by moving it somewhere else.
 
  Under the restorecon proposal, the web site would be horribly broken
  until restorecon finishes, as various random pages are or are not
  accessible to Apache.
 
  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, not to
  mention the issues surrounding paths that might be messed up.
 
  on the contrary, useing 'mv' is by far the cleanest way to do this.
 
  mv htdocs htdocs.old;mv htdocs.new htdocs
 
  this makes two atomic changes to the filesystem, but can generate thousands 
  to millions of permission changes as a result.

I agree, and yet, somehow, SELinux today handles this just fine, right?
:)

Let's worry about speed issues later on when a working implementation is
produced, I'm still looking for the logical reason a system like this
can not work properly based on the expected AA interface to users.

thanks,

greg k-h
-
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 39/45] AppArmor: Profile loading and manipulation, pathname matching

[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 to the in-kernel implementation.  There is no
reason that you can't implement the same functionality using some
totally different in-kernel solution if possible.

 SELinux is applicable in areas where AppArmor is not (e.g., MLS), but
 this comes at a cost. For me the question is not SELinux or AppArmor,
 but if AppArmor's security model is a good solution in common
 scenarios. In my opinion, AppArmor is a better answer than SELinux in
 a number of scenarios. This gives it value, nonwithstanding the fact
 that SELinux can be taken further.

I am still not completely certian that we can not properly implement AA
functionality using a SELinux backend solution.  Yes, the current tools
that try to implement this are still lacking, and maybe the kernel needs
to change, but that is possible.

I still want to see a definition of the AA model that we can then use
to try to implement using whatever solution works best.  As that seems
to be missing the current argument of if AA can or can not be
implemented using SELinux or something totally different should be
stopped.

So, AA developers, do you have such a document anywhere?  I know there
are some old research papers, do they properly describe the current
model you are trying to implement here?

thanks,

greg k-h
-
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: Reading files into LSM

[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://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad

-
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