1. 20 10月, 2016 1 次提交
  2. 08 10月, 2016 1 次提交
  3. 20 9月, 2016 1 次提交
    • V
      lsm,audit,selinux: Introduce a new audit data type LSM_AUDIT_DATA_FILE · 43af5de7
      Vivek Goyal 提交于
      Right now LSM_AUDIT_DATA_PATH type contains "struct path" in union "u"
      of common_audit_data. This information is used to print path of file
      at the same time it is also used to get to dentry and inode. And this
      inode information is used to get to superblock and device and print
      device information.
      
      This does not work well for layered filesystems like overlay where dentry
      contained in path is overlay dentry and not the real dentry of underlying
      file system. That means inode retrieved from dentry is also overlay
      inode and not the real inode.
      
      SELinux helpers like file_path_has_perm() are doing checks on inode
      retrieved from file_inode(). This returns the real inode and not the
      overlay inode. That means we are doing check on real inode but for audit
      purposes we are printing details of overlay inode and that can be
      confusing while debugging.
      
      Hence, introduce a new type LSM_AUDIT_DATA_FILE which carries file
      information and inode retrieved is real inode using file_inode(). That
      way right avc denied information is given to user.
      
      For example, following is one example avc before the patch.
      
        type=AVC msg=audit(1473360868.399:214): avc:  denied  { read open } for
          pid=1765 comm="cat"
          path="/root/.../overlay/container1/merged/readfile"
          dev="overlay" ino=21443
          scontext=unconfined_u:unconfined_r:test_overlay_client_t:s0:c10,c20
          tcontext=unconfined_u:object_r:test_overlay_files_ro_t:s0
          tclass=file permissive=0
      
      It looks as follows after the patch.
      
        type=AVC msg=audit(1473360017.388:282): avc:  denied  { read open } for
          pid=2530 comm="cat"
          path="/root/.../overlay/container1/merged/readfile"
          dev="dm-0" ino=2377915
          scontext=unconfined_u:unconfined_r:test_overlay_client_t:s0:c10,c20
          tcontext=unconfined_u:object_r:test_overlay_files_ro_t:s0
          tclass=file permissive=0
      
      Notice that now dev information points to "dm-0" device instead of
      "overlay" device. This makes it clear that check failed on underlying
      inode and not on the overlay inode.
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      [PM: slight tweaks to the description to make checkpatch.pl happy]
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      43af5de7
  4. 10 8月, 2016 1 次提交
  5. 09 8月, 2016 4 次提交
  6. 21 7月, 2016 1 次提交
  7. 28 6月, 2016 2 次提交
  8. 25 6月, 2016 1 次提交
  9. 24 6月, 2016 1 次提交
    • A
      fs: Treat foreign mounts as nosuid · 380cf5ba
      Andy Lutomirski 提交于
      If a process gets access to a mount from a different user
      namespace, that process should not be able to take advantage of
      setuid files or selinux entrypoints from that filesystem.  Prevent
      this by treating mounts from other mount namespaces and those not
      owned by current_user_ns() or an ancestor as nosuid.
      
      This will make it safer to allow more complex filesystems to be
      mounted in non-root user namespaces.
      
      This does not remove the need for MNT_LOCK_NOSUID.  The setuid,
      setgid, and file capability bits can no longer be abused if code in
      a user namespace were to clear nosuid on an untrusted filesystem,
      but this patch, by itself, is insufficient to protect the system
      from abuse of files that, when execed, would increase MAC privilege.
      
      As a more concrete explanation, any task that can manipulate a
      vfsmount associated with a given user namespace already has
      capabilities in that namespace and all of its descendents.  If they
      can cause a malicious setuid, setgid, or file-caps executable to
      appear in that mount, then that executable will only allow them to
      elevate privileges in exactly the set of namespaces in which they
      are already privileges.
      
      On the other hand, if they can cause a malicious executable to
      appear with a dangerous MAC label, running it could change the
      caller's security context in a way that should not have been
      possible, even inside the namespace in which the task is confined.
      
      As a hardening measure, this would have made CVE-2014-5207 much
      more difficult to exploit.
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
      Acked-by: NJames Morris <james.l.morris@oracle.com>
      Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      380cf5ba
  10. 27 4月, 2016 2 次提交
  11. 20 4月, 2016 3 次提交
  12. 11 4月, 2016 2 次提交
  13. 06 4月, 2016 4 次提交
  14. 28 3月, 2016 1 次提交
  15. 20 2月, 2016 1 次提交
  16. 28 1月, 2016 1 次提交
  17. 09 1月, 2016 1 次提交
  18. 25 12月, 2015 7 次提交
  19. 09 11月, 2015 1 次提交
  20. 06 11月, 2015 1 次提交
  21. 22 10月, 2015 3 次提交