1. 02 Mar, 2017 2 commits
  2. 01 Mar, 2017 1 commit
  3. 28 Feb, 2017 1 commit
  4. 25 Feb, 2017 1 commit
  5. 08 Feb, 2017 2 commits
    • Stephen Smalley's avatar
      selinux: fix off-by-one in setprocattr · 0c461cb7
      Stephen Smalley authored
      SELinux tries to support setting/clearing of /proc/pid/attr attributes
      from the shell by ignoring terminating newlines and treating an
      attribute value that begins with a NUL or newline as an attempt to
      clear the attribute.  However, the test for clearing attributes has
      always been wrong; it has an off-by-one error, and this could further
      lead to reading past the end of the allocated buffer since commit
      bb646cdb ("proc_pid_attr_write():
      switch to memdup_user()").  Fix the off-by-one error.
      
      Even with this fix, setting and clearing /proc/pid/attr attributes
      from the shell is not straightforward since the interface does not
      support multiple write() calls (so shells that write the value and
      newline separately will set and then immediately clear the attribute,
      requiring use of echo -n to set the attribute), whereas trying to use
      echo -n "" to clear the attribute causes the shell to skip the
      write() call altogether since POSIX says that a zero-length write
      causes no side effects. Thus, one must use echo -n to set and echo
      without -n to clear, as in the following example:
      $ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate
      $ cat /proc/$$/attr/fscreate
      unconfined_u:object_r:user_home_t:s0
      $ echo "" > /proc/$$/attr/fscreate
      $ cat /proc/$$/attr/fscreate
      
      Note the use of /proc/$$ rather than /proc/self, as otherwise
      the cat command will read its own attribute value, not that of the shell.
      
      There are no users of this facility to my knowledge; possibly we
      should just get rid of it.
      
      UPDATE: Upon further investigation it appears that a local process
      with the process:setfscreate permission can cause a kernel panic as a
      result of this bug.  This patch fixes CVE-2017-2618.
      Signed-off-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      [PM: added the update about CVE-2017-2618 to the commit description]
      Cc: stable@vger.kernel.org # 3.5: d6ea83ecSigned-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      0c461cb7
    • Antonio Murdaca's avatar
      selinux: allow changing labels for cgroupfs · 1ea0ce40
      Antonio Murdaca authored
      This patch allows changing labels for cgroup mounts. Previously, running
      chcon on cgroupfs would throw an "Operation not supported". This patch
      specifically whitelist cgroupfs.
      
      The patch could also allow containers to write only to the systemd cgroup
      for instance, while the other cgroups are kept with cgroup_t label.
      Signed-off-by: default avatarAntonio Murdaca <runcom@redhat.com>
      Acked-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      1ea0ce40
  6. 07 Feb, 2017 1 commit
    • Stephen Smalley's avatar
      selinux: fix off-by-one in setprocattr · a050a570
      Stephen Smalley authored
      SELinux tries to support setting/clearing of /proc/pid/attr attributes
      from the shell by ignoring terminating newlines and treating an
      attribute value that begins with a NUL or newline as an attempt to
      clear the attribute.  However, the test for clearing attributes has
      always been wrong; it has an off-by-one error, and this could further
      lead to reading past the end of the allocated buffer since commit
      bb646cdb ("proc_pid_attr_write():
      switch to memdup_user()").  Fix the off-by-one error.
      
      Even with this fix, setting and clearing /proc/pid/attr attributes
      from the shell is not straightforward since the interface does not
      support multiple write() calls (so shells that write the value and
      newline separately will set and then immediately clear the attribute,
      requiring use of echo -n to set the attribute), whereas trying to use
      echo -n "" to clear the attribute causes the shell to skip the
      write() call altogether since POSIX says that a zero-length write
      causes no side effects. Thus, one must use echo -n to set and echo
      without -n to clear, as in the following example:
      $ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate
      $ cat /proc/$$/attr/fscreate
      unconfined_u:object_r:user_home_t:s0
      $ echo "" > /proc/$$/attr/fscreate
      $ cat /proc/$$/attr/fscreate
      
      Note the use of /proc/$$ rather than /proc/self, as otherwise
      the cat command will read its own attribute value, not that of the shell.
      
      There are no users of this facility to my knowledge; possibly we
      should just get rid of it.
      
      UPDATE: Upon further investigation it appears that a local process
      with the process:setfscreate permission can cause a kernel panic as a
      result of this bug.  This patch fixes CVE-2017-2618.
      Signed-off-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      [PM: added the update about CVE-2017-2618 to the commit description]
      Cc: stable@vger.kernel.org # 3.5: d6ea83ecSigned-off-by: default avatarPaul Moore <paul@paul-moore.com>
      a050a570
  7. 24 Jan, 2017 1 commit
    • Krister Johansen's avatar
      Introduce a sysctl that modifies the value of PROT_SOCK. · 4548b683
      Krister Johansen authored
      Add net.ipv4.ip_unprivileged_port_start, which is a per namespace sysctl
      that denotes the first unprivileged inet port in the namespace.  To
      disable all privileged ports set this to zero.  It also checks for
      overlap with the local port range.  The privileged and local range may
      not overlap.
      
      The use case for this change is to allow containerized processes to bind
      to priviliged ports, but prevent them from ever being allowed to modify
      their container's network configuration.  The latter is accomplished by
      ensuring that the network namespace is not a child of the user
      namespace.  This modification was needed to allow the container manager
      to disable a namespace's priviliged port restrictions without exposing
      control of the network namespace to processes in the user namespace.
      Signed-off-by: default avatarKrister Johansen <kjlx@templeofstupid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4548b683
  8. 23 Jan, 2017 1 commit
  9. 19 Jan, 2017 1 commit
  10. 12 Jan, 2017 2 commits
  11. 09 Jan, 2017 8 commits
    • Gary Tierney's avatar
      selinux: default to security isid in sel_make_bools() if no sid is found · 900fde06
      Gary Tierney authored
      Use SECINITSID_SECURITY as the default SID for booleans which don't have
      a matching SID returned from security_genfs_sid(), also update the
      error message to a warning which matches this.
      
      This prevents the policy failing to load (and consequently the system
      failing to boot) when there is no default genfscon statement matched for
      the selinuxfs in the new policy.
      Signed-off-by: Gary Tierney's avatarGary Tierney <gary.tierney@gmx.com>
      Acked-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      900fde06
    • Gary Tierney's avatar
      selinux: log errors when loading new policy · 4262fb51
      Gary Tierney authored
      Adds error logging to the code paths which can fail when loading a new
      policy in sel_write_load().  If the policy fails to be loaded from
      userspace then a warning message is printed, whereas if a failure occurs
      after loading policy from userspace an error message will be printed
      with details on where policy loading failed (recreating one of /classes/,
      /policy_capabilities/, /booleans/ in the SELinux fs).
      
      Also, if sel_make_bools() fails to obtain an SID for an entry in
      /booleans/* an error will be printed indicating the path of the
      boolean.
      Signed-off-by: Gary Tierney's avatarGary Tierney <gary.tierney@gmx.com>
      Acked-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      4262fb51
    • Stephen Smalley's avatar
      proc,security: move restriction on writing /proc/pid/attr nodes to proc · b21507e2
      Stephen Smalley authored
      Processes can only alter their own security attributes via
      /proc/pid/attr nodes.  This is presently enforced by each individual
      security module and is also imposed by the Linux credentials
      implementation, which only allows a task to alter its own credentials.
      Move the check enforcing this restriction from the individual
      security modules to proc_pid_attr_write() before calling the security hook,
      and drop the unnecessary task argument to the security hook since it can
      only ever be the current task.
      Signed-off-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      Acked-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Acked-by: default avatarJohn Johansen <john.johansen@canonical.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      b21507e2
    • Stephen Smalley's avatar
      selinux: clean up cred usage and simplify · be0554c9
      Stephen Smalley authored
      SELinux was sometimes using the task "objective" credentials when
      it could/should use the "subjective" credentials.  This was sometimes
      hidden by the fact that we were unnecessarily passing around pointers
      to the current task, making it appear as if the task could be something
      other than current, so eliminate all such passing of current.  Inline
      various permission checking helper functions that can be reduced to a
      single avc_has_perm() call.
      
      Since the credentials infrastructure only allows a task to alter
      its own credentials, we can always assume that current must be the same
      as the target task in selinux_setprocattr after the check. We likely
      should move this check from selinux_setprocattr() to proc_pid_attr_write()
      and drop the task argument to the security hook altogether; it can only
      serve to confuse things.
      Signed-off-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      be0554c9
    • Stephen Smalley's avatar
      selinux: allow context mounts on tmpfs, ramfs, devpts within user namespaces · 01593d32
      Stephen Smalley authored
      commit aad82892 ("selinux: Add support for
      unprivileged mounts from user namespaces") prohibited any use of context
      mount options within non-init user namespaces.  However, this breaks
      use of context mount options for tmpfs mounts within user namespaces,
      which are being used by Docker/runc.  There is no reason to block such
      usage for tmpfs, ramfs or devpts.  Exempt these filesystem types
      from this restriction.
      
      Before:
      sh$ userns_child_exec  -p -m -U -M '0 1000 1' -G '0 1000 1' bash
      sh# mount -t tmpfs -o context=system_u:object_r:user_tmp_t:s0:c13 none /tmp
      mount: tmpfs is write-protected, mounting read-only
      mount: cannot mount tmpfs read-only
      
      After:
      sh$ userns_child_exec  -p -m -U -M '0 1000 1' -G '0 1000 1' bash
      sh# mount -t tmpfs -o context=system_u:object_r:user_tmp_t:s0:c13 none /tmp
      sh# ls -Zd /tmp
      unconfined_u:object_r:user_tmp_t:s0:c13 /tmp
      Signed-off-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      01593d32
    • Stephen Smalley's avatar
      selinux: handle ICMPv6 consistently with ICMP · ef37979a
      Stephen Smalley authored
      commit 79c8b348f215 ("selinux: support distinctions among all network
      address families") mapped datagram ICMP sockets to the new icmp_socket
      security class, but left ICMPv6 sockets unchanged.  This change fixes
      that oversight to handle both kinds of sockets consistently.
      Signed-off-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      ef37979a
    • liuyq's avatar
      selinux: add security in-core xattr support for tracefs · a2c7c6fb
      liuyq authored
      Since kernel 4.1 ftrace is supported as a new separate filesystem. It
      gets automatically mounted by the kernel under the old path
      /sys/kernel/debug/tracing. Because it lives now on a separate filesystem
      SELinux needs to be updated to also support setting SELinux labels
      on tracefs inodes.  This is required for compatibility in Android
      when moving to Linux 4.1 or newer.
      Signed-off-by: liuyq's avatarYongqin Liu <yongqin.liu@linaro.org>
      Signed-off-by: default avatarWilliam Roberts <william.c.roberts@intel.com>
      Acked-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      a2c7c6fb
    • Stephen Smalley's avatar
      selinux: support distinctions among all network address families · da69a530
      Stephen Smalley authored
      Extend SELinux to support distinctions among all network address families
      implemented by the kernel by defining new socket security classes
      and mapping to them. Otherwise, many sockets are mapped to the generic
      socket class and are indistinguishable in policy.  This has come up
      previously with regard to selectively allowing access to bluetooth sockets,
      and more recently with regard to selectively allowing access to AF_ALG
      sockets.  Guido Trentalancia submitted a patch that took a similar approach
      to add only support for distinguishing AF_ALG sockets, but this generalizes
      his approach to handle all address families implemented by the kernel.
      Socket security classes are also added for ICMP and SCTP sockets.
      Socket security classes were not defined for AF_* values that are reserved
      but unimplemented in the kernel, e.g. AF_NETBEUI, AF_SECURITY, AF_ASH,
      AF_ECONET, AF_SNA, AF_WANPIPE.
      
      Backward compatibility is provided by only enabling the finer-grained
      socket classes if a new policy capability is set in the policy; older
      policies will behave as before.  The legacy redhat1 policy capability
      that was only ever used in testing within Fedora for ptrace_child
      is reclaimed for this purpose; as far as I can tell, this policy
      capability is not enabled in any supported distro policy.
      
      Add a pair of conditional compilation guards to detect when new AF_* values
      are added so that we can update SELinux accordingly rather than having to
      belatedly update it long after new address families are introduced.
      Signed-off-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      da69a530
  12. 21 Dec, 2016 1 commit
    • Paul Moore's avatar
      selinux: use the kernel headers when building scripts/selinux · bfc5e3a6
      Paul Moore authored
      Commit 3322d0d6 ("selinux: keep SELinux in sync with new capability
      definitions") added a check on the defined capabilities without
      explicitly including the capability header file which caused problems
      when building genheaders for users of clang/llvm.  Resolve this by
      using the kernel headers when building genheaders, which is arguably
      the right thing to do regardless, and explicitly including the
      kernel's capability.h header file in classmap.h.  We also update the
      mdp build, even though it wasn't causing an error we really should
      be using the headers from the kernel we are building.
      Reported-by: default avatarNicolas Iooss <nicolas.iooss@m4x.org>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      bfc5e3a6
  13. 22 Nov, 2016 1 commit
    • Andreas Gruenbacher's avatar
      selinux: Convert isec->lock into a spinlock · 9287aed2
      Andreas Gruenbacher authored
      Convert isec->lock from a mutex into a spinlock.  Instead of holding
      the lock while sleeping in inode_doinit_with_dentry, set
      isec->initialized to LABEL_PENDING and release the lock.  Then, when
      the sid has been determined, re-acquire the lock.  If isec->initialized
      is still set to LABEL_PENDING, set isec->sid; otherwise, the sid has
      been set by another task (LABEL_INITIALIZED) or invalidated
      (LABEL_INVALID) in the meantime.
      
      This fixes a deadlock on gfs2 where
      
       * one task is in inode_doinit_with_dentry -> gfs2_getxattr, holds
         isec->lock, and tries to acquire the inode's glock, and
      
       * another task is in do_xmote -> inode_go_inval ->
         selinux_inode_invalidate_secctx, holds the inode's glock, and
         tries to acquire isec->lock.
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      [PM: minor tweaks to keep checkpatch.pl happy]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      9287aed2
  14. 21 Nov, 2016 1 commit
    • Stephen Smalley's avatar
      selinux: keep SELinux in sync with new capability definitions · 3322d0d6
      Stephen Smalley authored
      When a new capability is defined, SELinux needs to be updated.
      Trigger a build error if a new capability is defined without
      corresponding update to security/selinux/include/classmap.h's
      COMMON_CAP2_PERMS.  This is similar to BUILD_BUG_ON() guards
      in the SELinux nlmsgtab code to ensure that SELinux tracks
      new netlink message types as needed.
      
      Note that there is already a similar build guard in
      security/selinux/hooks.c to detect when more than 64
      capabilities are defined, since that will require adding
      a third capability class to SELinux.
      
      A nicer way to do this would be to extend scripts/selinux/genheaders
      or a similar tool to auto-generate the necessary definitions and code
      for SELinux capability checking from include/uapi/linux/capability.h.
      AppArmor does something similar in its Makefile, although it only
      needs to generate a single table of names.  That is left as future
      work.
      Signed-off-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      [PM: reformat the description to keep checkpatch.pl happy]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      3322d0d6
  15. 20 Nov, 2016 1 commit
    • Stephen Smalley's avatar
      selinux: normalize input to /sys/fs/selinux/enforce · ea49d10e
      Stephen Smalley authored
      At present, one can write any signed integer value to
      /sys/fs/selinux/enforce and it will be stored,
      e.g. echo -1 > /sys/fs/selinux/enforce or echo 2 >
      /sys/fs/selinux/enforce. This makes no real difference
      to the kernel, since it only ever cares if it is zero or non-zero,
      but some userspace code compares it with 1 to decide if SELinux
      is enforcing, and this could confuse it. Only a process that is
      already root and is allowed the setenforce permission in SELinux
      policy can write to /sys/fs/selinux/enforce, so this is not considered
      to be a security issue, but it should be fixed.
      Signed-off-by: Stephen Smalley's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      ea49d10e
  16. 16 Nov, 2016 1 commit
  17. 14 Nov, 2016 4 commits
  18. 20 Oct, 2016 1 commit
  19. 09 Oct, 2016 1 commit
    • Linus Torvalds's avatar
      printk: reinstate KERN_CONT for printing continuation lines · 4bcc595c
      Linus Torvalds authored
      Long long ago the kernel log buffer was a buffered stream of bytes, very
      much like stdio in user space.  It supported log levels by scanning the
      stream and noticing the log level markers at the beginning of each line,
      but if you wanted to print a partial line in multiple chunks, you just
      did multiple printk() calls, and it just automatically worked.
      
      Except when it didn't, and you had very confusing output when different
      lines got all mixed up with each other.  Then you got fragment lines
      mixing with each other, or with non-fragment lines, because it was
      traditionally impossible to tell whether a printk() call was a
      continuation or not.
      
      To at least help clarify the issue of continuation lines, we added a
      KERN_CONT marker back in 2007 to mark continuation lines:
      
        47492527 ("printk: add KERN_CONT annotation").
      
      That continuation marker was initially an empty string, and didn't
      actuall make any semantic difference.  But it at least made it possible
      to annotate the source code, and have check-patch notice that a printk()
      didn't need or want a log level marker, because it was a continuation of
      a previous line.
      
      To avoid the ambiguity between a continuation line that had that
      KERN_CONT marker, and a printk with no level information at all, we then
      in 2009 made KERN_CONT be a real log level marker which meant that we
      could now reliably tell the difference between the two cases.
      
        5fd29d6c ("printk: clean up handling of log-levels and newlines")
      
      and we could take advantage of that to make sure we didn't mix up
      continuation lines with lines that just didn't have any loglevel at all.
      
      Then, in 2012, the kernel log buffer was changed to be a "record" based
      log, where each line was a record that has a loglevel and a timestamp.
      
      You can see the beginning of that conversion in commits
      
        e11fea92 ("kmsg: export printk records to the /dev/kmsg interface")
        7ff9554b ("printk: convert byte-buffer to variable-length record buffer")
      
      with a number of follow-up commits to fix some painful fallout from that
      conversion.  Over all, it took a couple of months to sort out most of
      it.  But the upside was that you could have concurrent readers (and
      writers) of the kernel log and not have lines with mixed output in them.
      
      And one particular pain-point for the record-based kernel logging was
      exactly the fragmentary lines that are generated in smaller chunks.  In
      order to still log them as one recrod, the continuation lines need to be
      attached to the previous record properly.
      
      However the explicit continuation record marker that is actually useful
      for this exact case was actually removed in aroundm the same time by commit
      
        61e99ab8 ("printk: remove the now unnecessary "C" annotation for KERN_CONT")
      
      due to the incorrect belief that KERN_CONT wasn't meaningful.  The
      ambiguity between "is this a continuation line" or "is this a plain
      printk with no log level information" was reintroduced, and in fact
      became an even bigger pain point because there was now the whole
      record-level merging of kernel messages going on.
      
      This patch reinstates the KERN_CONT as a real non-empty string marker,
      so that the ambiguity is fixed once again.
      
      But it's not a plain revert of that original removal: in the four years
      since we made KERN_CONT an empty string again, not only has the format
      of the log level markers changed, we've also had some usage changes in
      this area.
      
      For example, some ACPI code seems to use KERN_CONT _together_ with a log
      level, and now uses both the KERN_CONT marker and (for example) a
      KERN_INFO marker to show that it's an informational continuation of a
      line.
      
      Which is actually not a bad idea - if the continuation line cannot be
      attached to its predecessor, without the log level information we don't
      know what log level to assign to it (and we traditionally just assigned
      it the default loglevel).  So having both a log level and the KERN_CONT
      marker is not necessarily a bad idea, but it does mean that we need to
      actually iterate over potentially multiple markers, rather than just a
      single one.
      
      Also, since KERN_CONT was still conceptually needed, and encouraged, but
      didn't actually _do_ anything, we've also had the reverse problem:
      rather than having too many annotations it has too few, and there is bit
      rot with code that no longer marks the continuation lines with the
      KERN_CONT marker.
      
      So this patch not only re-instates the non-empty KERN_CONT marker, it
      also fixes up the cases of bit-rot I noticed in my own logs.
      
      There are probably other cases where KERN_CONT will be needed to be
      added, either because it is new code that never dealt with the need for
      KERN_CONT, or old code that has bitrotted without anybody noticing.
      
      That said, we should strive to avoid the need for KERN_CONT.  It does
      result in real problems for logging, and should generally not be seen as
      a good feature.  If we some day can get rid of the feature entirely,
      because nobody does any fragmented printk calls, that would be lovely.
      
      But until that point, let's at mark the code that relies on the hacky
      multi-fragment kernel printk's.  Not only does it avoid the ambiguity,
      it also annotates code as "maybe this would be good to fix some day".
      
      (That said, particularly during single-threaded bootup, the downsides of
      KERN_CONT are very limited.  Things get much hairier when you have
      multiple threads going on and user level reading and writing logs too).
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4bcc595c
  20. 08 Oct, 2016 1 commit
  21. 28 Sep, 2016 1 commit
  22. 19 Sep, 2016 1 commit
    • Vivek Goyal's avatar
      lsm,audit,selinux: Introduce a new audit data type LSM_AUDIT_DATA_FILE · 43af5de7
      Vivek Goyal authored
      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: Vivek Goyal's avatarVivek Goyal <vgoyal@redhat.com>
      [PM: slight tweaks to the description to make checkpatch.pl happy]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      43af5de7
  23. 13 Sep, 2016 1 commit
  24. 30 Aug, 2016 1 commit
  25. 29 Aug, 2016 2 commits
  26. 19 Aug, 2016 1 commit