1. 17 Apr, 2006 1 commit
    • Hugh Dickins's avatar
      [PATCH] shmat: stop mprotect from giving write permission to a readonly attachment (CVE-2006-1524) · b78b6af6
      Hugh Dickins authored
      
      
      I found that all of 2.4 and 2.6 have been letting mprotect give write
      permission to a readonly attachment of shared memory, whether or not IPC
      would give the caller that permission.
      
      SUS says "The behaviour of this function [mprotect] is unspecified if the
      mapping was not established by a call to mmap", but I don't think we can
      interpret that as allowing it to subvert IPC permissions.
      
      I haven't tried 2.2, but the 2.2.26 source looks like it gets it right; and
      the patch below reproduces that behaviour - mprotect cannot be used to add
      write permission to a shared memory segment attached readonly.
      
      This patch is simple, and I'm sure it's what we should have done in 2.4.0:
      if you want to go on to switch write permission on and off with mprotect,
      just don't attach the segment readonly in the first place.
      
      However, we could have accumulated apps which attach readonly (even though
      they would be permitted to attach read/write), and which subsequently use
      mprotect to switch write permission on and off: it's not unreasonable.
      
      I was going to add a second ipcperms check in do_shmat, to check for
      writable when readonly, and if not writable find_vma and clear VM_MAYWRITE.
       But security_ipc_permission might do auditing, and it seems wrong to
      report an attempt for write permission when there has been none.  Or we
      could flag the vma as SHM, note the shmid or shp in vm_private_data, and
      then get mprotect to check.
      
      But the patch below is a lot simpler: I'd rather stick with it, if we can
      convince ourselves somehow that it'll be safe.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      b78b6af6
  2. 02 Apr, 2006 1 commit
  3. 26 Mar, 2006 1 commit
  4. 24 Mar, 2006 1 commit
    • Hugh Dickins's avatar
      [PATCH] shmdt: check address alignment · df1e2fb5
      Hugh Dickins authored
      
      
      SUSv3 says the shmdt() function shall fail with EINVAL if the value of
      shmaddr is not the data segment start address of a shared memory segment:
      our sys_shmdt needs to reject a shmaddr which is not page-aligned.
      
      Does it have the potential to break existing apps?
      
      Hugh says
      
        "sys_shmdt() just does the wrong (unexpected) thing with a misaligned
        address: it'll fail on what you might expect it to succeed on, and only
        succeed on what it should definitely fail on.
      
        "That is, I think it behaves as if shmaddr gets rounded up, when the only
        understandable behaviour would be if it rounded it down.
      
        "Which does mean you'd have to be devious to see anything but EINVAL from
        a misaligned shmaddr there, so it's not terribly important."
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      df1e2fb5
  5. 20 Mar, 2006 1 commit
    • Dustin Kirkland's avatar
      [PATCH] Capture selinux subject/object context information. · 8c8570fb
      Dustin Kirkland authored
      
      
      This patch extends existing audit records with subject/object context
      information. Audit records associated with filesystem inodes, ipc, and
      tasks now contain SELinux label information in the field "subj" if the
      item is performing the action, or in "obj" if the item is the receiver
      of an action.
      
      These labels are collected via hooks in SELinux and appended to the
      appropriate record in the audit code.
      
      This additional information is required for Common Criteria Labeled
      Security Protection Profile (LSPP).
      
      [AV: fixed kmalloc flags use]
      [folded leak fixes]
      [folded cleanup from akpm (kfree(NULL)]
      [folded audit_inode_context() leak fix]
      [folded akpm's fix for audit_ipc_perm() definition in case of !CONFIG_AUDIT]
      Signed-off-by: default avatarDustin Kirkland <dustin.kirkland@us.ibm.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      8c8570fb
  6. 10 Feb, 2006 1 commit
  7. 11 Jan, 2006 1 commit
  8. 08 Jan, 2006 1 commit
  9. 06 Jan, 2006 1 commit
    • David Howells's avatar
      [PATCH] NOMMU: Make SYSV IPC SHM use ramfs facilities on NOMMU · b0e15190
      David Howells authored
      
      
      The attached patch makes the SYSV IPC shared memory facilities use the new
      ramfs facilities on a no-MMU kernel.
      
      The following changes are made:
      
       (1) There are now shmem_mmap() and shmem_get_unmapped_area() functions to
           allow the IPC SHM facilities to commune with the tiny-shmem and shmem
           code.
      
       (2) ramfs files now need resizing using do_truncate() rather than by modifying
           the inode size directly (see shmem_file_setup()). This causes ramfs to
           attempt to bind a block of pages of sufficient size to the inode.
      
       (3) CONFIG_SYSVIPC is no longer contingent on CONFIG_MMU.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b0e15190
  10. 07 Nov, 2005 1 commit
  11. 29 Oct, 2005 1 commit
  12. 07 Sep, 2005 1 commit
  13. 01 Aug, 2005 1 commit
  14. 01 May, 2005 1 commit
  15. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4