Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 12 4月, 2014 4 次提交
  3. 20 3月, 2014 2 次提交
    • P
      selinux: correctly label /proc inodes in use before the policy is loaded · f64410ec
      由 Paul Moore 提交于 
      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: NPaul Moore <pmoore@redhat.com>
Acked-by: NEric Paris <eparis@redhat.com>
      f64410ec
    • 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
  5. 08 3月, 2014 11 次提交
  7. 07 3月, 2014 1 次提交
  9. 05 3月, 2014 1 次提交
  11. 17 2月, 2014 1 次提交
  13. 06 2月, 2014 1 次提交
  15. 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
  17. 03 1月, 2014 3 次提交
  19. 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
  21. 24 12月, 2013 4 次提交
  23. 20 12月, 2013 1 次提交
  25. 17 12月, 2013 2 次提交
  27. 16 12月, 2013 1 次提交
  29. 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
  31. 13 12月, 2013 4 次提交