Skip to content

L
linux
Switch branch/tag
  1. 11 Apr, 2014 7 commits
    • Casey Schaufler's avatar
      Smack: Correctly remove SMACK64TRANSMUTE attribute · f59bdfba
      Casey Schaufler authored 
      Sam Henderson points out that removing the SMACK64TRANSMUTE
attribute from a directory does not result in the directory
transmuting. This is because the inode flag indicating that
the directory is transmuting isn't cleared. The fix is a tad
less than trivial because smk_task and smk_mmap should have
been broken out, too.

Targeted for git://git.gitorious.org/smack-next/kernel.gitSigned-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      f59bdfba
    • José Bollo's avatar
      SMACK: Fix handling value==NULL in post setxattr · 9598f4c9
      José Bollo authored 
      The function `smack_inode_post_setxattr` is called each
time that a setxattr is done, for any value of name.
The kernel allow to put value==NULL when size==0
to set an empty attribute value. The systematic
call to smk_import_entry was causing the dereference
of a NULL pointer hence a KERNEL PANIC!

The problem can be produced easily by issuing the
command `setfattr -n user.data file` under bash prompt
when SMACK is active.

Moving the call to smk_import_entry as proposed by this
patch is correcting the behaviour because the function
smack_inode_post_setxattr is called for the SMACK's
attributes only if the function smack_inode_setxattr validated
the value and its size (what will not be the case when size==0).

It also has a benefical effect to not fill the smack hash
with garbage values coming from any extended attribute
write.

Change-Id: Iaf0039c2be9bccb6cee11c24a3b44d209101fe47
Signed-off-by: default avatarJosé Bollo <jose.bollo@open.eurogiciel.org>
      9598f4c9
    • Pankaj Kumar's avatar
      bugfix patch for SMACK · 5e9ab593
      Pankaj Kumar authored 
      1. In order to remove any SMACK extended attribute from a file, a user
should have CAP_MAC_ADMIN capability. But user without having this
capability is able to remove SMACK64MMAP security attribute.

2. While validating size and value of smack extended attribute in
smack_inode_setsecurity hook, wrong error code is returned.
Signed-off-by: default avatarPankaj Kumar <pamkaj.k2@samsung.com>
Signed-off-by: default avatarHimanshu Shukla <himanshu.sh@samsung.com>
      5e9ab593
    • Lukasz Pawelczyk's avatar
      Smack: adds smackfs/ptrace interface · 66867818
      Lukasz Pawelczyk authored 
      This allows to limit ptrace beyond the regular smack access rules.
It adds a smackfs/ptrace interface that allows smack to be configured
to require equal smack labels for PTRACE_MODE_ATTACH access.
See the changes in Documentation/security/Smack.txt below for details.
Signed-off-by: default avatarLukasz Pawelczyk <l.pawelczyk@partner.samsung.com>
Signed-off-by: default avatarRafal Krypa <r.krypa@samsung.com>
      66867818
    • Lukasz Pawelczyk's avatar
      Smack: unify all ptrace accesses in the smack · 5663884c
      Lukasz Pawelczyk authored 
      The decision whether we can trace a process is made in the following
functions:
	smack_ptrace_traceme()
	smack_ptrace_access_check()
	smack_bprm_set_creds() (in case the proces is traced)

This patch unifies all those decisions by introducing one function that
checks whether ptrace is allowed: smk_ptrace_rule_check().

This makes possible to actually trace with TRACEME where first the
TRACEME itself must be allowed and then exec() on a traced process.

Additional bugs fixed:
- The decision is made according to the mode parameter that is now correctly
  translated from PTRACE_MODE_* to MAY_* instead of being treated 1:1.
  PTRACE_MODE_READ requires MAY_READ.
  PTRACE_MODE_ATTACH requires MAY_READWRITE.
- Add a smack audit log in case of exec() refused by bprm_set_creds().
- Honor the PTRACE_MODE_NOAUDIT flag and don't put smack audit info
  in case this flag is set.
Signed-off-by: default avatarLukasz Pawelczyk <l.pawelczyk@partner.samsung.com>
Signed-off-by: default avatarRafal Krypa <r.krypa@samsung.com>
      5663884c
    • Lukasz Pawelczyk's avatar
      Smack: fix the subject/object order in smack_ptrace_traceme() · 959e6c7f
      Lukasz Pawelczyk authored 
      The order of subject/object is currently reversed in
smack_ptrace_traceme(). It is currently checked if the tracee has a
capability to trace tracer and according to this rule a decision is made
whether the tracer will be allowed to trace tracee.
Signed-off-by: default avatarLukasz Pawelczyk <l.pawelczyk@partner.samsung.com>
Signed-off-by: default avatarRafal Krypa <r.krypa@samsung.com>
      959e6c7f
    • José Bollo's avatar
      Minor improvement of 'smack_sb_kern_mount' · 55dfc5da
      José Bollo authored 
      Fix a possible memory access fault when transmute is true and isp is NULL.
Signed-off-by: default avatarJosé Bollo <jose.bollo@open.eurogiciel.org>
      55dfc5da
  3. 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
  5. 12 Mar, 2014 1 commit
  7. 07 Mar, 2014 14 commits
  9. 04 Mar, 2014 1 commit
  11. 28 Feb, 2014 1 commit
  13. 24 Feb, 2014 1 commit
  15. 17 Feb, 2014 1 commit
  17. 06 Feb, 2014 2 commits
  19. 08 Jan, 2014 1 commit
  21. 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
  23. 06 Jan, 2014 7 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7