1. 09 6月, 2013 2 次提交
  2. 10 4月, 2013 1 次提交
  3. 02 4月, 2013 1 次提交
    • J
      selinux: make security_sb_clone_mnt_opts return an error on context mismatch · 094f7b69
      Jeff Layton 提交于
      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: NJeff Layton <jlayton@redhat.com>
      Acked-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      094f7b69
  4. 15 1月, 2013 1 次提交
    • P
      tun: fix LSM/SELinux labeling of tun/tap devices · 5dbbaf2d
      Paul Moore 提交于
      This patch corrects some problems with LSM/SELinux that were introduced
      with the multiqueue patchset.  The problem stems from the fact that the
      multiqueue work changed the relationship between the tun device and its
      associated socket; before the socket persisted for the life of the
      device, however after the multiqueue changes the socket only persisted
      for the life of the userspace connection (fd open).  For non-persistent
      devices this is not an issue, but for persistent devices this can cause
      the tun device to lose its SELinux label.
      
      We correct this problem by adding an opaque LSM security blob to the
      tun device struct which allows us to have the LSM security state, e.g.
      SELinux labeling information, persist for the lifetime of the tun
      device.  In the process we tweak the LSM hooks to work with this new
      approach to TUN device/socket labeling and introduce a new LSM hook,
      security_tun_dev_attach_queue(), to approve requests to attach to a
      TUN queue via TUNSETQUEUE.
      
      The SELinux code has been adjusted to match the new LSM hooks, the
      other LSMs do not make use of the LSM TUN controls.  This patch makes
      use of the recently added "tun_socket:attach_queue" permission to
      restrict access to the TUNSETQUEUE operation.  On older SELinux
      policies which do not define the "tun_socket:attach_queue" permission
      the access control decision for TUNSETQUEUE will be handled according
      to the SELinux policy's unknown permission setting.
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      Acked-by: NEric Paris <eparis@parisplace.org>
      Tested-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5dbbaf2d
  5. 14 12月, 2012 2 次提交
  6. 12 10月, 2012 1 次提交
  7. 21 9月, 2012 1 次提交
  8. 08 9月, 2012 1 次提交
    • M
      ima: add ima_inode_setxattr/removexattr function and calls · 42c63330
      Mimi Zohar 提交于
      Based on xattr_permission comments, the restriction to modify 'security'
      xattr is left up to the underlying fs or lsm. Ensure that not just anyone
      can modify or remove 'security.ima'.
      
      Changelog v1:
      - Unless IMA-APPRAISE is configured, use stub ima_inode_removexattr()/setxattr()
        functions.  (Moved ima_inode_removexattr()/setxattr() to ima_appraise.c)
      
      Changelog:
        - take i_mutex to fix locking (Dmitry Kasatkin)
        - ima_reset_appraise_flags should only be called when modifying or
          removing the 'security.ima' xattr. Requires CAP_SYS_ADMIN privilege.
          (Incorporated fix from Roberto Sassu)
        - Even if allowed to update security.ima, reset the appraisal flags,
          forcing re-appraisal.
        - Replace CAP_MAC_ADMIN with CAP_SYS_ADMIN
        - static inline ima_inode_setxattr()/ima_inode_removexattr() stubs
        - ima_protect_xattr should be static
      Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
      Signed-off-by: NDmitry Kasatkin <dmitry.kasatkin@intel.com>
      42c63330
  9. 06 9月, 2012 1 次提交
  10. 03 7月, 2012 1 次提交
    • P
      security: Fix nommu build. · 75331a59
      Paul Mundt 提交于
      The security + nommu configuration presently blows up with an undefined
      reference to BDI_CAP_EXEC_MAP:
      
      security/security.c: In function 'mmap_prot':
      security/security.c:687:36: error: dereferencing pointer to incomplete type
      security/security.c:688:16: error: 'BDI_CAP_EXEC_MAP' undeclared (first use in this function)
      security/security.c:688:16: note: each undeclared identifier is reported only once for each function it appears in
      
      include backing-dev.h directly to fix it up.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      75331a59
  11. 02 7月, 2012 1 次提交
    • P
      security: Fix nommu build. · 659b5e76
      Paul Mundt 提交于
      The security + nommu configuration presently blows up with an undefined
      reference to BDI_CAP_EXEC_MAP:
      
      security/security.c: In function 'mmap_prot':
      security/security.c:687:36: error: dereferencing pointer to incomplete type
      security/security.c:688:16: error: 'BDI_CAP_EXEC_MAP' undeclared (first use in this function)
      security/security.c:688:16: note: each undeclared identifier is reported only once for each function it appears in
      
      include backing-dev.h directly to fix it up.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      659b5e76
  12. 01 6月, 2012 3 次提交
  13. 10 4月, 2012 1 次提交
  14. 14 2月, 2012 2 次提交
  15. 10 2月, 2012 1 次提交
  16. 07 1月, 2012 1 次提交
  17. 06 1月, 2012 5 次提交
    • E
      security: remove the security_netlink_recv hook as it is equivalent to capable() · fd778461
      Eric Paris 提交于
      Once upon a time netlink was not sync and we had to get the effective
      capabilities from the skb that was being received.  Today we instead get
      the capabilities from the current task.  This has rendered the entire
      purpose of the hook moot as it is now functionally equivalent to the
      capable() call.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      fd778461
    • E
      capabilities: remove all _real_ interfaces · 2920a840
      Eric Paris 提交于
      The name security_real_capable and security_real_capable_noaudit just don't
      make much sense to me.  Convert them to use security_capable and
      security_capable_noaudit.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NSerge E. Hallyn <serge.hallyn@canonical.com>
      2920a840
    • E
      capabilities: introduce security_capable_noaudit · c7eba4a9
      Eric Paris 提交于
      Exactly like security_capable except don't audit any denials.  This is for
      places where the kernel may make decisions about what to do if a task has a
      given capability, but which failing that capability is not a sign of a
      security policy violation.  An example is checking if a task has
      CAP_SYS_ADMIN to lower it's likelyhood of being killed by the oom killer.
      This check is not a security violation if it is denied.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NSerge E. Hallyn <serge.hallyn@canonical.com>
      c7eba4a9
    • E
      capabilities: reverse arguments to security_capable · b7e724d3
      Eric Paris 提交于
      security_capable takes ns, cred, cap.  But the LSM capable() hook takes
      cred, ns, cap.  The capability helper functions also take cred, ns, cap.
      Rather than flip argument order just to flip it back, leave them alone.
      Heck, this should be a little faster since argument will be in the right
      place!
      Signed-off-by: NEric Paris <eparis@redhat.com>
      b7e724d3
    • E
      capabilities: remove the task from capable LSM hook entirely · 6a9de491
      Eric Paris 提交于
      The capabilities framework is based around credentials, not necessarily the
      current task.  Yet we still passed the current task down into LSMs from the
      security_capable() LSM hook as if it was a meaningful portion of the security
      decision.  This patch removes the 'generic' passing of current and instead
      forces individual LSMs to use current explicitly if they think it is
      appropriate.  In our case those LSMs are SELinux and AppArmor.
      
      I believe the AppArmor use of current is incorrect, but that is wholely
      unrelated to this patch.  This patch does not change what AppArmor does, it
      just makes it clear in the AppArmor code that it is doing it.
      
      The SELinux code still uses current in it's audit message, which may also be
      wrong and needs further investigation.  Again this is NOT a change, it may
      have always been wrong, this patch just makes it clear what is happening.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      6a9de491
  18. 04 1月, 2012 7 次提交
  19. 19 10月, 2011 1 次提交
  20. 15 9月, 2011 1 次提交
  21. 10 9月, 2011 1 次提交
  22. 20 7月, 2011 2 次提交
  23. 19 7月, 2011 2 次提交