1. 20 3月, 2014 1 次提交
    • P
      selinux: put the mmap() DAC controls before the MAC controls · 98883bfd
      Paul Moore 提交于
      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: NPaul Moore <pmoore@redhat.com>
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      98883bfd
  2. 08 3月, 2014 11 次提交
  3. 07 3月, 2014 1 次提交
  4. 05 3月, 2014 1 次提交
  5. 17 2月, 2014 1 次提交
  6. 06 2月, 2014 1 次提交
  7. 07 1月, 2014 1 次提交
    • T
      SELinux: Fix memory leak upon loading policy · 8ed81460
      Tetsuo Handa 提交于
      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: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: NEric Paris <eparis@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      8ed81460
  8. 03 1月, 2014 3 次提交
  9. 01 1月, 2014 2 次提交
    • C
      Smack: File receive audit correction · 4482a44f
      Casey Schaufler 提交于
      Eric Paris politely points out:
      
          Inside smack_file_receive() it seems like you are initting the audit
          field with LSM_AUDIT_DATA_TASK.  And then use
          smk_ad_setfield_u_fs_path().
      
          Seems like LSM_AUDIT_DATA_PATH would make more sense.  (and depending
          on how it's used fix a crash...)
      
      He is correct. This puts things in order.
      
      Targeted for git://git.gitorious.org/smack-next/kernel.gitSigned-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      4482a44f
    • C
      Smack: Rationalize mount restrictions · 24ea1b6e
      Casey Schaufler 提交于
      The mount restrictions imposed by Smack rely heavily on the
      use of the filesystem "floor", which is the label that all
      processes writing to the filesystem must have access to. It
      turns out that while the "floor" notion is sound, it has yet
      to be fully implemented and has never been used.
      
      The sb_mount and sb_umount hooks only make sense if the
      filesystem floor is used actively, and it isn't. They can
      be reintroduced if a rational restriction comes up. Until
      then, they get removed.
      
      The sb_kern_mount hook is required for the option processing.
      It is too permissive in the case of unprivileged mounts,
      effectively bypassing the CAP_MAC_ADMIN restrictions if
      any of the smack options are specified. Unprivileged mounts
      are no longer allowed to set Smack filesystem options.
      Additionally, the root and default values are set to the
      label of the caller, in keeping with the policy that objects
      get the label of their creator.
      
      Targeted for git://git.gitorious.org/smack-next/kernel.gitSigned-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      24ea1b6e
  10. 24 12月, 2013 4 次提交
  11. 20 12月, 2013 1 次提交
  12. 17 12月, 2013 2 次提交
  13. 16 12月, 2013 1 次提交
  14. 14 12月, 2013 1 次提交
    • P
      selinux: revert 102aefdd · 4d546f81
      Paul Moore 提交于
      Revert "selinux: consider filesystem subtype in policies"
      
      This reverts commit 102aefdd.
      
      Explanation from Eric Paris:
      
      	SELinux policy can specify if it should use a filesystem's
      	xattrs or not.  In current policy we have a specification that
      	fuse should not use xattrs but fuse.glusterfs should use
      	xattrs.  This patch has a bug in which non-glusterfs
      	filesystems would match the rule saying fuse.glusterfs should
      	use xattrs.  If both fuse and the particular filesystem in
      	question are not written to handle xattr calls during the mount
      	command, they will deadlock.
      
      	I have fixed the bug to do proper matching, however I believe a
      	revert is still the correct solution.  The reason I believe
      	that is because the code still does not work.  The s_subtype is
      	not set until after the SELinux hook which attempts to match on
      	the ".gluster" portion of the rule.  So we cannot match on the
      	rule in question.  The code is useless.
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      4d546f81
  15. 13 12月, 2013 4 次提交
  16. 12 12月, 2013 2 次提交
  17. 11 12月, 2013 1 次提交
  18. 10 12月, 2013 1 次提交
  19. 05 12月, 2013 1 次提交