1. 12 5月, 2015 3 次提交
  2. 17 4月, 2015 1 次提交
  3. 16 4月, 2015 3 次提交
  4. 15 4月, 2015 1 次提交
    • R
      lsm: copy comm before calling audit_log to avoid race in string printing · 5deeb5ce
      Richard Guy Briggs 提交于
      When task->comm is passed directly to audit_log_untrustedstring() without
      getting a copy or using the task_lock, there is a race that could happen that
      would output a NULL (\0) in the middle of the output string that would
      effectively truncate the rest of the report text after the comm= field in the
      audit log message, losing fields.
      
      Using get_task_comm() to get a copy while acquiring the task_lock to prevent
      this and to prevent the result from being a mixture of old and new values of
      comm would incur potentially unacceptable overhead, considering that the value
      can be influenced by userspace and therefore untrusted anyways.
      
      Copy the value before passing it to audit_log_untrustedstring() ensures that a
      local copy is used to calculate the length *and* subsequently printed.  Even if
      this value contains a mix of old and new values, it will only calculate and
      copy up to the first NULL, preventing the rest of the audit log message being
      truncated.
      
      Use a second local copy of comm to avoid a race between the first and second
      calls to audit_log_untrustedstring() with comm.
      Reported-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NRichard Guy Briggs <rgb@redhat.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      5deeb5ce
  5. 14 4月, 2015 1 次提交
  6. 13 4月, 2015 3 次提交
  7. 12 4月, 2015 3 次提交
  8. 09 4月, 2015 5 次提交
  9. 08 4月, 2015 3 次提交
  10. 07 4月, 2015 5 次提交
  11. 05 4月, 2015 1 次提交
  12. 26 3月, 2015 1 次提交
  13. 24 3月, 2015 4 次提交
    • P
      smack: Fix gcc warning from unused smack_syslog_lock mutex in smackfs.c · f43b65ba
      Paul Gortmaker 提交于
      In commit 00f84f3f ("Smack: Make the
      syslog control configurable") this mutex was added, but the rest of
      the final commit never actually made use of it, resulting in:
      
       In file included from include/linux/mutex.h:29:0,
                        from include/linux/notifier.h:13,
                        from include/linux/memory_hotplug.h:6,
                        from include/linux/mmzone.h:821,
                        from include/linux/gfp.h:5,
                        from include/linux/slab.h:14,
                        from include/linux/security.h:27,
                        from security/smack/smackfs.c:21:
       security/smack/smackfs.c:63:21: warning: ‘smack_syslog_lock’ defined but not used [-Wunused-variable]
        static DEFINE_MUTEX(smack_syslog_lock);
                            ^
      
      A git grep shows no other instances/references to smack_syslog_lock.
      Delete it, assuming that the mutex addition was just a leftover from
      an earlier work in progress version of the change.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      f43b65ba
    • C
      Smack: Allow an unconfined label in bringup mode · bf4b2fee
      Casey Schaufler 提交于
      I have vehemently opposed adding a "permissive" mode to Smack
      for the simple reasons that it would be subject to massive abuse
      and that developers refuse to turn it off come product release.
      I still believe that this is true, and still refuse to add a
      general "permissive mode". So don't ask again.
      
      Bumjin Im suggested an approach that addresses most of the concerns,
      and I have implemented it here. I still believe that we'd be better
      off without this sort of thing, but it looks like this minimizes the
      abuse potential.
      
      Firstly, you have to configure Smack Bringup Mode. That allows
      for "release" software to be ammune from abuse. Second, only one
      label gets to be "permissive" at a time. You can use it for
      debugging, but that's about it.
      
      A label written to smackfs/unconfined is treated specially.
      If either the subject or object label of an access check
      matches the "unconfined" label, and the access would not
      have been allowed otherwise an audit record and a console
      message are generated. The audit record "request" string is
      marked with either "(US)" or "(UO)", to indicate that the
      request was granted because of an unconfined label. The
      fact that an inode was accessed by an unconfined label is
      remembered, and subsequent accesses to that "impure"
      object are noted in the log. The impurity is not stored in
      the filesystem, so a file mislabled as a side effect of
      using an unconfined label may still cause concern after
      a reboot.
      
      So, it's there, it's dangerous, but so many application
      developers seem incapable of living without it I have
      given in. I've tried to make it as safe as I can, but
      in the end it's still a chain saw.
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      bf4b2fee
    • J
      Smack: getting the Smack security context of keys · 7fc5f36e
      José Bollo 提交于
      With this commit, the LSM Smack implements the LSM
      side part of the system call keyctl with the action
      code KEYCTL_GET_SECURITY.
      
      It is now possible to get the context of, for example,
      the user session key using the command "keyctl security @s".
      
      The original patch has been modified for merge.
      Signed-off-by: NJosé Bollo <jose.bollo@open.eurogiciel.org>
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      7fc5f36e
    • M
      Smack: Assign smack_known_web as default smk_in label for kernel thread's socket · 7412301b
      Marcin Lis 提交于
      This change fixes the bug associated with sockets owned by kernel threads. These
      sockets, created usually by network devices' drivers tasks, received smk_in
      label from the task that created them - the "floor" label in the most cases. The
      result was that they were not able to receive data packets because of missing
      smack rules. The main reason of the access deny is that the socket smk_in label
      is placed as the object during smk check, kernel thread's capabilities are
      omitted.
      Signed-off-by: NMarcin Lis <m.lis@samsung.com>
      7412301b
  14. 21 3月, 2015 1 次提交
  15. 28 2月, 2015 2 次提交
  16. 23 2月, 2015 3 次提交
    • D
      VFS: (Scripted) Convert S_ISLNK/DIR/REG(dentry->d_inode) to d_is_*(dentry) · e36cb0b8
      David Howells 提交于
      Convert the following where appropriate:
      
       (1) S_ISLNK(dentry->d_inode) to d_is_symlink(dentry).
      
       (2) S_ISREG(dentry->d_inode) to d_is_reg(dentry).
      
       (3) S_ISDIR(dentry->d_inode) to d_is_dir(dentry).  This is actually more
           complicated than it appears as some calls should be converted to
           d_can_lookup() instead.  The difference is whether the directory in
           question is a real dir with a ->lookup op or whether it's a fake dir with
           a ->d_automount op.
      
      In some circumstances, we can subsume checks for dentry->d_inode not being
      NULL into this, provided we the code isn't in a filesystem that expects
      d_inode to be NULL if the dirent really *is* negative (ie. if we're going to
      use d_inode() rather than d_backing_inode() to get the inode pointer).
      
      Note that the dentry type field may be set to something other than
      DCACHE_MISS_TYPE when d_inode is NULL in the case of unionmount, where the VFS
      manages the fall-through from a negative dentry to a lower layer.  In such a
      case, the dentry type of the negative union dentry is set to the same as the
      type of the lower dentry.
      
      However, if you know d_inode is not NULL at the call site, then you can use
      the d_is_xxx() functions even in a filesystem.
      
      There is one further complication: a 0,0 chardev dentry may be labelled
      DCACHE_WHITEOUT_TYPE rather than DCACHE_SPECIAL_TYPE.  Strictly, this was
      intended for special directory entry types that don't have attached inodes.
      
      The following perl+coccinelle script was used:
      
      use strict;
      
      my @callers;
      open($fd, 'git grep -l \'S_IS[A-Z].*->d_inode\' |') ||
          die "Can't grep for S_ISDIR and co. callers";
      @callers = <$fd>;
      close($fd);
      unless (@callers) {
          print "No matches\n";
          exit(0);
      }
      
      my @cocci = (
          '@@',
          'expression E;',
          '@@',
          '',
          '- S_ISLNK(E->d_inode->i_mode)',
          '+ d_is_symlink(E)',
          '',
          '@@',
          'expression E;',
          '@@',
          '',
          '- S_ISDIR(E->d_inode->i_mode)',
          '+ d_is_dir(E)',
          '',
          '@@',
          'expression E;',
          '@@',
          '',
          '- S_ISREG(E->d_inode->i_mode)',
          '+ d_is_reg(E)' );
      
      my $coccifile = "tmp.sp.cocci";
      open($fd, ">$coccifile") || die $coccifile;
      print($fd "$_\n") || die $coccifile foreach (@cocci);
      close($fd);
      
      foreach my $file (@callers) {
          chomp $file;
          print "Processing ", $file, "\n";
          system("spatch", "--sp-file", $coccifile, $file, "--in-place", "--no-show-diff") == 0 ||
      	die "spatch failed";
      }
      
      [AV: overlayfs parts skipped]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      e36cb0b8
    • D
      SELinux: Use d_is_positive() rather than testing dentry->d_inode · 2c616d4d
      David Howells 提交于
      Use d_is_positive() rather than testing dentry->d_inode in SELinux to get rid
      of direct references to d_inode outside of the VFS.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      2c616d4d
    • D
      Smack: Use d_is_positive() rather than testing dentry->d_inode · 8802565b
      David Howells 提交于
      Use d_is_positive() rather than testing dentry->d_inode in Smack to get rid of
      direct references to d_inode outside of the VFS.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      8802565b