1. 11 Apr, 2014 8 commits
  2. 19 Mar, 2014 3 commits
    • Paul Moore's avatar
      selinux: correctly label /proc inodes in use before the policy is loaded · f64410ec
      Paul Moore authored
      This patch is based on an earlier patch by Eric Paris, he describes
      the problem below:
      
        "If an inode is accessed before policy load it will get placed on a
         list of inodes to be initialized after policy load.  After policy
         load we call inode_doinit() which calls inode_doinit_with_dentry()
         on all inodes accessed before policy load.  In the case of inodes
         in procfs that means we'll end up at the bottom where it does:
      
           /* Default to the fs superblock SID. */
           isec->sid = sbsec->sid;
      
           if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) {
                   if (opt_dentry) {
                           isec->sclass = inode_mode_to_security_class(...)
                           rc = selinux_proc_get_sid(opt_dentry,
                                                     isec->sclass,
                                                     &sid);
                           if (rc)
                                   goto out_unlock;
                           isec->sid = sid;
                   }
           }
      
         Since opt_dentry is null, we'll never call selinux_proc_get_sid()
         and will leave the inode labeled with the label on the superblock.
         I believe a fix would be to mimic the behavior of xattrs.  Look
         for an alias of the inode.  If it can't be found, just leave the
         inode uninitialized (and pick it up later) if it can be found, we
         should be able to call selinux_proc_get_sid() ..."
      
      On a system exhibiting this problem, you will notice a lot of files in
      /proc with the generic "proc_t" type (at least the ones that were
      accessed early in the boot), for example:
      
         # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
         system_u:object_r:proc_t:s0 /proc/sys/kernel/shmmax
      
      However, with this patch in place we see the expected result:
      
         # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
         system_u:object_r:sysctl_kernel_t:s0 /proc/sys/kernel/shmmax
      
      Cc: Eric Paris <eparis@redhat.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Acked-by: default avatarEric Paris <eparis@redhat.com>
      f64410ec
    • Paul Moore's avatar
      selinux: put the mmap() DAC controls before the MAC controls · 98883bfd
      Paul Moore authored
      It turns out that doing the SELinux MAC checks for mmap() before the
      DAC checks was causing users and the SELinux policy folks headaches
      as users were seeing a lot of SELinux AVC denials for the
      memprotect:mmap_zero permission that would have also been denied by
      the normal DAC capability checks (CAP_SYS_RAWIO).
      
      Example:
      
       # cat mmap_test.c
        #include <stdlib.h>
        #include <stdio.h>
        #include <errno.h>
        #include <sys/mman.h>
      
        int main(int argc, char *argv[])
        {
              int rc;
              void *mem;
      
              mem = mmap(0x0, 4096,
                         PROT_READ | PROT_WRITE,
                         MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
              if (mem == MAP_FAILED)
                      return errno;
              printf("mem = %p\n", mem);
              munmap(mem, 4096);
      
              return 0;
        }
       # gcc -g -O0 -o mmap_test mmap_test.c
       # ./mmap_test
       mem = (nil)
       # ausearch -m AVC | grep mmap_zero
       type=AVC msg=audit(...): avc:  denied  { mmap_zero }
         for pid=1025 comm="mmap_test"
         scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
         tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
         tclass=memprotect
      
      This patch corrects things so that when the above example is run by a
      user without CAP_SYS_RAWIO the SELinux AVC is no longer generated as
      the DAC capability check fails before the SELinux permission check.
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Acked-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      98883bfd
    • Paul Moore's avatar
      selinux: fix the output of ./scripts/get_maintainer.pl for SELinux · 2c5f5c9a
      Paul Moore authored
      Correctly tag the SELinux mailing list as moderated for non-subscribers
      and do some shuffling of the SELinux maintainers to try and make things
      more clear when the scripts/get_maintainer.pl script is used.
      
       # ./scripts/get_maintainer.pl -f security/selinux
       Paul Moore <paul@paul-moore.com> (supporter:SELINUX SECURITY...)
       Stephen Smalley <sds@tycho.nsa.gov> (supporter:SELINUX SECURITY...)
       Eric Paris <eparis@parisplace.org> (supporter:SELINUX SECURITY...)
       James Morris <james.l.morris@oracle.com> (supporter:SECURITY SUBSYSTEM)
       selinux@tycho.nsa.gov (moderated list:SELINUX SECURITY...)
       linux-security-module@vger.kernel.org (open list:SECURITY SUBSYSTEM)
       linux-kernel@vger.kernel.org (open list)
      
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: James Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      2c5f5c9a
  3. 12 Mar, 2014 1 commit
  4. 07 Mar, 2014 14 commits
  5. 04 Mar, 2014 1 commit
  6. 28 Feb, 2014 1 commit
  7. 24 Feb, 2014 1 commit
  8. 17 Feb, 2014 1 commit
  9. 06 Feb, 2014 2 commits
  10. 08 Jan, 2014 1 commit
  11. 07 Jan, 2014 1 commit
    • Tetsuo Handa's avatar
      SELinux: Fix memory leak upon loading policy · 8ed81460
      Tetsuo Handa authored
      Hello.
      
      I got below leak with linux-3.10.0-54.0.1.el7.x86_64 .
      
      [  681.903890] kmemleak: 5538 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
      
      Below is a patch, but I don't know whether we need special handing for undoing
      ebitmap_set_bit() call.
      ----------
      >>From fe97527a90fe95e2239dfbaa7558f0ed559c0992 Mon Sep 17 00:00:00 2001
      From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Date: Mon, 6 Jan 2014 16:30:21 +0900
      Subject: [PATCH] SELinux: Fix memory leak upon loading policy
      
      Commit 2463c26d "SELinux: put name based create rules in a hashtable" did not
      check return value from hashtab_insert() in filename_trans_read(). It leaks
      memory if hashtab_insert() returns error.
      
        unreferenced object 0xffff88005c9160d0 (size 8):
          comm "systemd", pid 1, jiffies 4294688674 (age 235.265s)
          hex dump (first 8 bytes):
            57 0b 00 00 6b 6b 6b a5                          W...kkk.
          backtrace:
            [<ffffffff816604ae>] kmemleak_alloc+0x4e/0xb0
            [<ffffffff811cba5e>] kmem_cache_alloc_trace+0x12e/0x360
            [<ffffffff812aec5d>] policydb_read+0xd1d/0xf70
            [<ffffffff812b345c>] security_load_policy+0x6c/0x500
            [<ffffffff812a623c>] sel_write_load+0xac/0x750
            [<ffffffff811eb680>] vfs_write+0xc0/0x1f0
            [<ffffffff811ec08c>] SyS_write+0x4c/0xa0
            [<ffffffff81690419>] system_call_fastpath+0x16/0x1b
            [<ffffffffffffffff>] 0xffffffffffffffff
      
      However, we should not return EEXIST error to the caller, or the systemd will
      show below message and the boot sequence freezes.
      
        systemd[1]: Failed to load SELinux policy. Freezing.
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: default avatarEric Paris <eparis@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      8ed81460
  12. 06 Jan, 2014 6 commits