[GITLAB] - UPGRADE TO v12 on Wednesday the 18th of December at 11.30AM

  1. 29 Apr, 2015 1 commit
  2. 19 Apr, 2015 1 commit
  3. 02 Apr, 2015 1 commit
  4. 30 Jan, 2015 1 commit
    • Sasha Levin's avatar
      KEYS: close race between key lookup and freeing · a7033e30
      Sasha Levin authored
      commit a3a8784454692dd72e5d5d34dcdab17b4420e74c upstream.
      
      When a key is being garbage collected, it's key->user would get put before
      the ->destroy() callback is called, where the key is removed from it's
      respective tracking structures.
      
      This leaves a key hanging in a semi-invalid state which leaves a window open
      for a different task to try an access key->user. An example is
      find_keyring_by_name() which would dereference key->user for a key that is
      in the process of being garbage collected (where key->user was freed but
      ->destroy() wasn't called yet - so it's still present in the linked list).
      
      This would cause either a panic, or corrupt memory.
      
      Fixes CVE-2014-9529.
      Signed-off-by: 's avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7033e30
  5. 08 Jan, 2015 1 commit
  6. 14 Nov, 2014 2 commits
    • Stephen Smalley's avatar
      selinux: fix inode security list corruption · e38e049b
      Stephen Smalley authored
      commit 923190d32de4428afbea5e5773be86bea60a9925 upstream.
      
      sb_finish_set_opts() can race with inode_free_security()
      when initializing inode security structures for inodes
      created prior to initial policy load or by the filesystem
      during ->mount().   This appears to have always been
      a possible race, but commit 3dc91d4 ("SELinux:  Fix possible
      NULL pointer dereference in selinux_inode_permission()")
      made it more evident by immediately reusing the unioned
      list/rcu element  of the inode security structure for call_rcu()
      upon an inode_free_security().  But the underlying issue
      was already present before that commit as a possible use-after-free
      of isec.
      
      Shivnandan Kumar reported the list corruption and proposed
      a patch to split the list and rcu elements out of the union
      as separate fields of the inode_security_struct so that setting
      the rcu element would not affect the list element.  However,
      this would merely hide the issue and not truly fix the code.
      
      This patch instead moves up the deletion of the list entry
      prior to dropping the sbsec->isec_lock initially.  Then,
      if the inode is dropped subsequently, there will be no further
      references to the isec.
      Reported-by: 's avatarShivnandan Kumar <shivnandan.k@samsung.com>
      Signed-off-by: 's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: 's avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e38e049b
    • Dmitry Kasatkin's avatar
      evm: check xattr value length and type in evm_inode_setxattr() · bcaf8f4d
      Dmitry Kasatkin authored
      commit 3b1deef6b1289a99505858a3b212c5b50adf0c2f upstream.
      
      evm_inode_setxattr() can be called with no value. The function does not
      check the length so that following command can be used to produce the
      kernel oops: setfattr -n security.evm FOO. This patch fixes it.
      
      Changes in v3:
      * there is no reason to return different error codes for EVM_XATTR_HMAC
        and non EVM_XATTR_HMAC. Remove unnecessary test then.
      
      Changes in v2:
      * testing for validity of xattr type
      
      [ 1106.396921] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [ 1106.398192] IP: [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48
      [ 1106.399244] PGD 29048067 PUD 290d7067 PMD 0
      [ 1106.399953] Oops: 0000 [#1] SMP
      [ 1106.400020] Modules linked in: bridge stp llc evdev serio_raw i2c_piix4 button fuse
      [ 1106.400020] CPU: 0 PID: 3635 Comm: setxattr Not tainted 3.16.0-kds+ #2936
      [ 1106.400020] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [ 1106.400020] task: ffff8800291a0000 ti: ffff88002917c000 task.ti: ffff88002917c000
      [ 1106.400020] RIP: 0010:[<ffffffff812af7b8>]  [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48
      [ 1106.400020] RSP: 0018:ffff88002917fd50  EFLAGS: 00010246
      [ 1106.400020] RAX: 0000000000000000 RBX: ffff88002917fdf8 RCX: 0000000000000000
      [ 1106.400020] RDX: 0000000000000000 RSI: ffffffff818136d3 RDI: ffff88002917fdf8
      [ 1106.400020] RBP: ffff88002917fd68 R08: 0000000000000000 R09: 00000000003ec1df
      [ 1106.400020] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800438a0a00
      [ 1106.400020] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
      [ 1106.400020] FS:  00007f7dfa7d7740(0000) GS:ffff88005da00000(0000) knlGS:0000000000000000
      [ 1106.400020] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1106.400020] CR2: 0000000000000000 CR3: 000000003763e000 CR4: 00000000000006f0
      [ 1106.400020] Stack:
      [ 1106.400020]  ffff8800438a0a00 ffff88002917fdf8 0000000000000000 ffff88002917fd98
      [ 1106.400020]  ffffffff812a1030 ffff8800438a0a00 ffff88002917fdf8 0000000000000000
      [ 1106.400020]  0000000000000000 ffff88002917fde0 ffffffff8116d08a ffff88002917fdc8
      [ 1106.400020] Call Trace:
      [ 1106.400020]  [<ffffffff812a1030>] security_inode_setxattr+0x5d/0x6a
      [ 1106.400020]  [<ffffffff8116d08a>] vfs_setxattr+0x6b/0x9f
      [ 1106.400020]  [<ffffffff8116d1e0>] setxattr+0x122/0x16c
      [ 1106.400020]  [<ffffffff811687e8>] ? mnt_want_write+0x21/0x45
      [ 1106.400020]  [<ffffffff8114d011>] ? __sb_start_write+0x10f/0x143
      [ 1106.400020]  [<ffffffff811687e8>] ? mnt_want_write+0x21/0x45
      [ 1106.400020]  [<ffffffff811687c0>] ? __mnt_want_write+0x48/0x4f
      [ 1106.400020]  [<ffffffff8116d3e6>] SyS_setxattr+0x6e/0xb0
      [ 1106.400020]  [<ffffffff81529da9>] system_call_fastpath+0x16/0x1b
      [ 1106.400020] Code: c3 0f 1f 44 00 00 55 48 89 e5 41 55 49 89 d5 41 54 49 89 fc 53 48 89 f3 48 c7 c6 d3 36 81 81 48 89 df e8 18 22 04 00 85 c0 75 07 <41> 80 7d 00 02 74 0d 48 89 de 4c 89 e7 e8 5a fe ff ff eb 03 83
      [ 1106.400020] RIP  [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48
      [ 1106.400020]  RSP <ffff88002917fd50>
      [ 1106.400020] CR2: 0000000000000000
      [ 1106.428061] ---[ end trace ae08331628ba3050 ]---
      Reported-by: 's avatarJan Kara <jack@suse.cz>
      Signed-off-by: 's avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bcaf8f4d
  7. 17 Sep, 2014 1 commit
    • Eric Paris's avatar
      CAPABILITIES: remove undefined caps from all processes · 76f01555
      Eric Paris authored
      commit 7d8b6c63751cfbbe5eef81a48c22978b3407a3ad upstream.
      
      This is effectively a revert of 7b9a7ec5
      plus fixing it a different way...
      
      We found, when trying to run an application from an application which
      had dropped privs that the kernel does security checks on undefined
      capability bits.  This was ESPECIALLY difficult to debug as those
      undefined bits are hidden from /proc/$PID/status.
      
      Consider a root application which drops all capabilities from ALL 4
      capability sets.  We assume, since the application is going to set
      eff/perm/inh from an array that it will clear not only the defined caps
      less than CAP_LAST_CAP, but also the higher 28ish bits which are
      undefined future capabilities.
      
      The BSET gets cleared differently.  Instead it is cleared one bit at a
      time.  The problem here is that in security/commoncap.c::cap_task_prctl()
      we actually check the validity of a capability being read.  So any task
      which attempts to 'read all things set in bset' followed by 'unset all
      things set in bset' will not even attempt to unset the undefined bits
      higher than CAP_LAST_CAP.
      
      So the 'parent' will look something like:
      CapInh:	0000000000000000
      CapPrm:	0000000000000000
      CapEff:	0000000000000000
      CapBnd:	ffffffc000000000
      
      All of this 'should' be fine.  Given that these are undefined bits that
      aren't supposed to have anything to do with permissions.  But they do...
      
      So lets now consider a task which cleared the eff/perm/inh completely
      and cleared all of the valid caps in the bset (but not the invalid caps
      it couldn't read out of the kernel).  We know that this is exactly what
      the libcap-ng library does and what the go capabilities library does.
      They both leave you in that above situation if you try to clear all of
      you capapabilities from all 4 sets.  If that root task calls execve()
      the child task will pick up all caps not blocked by the bset.  The bset
      however does not block bits higher than CAP_LAST_CAP.  So now the child
      task has bits in eff which are not in the parent.  These are
      'meaningless' undefined bits, but still bits which the parent doesn't
      have.
      
      The problem is now in cred_cap_issubset() (or any operation which does a
      subset test) as the child, while a subset for valid cap bits, is not a
      subset for invalid cap bits!  So now we set durring commit creds that
      the child is not dumpable.  Given it is 'more priv' than its parent.  It
      also means the parent cannot ptrace the child and other stupidity.
      
      The solution here:
      1) stop hiding capability bits in status
      	This makes debugging easier!
      
      2) stop giving any task undefined capability bits.  it's simple, it you
      don't put those invalid bits in CAP_FULL_SET you won't get them in init
      and you won't get them in any other task either.
      	This fixes the cap_issubset() tests and resulting fallout (which
      	made the init task in a docker container untraceable among other
      	things)
      
      3) mask out undefined bits when sys_capset() is called as it might use
      ~0, ~0 to denote 'all capabilities' for backward/forward compatibility.
      	This lets 'capsh --caps="all=eip" -- -c /bin/bash' run.
      
      4) mask out undefined bit when we read a file capability off of disk as
      again likely all bits are set in the xattr for forward/backward
      compatibility.
      	This lets 'setcap all+pe /bin/bash; /bin/bash' run
      Signed-off-by: 's avatarEric Paris <eparis@redhat.com>
      Reviewed-by: 's avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Vagin <avagin@openvz.org>
      Cc: Andrew G. Morgan <morgan@kernel.org>
      Cc: Serge E. Hallyn <serge.hallyn@canonical.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Steve Grubb <sgrubb@redhat.com>
      Cc: Dan Walsh <dwalsh@redhat.com>
      Signed-off-by: 's avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76f01555
  8. 26 Jun, 2014 2 commits
    • Mimi Zohar's avatar
      evm: prohibit userspace writing 'security.evm' HMAC value · bb7f9e5c
      Mimi Zohar authored
      commit 2fb1c9a4f2dbc2f0bd2431c7fa64d0b5483864e4 upstream.
      
      Calculating the 'security.evm' HMAC value requires access to the
      EVM encrypted key.  Only the kernel should have access to it.  This
      patch prevents userspace tools(eg. setfattr, cp --preserve=xattr)
      from setting/modifying the 'security.evm' HMAC value directly.
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb7f9e5c
    • Dmitry Kasatkin's avatar
      ima: introduce ima_kernel_read() · 8b46db3a
      Dmitry Kasatkin authored
      commit 0430e49b6e7c6b5e076be8fefdee089958c9adad upstream.
      
      Commit 8aac6270 "move exit_task_namespaces() outside of exit_notify"
      introduced the kernel opps since the kernel v3.10, which happens when
      Apparmor and IMA-appraisal are enabled at the same time.
      
      ----------------------------------------------------------------------
      [  106.750167] BUG: unable to handle kernel NULL pointer dereference at
      0000000000000018
      [  106.750221] IP: [<ffffffff811ec7da>] our_mnt+0x1a/0x30
      [  106.750241] PGD 0
      [  106.750254] Oops: 0000 [#1] SMP
      [  106.750272] Modules linked in: cuse parport_pc ppdev bnep rfcomm
      bluetooth rpcsec_gss_krb5 nfsd auth_rpcgss nfs_acl nfs lockd sunrpc
      fscache dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp
      kvm_intel snd_hda_codec_hdmi kvm crct10dif_pclmul crc32_pclmul
      ghash_clmulni_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul
      ablk_helper cryptd snd_hda_codec_realtek dcdbas snd_hda_intel
      snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_seq_midi
      snd_seq_midi_event snd_rawmidi psmouse snd_seq microcode serio_raw
      snd_timer snd_seq_device snd soundcore video lpc_ich coretemp mac_hid lp
      parport mei_me mei nbd hid_generic e1000e usbhid ahci ptp hid libahci
      pps_core
      [  106.750658] CPU: 6 PID: 1394 Comm: mysqld Not tainted 3.13.0-rc7-kds+ #15
      [  106.750673] Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A08
      09/19/2012
      [  106.750689] task: ffff8800de804920 ti: ffff880400fca000 task.ti:
      ffff880400fca000
      [  106.750704] RIP: 0010:[<ffffffff811ec7da>]  [<ffffffff811ec7da>]
      our_mnt+0x1a/0x30
      [  106.750725] RSP: 0018:ffff880400fcba60  EFLAGS: 00010286
      [  106.750738] RAX: 0000000000000000 RBX: 0000000000000100 RCX:
      ffff8800d51523e7
      [  106.750764] RDX: ffffffffffffffea RSI: ffff880400fcba34 RDI:
      ffff880402d20020
      [  106.750791] RBP: ffff880400fcbae0 R08: 0000000000000000 R09:
      0000000000000001
      [  106.750817] R10: 0000000000000000 R11: 0000000000000001 R12:
      ffff8800d5152300
      [  106.750844] R13: ffff8803eb8df510 R14: ffff880400fcbb28 R15:
      ffff8800d51523e7
      [  106.750871] FS:  0000000000000000(0000) GS:ffff88040d200000(0000)
      knlGS:0000000000000000
      [  106.750910] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  106.750935] CR2: 0000000000000018 CR3: 0000000001c0e000 CR4:
      00000000001407e0
      [  106.750962] Stack:
      [  106.750981]  ffffffff813434eb ffff880400fcbb20 ffff880400fcbb18
      0000000000000000
      [  106.751037]  ffff8800de804920 ffffffff8101b9b9 0001800000000000
      0000000000000100
      [  106.751093]  0000010000000000 0000000000000002 000000000000000e
      ffff8803eb8df500
      [  106.751149] Call Trace:
      [  106.751172]  [<ffffffff813434eb>] ? aa_path_name+0x2ab/0x430
      [  106.751199]  [<ffffffff8101b9b9>] ? sched_clock+0x9/0x10
      [  106.751225]  [<ffffffff8134a68d>] aa_path_perm+0x7d/0x170
      [  106.751250]  [<ffffffff8101b945>] ? native_sched_clock+0x15/0x80
      [  106.751276]  [<ffffffff8134aa73>] aa_file_perm+0x33/0x40
      [  106.751301]  [<ffffffff81348c5e>] common_file_perm+0x8e/0xb0
      [  106.751327]  [<ffffffff81348d78>] apparmor_file_permission+0x18/0x20
      [  106.751355]  [<ffffffff8130c853>] security_file_permission+0x23/0xa0
      [  106.751382]  [<ffffffff811c77a2>] rw_verify_area+0x52/0xe0
      [  106.751407]  [<ffffffff811c789d>] vfs_read+0x6d/0x170
      [  106.751432]  [<ffffffff811cda31>] kernel_read+0x41/0x60
      [  106.751457]  [<ffffffff8134fd45>] ima_calc_file_hash+0x225/0x280
      [  106.751483]  [<ffffffff8134fb52>] ? ima_calc_file_hash+0x32/0x280
      [  106.751509]  [<ffffffff8135022d>] ima_collect_measurement+0x9d/0x160
      [  106.751536]  [<ffffffff810b552d>] ? trace_hardirqs_on+0xd/0x10
      [  106.751562]  [<ffffffff8134f07c>] ? ima_file_free+0x6c/0xd0
      [  106.751587]  [<ffffffff81352824>] ima_update_xattr+0x34/0x60
      [  106.751612]  [<ffffffff8134f0d0>] ima_file_free+0xc0/0xd0
      [  106.751637]  [<ffffffff811c9635>] __fput+0xd5/0x300
      [  106.751662]  [<ffffffff811c98ae>] ____fput+0xe/0x10
      [  106.751687]  [<ffffffff81086774>] task_work_run+0xc4/0xe0
      [  106.751712]  [<ffffffff81066fad>] do_exit+0x2bd/0xa90
      [  106.751738]  [<ffffffff8173c958>] ? retint_swapgs+0x13/0x1b
      [  106.751763]  [<ffffffff8106780c>] do_group_exit+0x4c/0xc0
      [  106.751788]  [<ffffffff81067894>] SyS_exit_group+0x14/0x20
      [  106.751814]  [<ffffffff8174522d>] system_call_fastpath+0x1a/0x1f
      [  106.751839] Code: c3 0f 1f 44 00 00 55 48 89 e5 e8 22 fe ff ff 5d c3
      0f 1f 44 00 00 55 65 48 8b 04 25 c0 c9 00 00 48 8b 80 28 06 00 00 48 89
      e5 5d <48> 8b 40 18 48 39 87 c0 00 00 00 0f 94 c0 c3 0f 1f 80 00 00 00
      [  106.752185] RIP  [<ffffffff811ec7da>] our_mnt+0x1a/0x30
      [  106.752214]  RSP <ffff880400fcba60>
      [  106.752236] CR2: 0000000000000018
      [  106.752258] ---[ end trace 3c520748b4732721 ]---
      ----------------------------------------------------------------------
      
      The reason for the oops is that IMA-appraisal uses "kernel_read()" when
      file is closed. kernel_read() honors LSM security hook which calls
      Apparmor handler, which uses current->nsproxy->mnt_ns. The 'guilty'
      commit changed the order of cleanup code so that nsproxy->mnt_ns was
      not already available for Apparmor.
      
      Discussion about the issue with Al Viro and Eric W. Biederman suggested
      that kernel_read() is too high-level for IMA. Another issue, except
      security checking, that was identified is mandatory locking. kernel_read
      honors it as well and it might prevent IMA from calculating necessary hash.
      It was suggested to use simplified version of the function without security
      and locking checks.
      
      This patch introduces special version ima_kernel_read(), which skips security
      and mandatory locking checking. It prevents the kernel oops to happen.
      Signed-off-by: 's avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Suggested-by: 's avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b46db3a
  9. 07 Jun, 2014 1 commit
  10. 14 Apr, 2014 1 commit
    • Paul Moore's avatar
      selinux: correctly label /proc inodes in use before the policy is loaded · 913a13b6
      Paul Moore authored
      commit f64410ec665479d7b4b77b7519e814253ed0f686 upstream.
      
      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: 's avatarPaul Moore <pmoore@redhat.com>
      Acked-by: 's avatarEric Paris <eparis@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      913a13b6
  11. 07 Mar, 2014 1 commit
  12. 20 Feb, 2014 1 commit
    • Stephen Smalley's avatar
      SELinux: Fix kernel BUG on empty security contexts. · 95664c96
      Stephen Smalley authored
      commit 2172fa709ab32ca60e86179dc67d0857be8e2c98 upstream.
      
      Setting an empty security context (length=0) on a file will
      lead to incorrectly dereferencing the type and other fields
      of the security context structure, yielding a kernel BUG.
      As a zero-length security context is never valid, just reject
      all such security contexts whether coming from userspace
      via setxattr or coming from the filesystem upon a getxattr
      request by SELinux.
      
      Setting a security context value (empty or otherwise) unknown to
      SELinux in the first place is only possible for a root process
      (CAP_MAC_ADMIN), and, if running SELinux in enforcing mode, only
      if the corresponding SELinux mac_admin permission is also granted
      to the domain by policy.  In Fedora policies, this is only allowed for
      specific domains such as livecd for setting down security contexts
      that are not defined in the build host policy.
      
      Reproducer:
      su
      setenforce 0
      touch foo
      setfattr -n security.selinux foo
      
      Caveat:
      Relabeling or removing foo after doing the above may not be possible
      without booting with SELinux disabled.  Any subsequent access to foo
      after doing the above will also trigger the BUG.
      
      BUG output from Matthew Thode:
      [  473.893141] ------------[ cut here ]------------
      [  473.962110] kernel BUG at security/selinux/ss/services.c:654!
      [  473.995314] invalid opcode: 0000 [#6] SMP
      [  474.027196] Modules linked in:
      [  474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G      D   I
      3.13.0-grsec #1
      [  474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
      07/29/10
      [  474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
      ffff8805f50cd488
      [  474.183707] RIP: 0010:[<ffffffff814681c7>]  [<ffffffff814681c7>]
      context_struct_compute_av+0xce/0x308
      [  474.219954] RSP: 0018:ffff8805c0ac3c38  EFLAGS: 00010246
      [  474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
      0000000000000100
      [  474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
      ffff8805e8aaa000
      [  474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
      0000000000000006
      [  474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
      0000000000000006
      [  474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
      0000000000000000
      [  474.453816] FS:  00007f2e75220800(0000) GS:ffff88061fc00000(0000)
      knlGS:0000000000000000
      [  474.489254] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
      00000000000207f0
      [  474.556058] Stack:
      [  474.584325]  ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
      ffff8805f1190a40
      [  474.618913]  ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
      ffff8805e8aac860
      [  474.653955]  ffff8805c0ac3cb8 000700068113833a ffff880606c75060
      ffff8805c0ac3d94
      [  474.690461] Call Trace:
      [  474.723779]  [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a
      [  474.778049]  [<ffffffff81468824>] security_compute_av+0xf4/0x20b
      [  474.811398]  [<ffffffff8196f419>] avc_compute_av+0x2a/0x179
      [  474.843813]  [<ffffffff8145727b>] avc_has_perm+0x45/0xf4
      [  474.875694]  [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31
      [  474.907370]  [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e
      [  474.938726]  [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22
      [  474.970036]  [<ffffffff811b057d>] vfs_getattr+0x19/0x2d
      [  475.000618]  [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91
      [  475.030402]  [<ffffffff811b063b>] vfs_lstat+0x19/0x1b
      [  475.061097]  [<ffffffff811b077e>] SyS_newlstat+0x15/0x30
      [  475.094595]  [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3
      [  475.148405]  [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b
      [  475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
      8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
      75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
      [  475.255884] RIP  [<ffffffff814681c7>]
      context_struct_compute_av+0xce/0x308
      [  475.296120]  RSP <ffff8805c0ac3c38>
      [  475.328734] ---[ end trace f076482e9d754adc ]---
      Reported-by: 's avatarMatthew Thode <mthode@mthode.org>
      Signed-off-by: 's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: 's avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      95664c96
  13. 13 Feb, 2014 1 commit
    • Tetsuo Handa's avatar
      SELinux: Fix memory leak upon loading policy · f6333f55
      Tetsuo Handa authored
      commit 8ed814602876bec9bad2649ca17f34b499357a1c upstream.
      
      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: 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: 's avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: 's avatarEric Paris <eparis@redhat.com>
      Signed-off-by: 's avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f6333f55
  14. 25 Jan, 2014 1 commit
    • Steven Rostedt's avatar
      SELinux: Fix possible NULL pointer dereference in selinux_inode_permission() · 057f2f7d
      Steven Rostedt authored
      commit 3dc91d4338d698ce77832985f9cb183d8eeaf6be upstream.
      
      While running stress tests on adding and deleting ftrace instances I hit
      this bug:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
        IP: selinux_inode_permission+0x85/0x160
        PGD 63681067 PUD 7ddbe067 PMD 0
        Oops: 0000 [#1] PREEMPT
        CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 3.13.0-rc4-test-00033-gd2a6dde-dirty #20
        Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
        task: ffff880078375800 ti: ffff88007ddb0000 task.ti: ffff88007ddb0000
        RIP: 0010:[<ffffffff812d8bc5>]  [<ffffffff812d8bc5>] selinux_inode_permission+0x85/0x160
        RSP: 0018:ffff88007ddb1c48  EFLAGS: 00010246
        RAX: 0000000000000000 RBX: 0000000000800000 RCX: ffff88006dd43840
        RDX: 0000000000000001 RSI: 0000000000000081 RDI: ffff88006ee46000
        RBP: ffff88007ddb1c88 R08: 0000000000000000 R09: ffff88007ddb1c54
        R10: 6e6576652f6f6f66 R11: 0000000000000003 R12: 0000000000000000
        R13: 0000000000000081 R14: ffff88006ee46000 R15: 0000000000000000
        FS:  00007f217b5b6700(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M
        CR2: 0000000000000020 CR3: 000000006a0fe000 CR4: 00000000000007f0
        Call Trace:
          security_inode_permission+0x1c/0x30
          __inode_permission+0x41/0xa0
          inode_permission+0x18/0x50
          link_path_walk+0x66/0x920
          path_openat+0xa6/0x6c0
          do_filp_open+0x43/0xa0
          do_sys_open+0x146/0x240
          SyS_open+0x1e/0x20
          system_call_fastpath+0x16/0x1b
        Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff
        RIP  selinux_inode_permission+0x85/0x160
        CR2: 0000000000000020
      
      Investigating, I found that the inode->i_security was NULL, and the
      dereference of it caused the oops.
      
      in selinux_inode_permission():
      
      	isec = inode->i_security;
      
      	rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, &avd);
      
      Note, the crash came from stressing the deletion and reading of debugfs
      files.  I was not able to recreate this via normal files.  But I'm not
      sure they are safe.  It may just be that the race window is much harder
      to hit.
      
      What seems to have happened (and what I have traced), is the file is
      being opened at the same time the file or directory is being deleted.
      As the dentry and inode locks are not held during the path walk, nor is
      the inodes ref counts being incremented, there is nothing saving these
      structures from being discarded except for an rcu_read_lock().
      
      The rcu_read_lock() protects against freeing of the inode, but it does
      not protect freeing of the inode_security_struct.  Now if the freeing of
      the i_security happens with a call_rcu(), and the i_security field of
      the inode is not changed (it gets freed as the inode gets freed) then
      there will be no issue here.  (Linus Torvalds suggested not setting the
      field to NULL such that we do not need to check if it is NULL in the
      permission check).
      
      Note, this is a hack, but it fixes the problem at hand.  A real fix is
      to restructure the destroy_inode() to call all the destructor handlers
      from the RCU callback.  But that is a major job to do, and requires a
      lot of work.  For now, we just band-aid this bug with this fix (it
      works), and work on a more maintainable solution in the future.
      
      Link: http://lkml.kernel.org/r/20140109101932.0508dec7@gandalf.local.home
      Link: http://lkml.kernel.org/r/20140109182756.17abaaa8@gandalf.local.homeSigned-off-by: 's avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      057f2f7d
  15. 09 Jan, 2014 4 commits
  16. 20 Dec, 2013 2 commits
    • Paul Moore's avatar
      selinux: handle TCP SYN-ACK packets correctly in selinux_ip_postroute() · 348d7867
      Paul Moore authored
      commit 446b802437f285de68ffb8d6fac3c44c3cab5b04 upstream.
      
      In selinux_ip_postroute() we perform access checks based on the
      packet's security label.  For locally generated traffic we get the
      packet's security label from the associated socket; this works in all
      cases except for TCP SYN-ACK packets.  In the case of SYN-ACK packet's
      the correct security label is stored in the connection's request_sock,
      not the server's socket.  Unfortunately, at the point in time when
      selinux_ip_postroute() is called we can't query the request_sock
      directly, we need to recreate the label using the same logic that
      originally labeled the associated request_sock.
      
      See the inline comments for more explanation.
      Reported-by: 's avatarJanak Desai <Janak.Desai@gtri.gatech.edu>
      Tested-by: 's avatarJanak Desai <Janak.Desai@gtri.gatech.edu>
      Signed-off-by: 's avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      348d7867
    • Paul Moore's avatar
      selinux: handle TCP SYN-ACK packets correctly in selinux_ip_output() · 216c4a77
      Paul Moore authored
      commit 47180068276a04ed31d24fe04c673138208b07a9 upstream.
      
      In selinux_ip_output() we always label packets based on the parent
      socket.  While this approach works in almost all cases, it doesn't
      work in the case of TCP SYN-ACK packets when the correct label is not
      the label of the parent socket, but rather the label of the larval
      socket represented by the request_sock struct.
      
      Unfortunately, since the request_sock isn't queued on the parent
      socket until *after* the SYN-ACK packet is sent, we can't lookup the
      request_sock to determine the correct label for the packet; at this
      point in time the best we can do is simply pass/NF_ACCEPT the packet.
      It must be said that simply passing the packet without any explicit
      labeling action, while far from ideal, is not terrible as the SYN-ACK
      packet will inherit any IP option based labeling from the initial
      connection request so the label *should* be correct and all our
      access controls remain in place so we shouldn't have to worry about
      information leaks.
      Reported-by: 's avatarJanak Desai <Janak.Desai@gtri.gatech.edu>
      Tested-by: 's avatarJanak Desai <Janak.Desai@gtri.gatech.edu>
      Signed-off-by: 's avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      216c4a77
  17. 04 Dec, 2013 1 commit
    • Paul Moore's avatar
      selinux: correct locking in selinux_netlbl_socket_connect) · 6be060cd
      Paul Moore authored
      commit 42d64e1add3a1ce8a787116036163b8724362145 upstream.
      
      The SELinux/NetLabel glue code has a locking bug that affects systems
      with NetLabel enabled, see the kernel error message below.  This patch
      corrects this problem by converting the bottom half socket lock to a
      more conventional, and correct for this call-path, lock_sock() call.
      
       ===============================
       [ INFO: suspicious RCU usage. ]
       3.11.0-rc3+ #19 Not tainted
       -------------------------------
       net/ipv4/cipso_ipv4.c:1928 suspicious rcu_dereference_protected() usage!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 1, debug_locks = 0
       2 locks held by ping/731:
        #0:  (slock-AF_INET/1){+.-...}, at: [...] selinux_netlbl_socket_connect
        #1:  (rcu_read_lock){.+.+..}, at: [<...>] netlbl_conn_setattr
      
       stack backtrace:
       CPU: 1 PID: 731 Comm: ping Not tainted 3.11.0-rc3+ #19
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
        0000000000000001 ffff88006f659d28 ffffffff81726b6a ffff88003732c500
        ffff88006f659d58 ffffffff810e4457 ffff88006b845a00 0000000000000000
        000000000000000c ffff880075aa2f50 ffff88006f659d90 ffffffff8169bec7
       Call Trace:
        [<ffffffff81726b6a>] dump_stack+0x54/0x74
        [<ffffffff810e4457>] lockdep_rcu_suspicious+0xe7/0x120
        [<ffffffff8169bec7>] cipso_v4_sock_setattr+0x187/0x1a0
        [<ffffffff8170f317>] netlbl_conn_setattr+0x187/0x190
        [<ffffffff8170f195>] ? netlbl_conn_setattr+0x5/0x190
        [<ffffffff8131ac9e>] selinux_netlbl_socket_connect+0xae/0xc0
        [<ffffffff81303025>] selinux_socket_connect+0x135/0x170
        [<ffffffff8119d127>] ? might_fault+0x57/0xb0
        [<ffffffff812fb146>] security_socket_connect+0x16/0x20
        [<ffffffff815d3ad3>] SYSC_connect+0x73/0x130
        [<ffffffff81739a85>] ? sysret_check+0x22/0x5d
        [<ffffffff810e5e2d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
        [<ffffffff81373d4e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
        [<ffffffff815d52be>] SyS_connect+0xe/0x10
        [<ffffffff81739a59>] system_call_fastpath+0x16/0x1b
      Signed-off-by: 's avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6be060cd
  18. 29 Nov, 2013 1 commit
  19. 01 Jun, 2013 1 commit
  20. 08 May, 2013 1 commit
  21. 01 May, 2013 1 commit
  22. 29 Apr, 2013 1 commit
  23. 18 Apr, 2013 2 commits
  24. 09 Apr, 2013 1 commit
  25. 08 Apr, 2013 1 commit
  26. 03 Apr, 2013 1 commit
  27. 02 Apr, 2013 1 commit
    • Jeff Layton's avatar
      selinux: make security_sb_clone_mnt_opts return an error on context mismatch · 094f7b69
      Jeff Layton authored
      I had the following problem reported a while back. If you mount the
      same filesystem twice using NFSv4 with different contexts, then the
      second context= option is ignored. For instance:
      
          # mount server:/export /mnt/test1
          # mount server:/export /mnt/test2 -o context=system_u:object_r:tmp_t:s0
          # ls -dZ /mnt/test1
          drwxrwxrwt. root root system_u:object_r:nfs_t:s0       /mnt/test1
          # ls -dZ /mnt/test2
          drwxrwxrwt. root root system_u:object_r:nfs_t:s0       /mnt/test2
      
      When we call into SELinux to set the context of a "cloned" superblock,
      it will currently just bail out when it notices that we're reusing an
      existing superblock. Since the existing superblock is already set up and
      presumably in use, we can't go overwriting its context with the one from
      the "original" sb. Because of this, the second context= option in this
      case cannot take effect.
      
      This patch fixes this by turning security_sb_clone_mnt_opts into an int
      return operation. When it finds that the "new" superblock that it has
      been handed is already set up, it checks to see whether the contexts on
      the old superblock match it. If it does, then it will just return
      success, otherwise it'll return -EBUSY and emit a printk to tell the
      admin why the second mount failed.
      
      Note that this patch may cause casualties. The NFSv4 code relies on
      being able to walk down to an export from the pseudoroot. If you mount
      filesystems that are nested within one another with different contexts,
      then this patch will make those mounts fail in new and "exciting" ways.
      
      For instance, suppose that /export is a separate filesystem on the
      server:
      
          # mount server:/ /mnt/test1
          # mount salusa:/export /mnt/test2 -o context=system_u:object_r:tmp_t:s0
          mount.nfs: an incorrect mount option was specified
      
      ...with the printk in the ring buffer. Because we *might* eventually
      walk down to /mnt/test1/export, the mount is denied due to this patch.
      The second mount needs the pseudoroot superblock, but that's already
      present with the wrong context.
      
      OTOH, if we mount these in the reverse order, then both mounts work,
      because the pseudoroot superblock created when mounting /export is
      discarded once that mount is done. If we then however try to walk into
      that directory, the automount fails for the similar reasons:
      
          # cd /mnt/test1/scratch/
          -bash: cd: /mnt/test1/scratch: Device or resource busy
      
      The story I've gotten from the SELinux folks that I've talked to is that
      this is desirable behavior. In SELinux-land, mounting the same data
      under different contexts is wrong -- there can be only one.
      
      Cc: Steve Dickson <steved@redhat.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: 's avatarJeff Layton <jlayton@redhat.com>
      Acked-by: 's avatarEric Paris <eparis@redhat.com>
      Signed-off-by: 's avatarJames Morris <james.l.morris@oracle.com>
      094f7b69
  28. 28 Mar, 2013 1 commit
  29. 26 Mar, 2013 1 commit
  30. 20 Mar, 2013 4 commits
    • Aristeu Rozanski's avatar
      devcg: propagate local changes down the hierarchy · bd2953eb
      Aristeu Rozanski authored
      This patch makes exception changes to propagate down in hierarchy respecting
      when possible local exceptions.
      
      New exceptions allowing additional access to devices won't be propagated, but
      it'll be possible to add an exception to access all of part of the newly
      allowed device(s).
      
      New exceptions disallowing access to devices will be propagated down and the
      local group's exceptions will be revalidated for the new situation.
      Example:
            A
           / \
              B
      
          group        behavior          exceptions
          A            allow             "b 8:* rwm", "c 116:1 rw"
          B            deny              "c 1:3 rwm", "c 116:2 rwm", "b 3:* rwm"
      
      If a new exception is added to group A:
      	# echo "c 116:* r" > A/devices.deny
      it'll propagate down and after revalidating B's local exceptions, the exception
      "c 116:2 rwm" will be removed.
      
      In case parent's exceptions change and local exceptions are not allowed anymore,
      they'll be deleted.
      
      v7:
      - do not allow behavior change when the cgroup has children
      - update documentation
      
      v6: fixed issues pointed by Serge Hallyn
      - only copy parent's exceptions while propagating behavior if the local
        behavior is different
      - while propagating exceptions, do not clear and copy parent's: it'd be against
        the premise we don't propagate access to more devices
      
      v5: fixed issues pointed by Serge Hallyn
      - updated documentation
      - not propagating when an exception is written to devices.allow
      - when propagating a new behavior, clean the local exceptions list if they're
        for a different behavior
      
      v4: fixed issues pointed by Tejun Heo
      - separated function to walk the tree and collect valid propagation targets
      
      v3: fixed issues pointed by Tejun Heo
      - update documentation
      - move css_online/css_offline changes to a new patch
      - use cgroup_for_each_descendant_pre() instead of own descendant walk
      - move exception_copy rework to a separared patch
      - move exception_clean rework to a separated patch
      
      v2: fixed issues pointed by Tejun Heo
      - instead of keeping the local settings that won't apply anymore, remove them
      
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: 's avatarAristeu Rozanski <aris@redhat.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      bd2953eb
    • Aristeu Rozanski's avatar
      devcg: use css_online and css_offline · 1909554c
      Aristeu Rozanski authored
      Allocate resources and change behavior only when online. This is needed in
      order to determine if a node is suitable for hierarchy propagation or if it's
      being removed.
      
      Locking:
      Both functions take devcgroup_mutex to make changes to device_cgroup structure.
      Hierarchy propagation will also take devcgroup_mutex before walking the
      tree while walking the tree itself is protected by rcu lock.
      Acked-by: 's avatarTejun Heo <tj@kernel.org>
      Acked-by: 's avatarSerge Hallyn <serge.hallyn@canonical.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: 's avatarAristeu Rozanski <aris@redhat.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      1909554c
    • Aristeu Rozanski's avatar
      devcg: prepare may_access() for hierarchy support · c39a2a30
      Aristeu Rozanski authored
      Currently may_access() is only able to verify if an exception is valid for the
      current cgroup, which has the same behavior. With hierarchy, it'll be also used
      to verify if a cgroup local exception is valid towards its cgroup parent, which
      might have different behavior.
      
      v2:
      - updated patch description
      - rebased on top of a new patch to expand the may_access() logic to make it
        more clear
      - fixed argument description order in may_access()
      Acked-by: 's avatarTejun Heo <tj@kernel.org>
      Acked-by: 's avatarSerge Hallyn <serge.hallyn@canonical.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: 's avatarAristeu Rozanski <aris@redhat.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      c39a2a30
    • Aristeu Rozanski's avatar
      devcg: expand may_access() logic · 26898fdf
      Aristeu Rozanski authored
      In order to make the next patch more clear, expand may_access() logic.
      
      v2: may_access() returns bool now
      Acked-by: 's avatarTejun Heo <tj@kernel.org>
      Acked-by: 's avatarSerge Hallyn <serge.hallyn@canonical.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: 's avatarAristeu Rozanski <aris@redhat.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      26898fdf