Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 153
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 07 1月, 2012 1 次提交
  3. 04 1月, 2012 7 次提交
  5. 09 12月, 2011 1 次提交
  7. 07 12月, 2011 1 次提交
    • A
      fix apparmor dereferencing potentially freed dentry, sanitize __d_path() API · 02125a82
      由 Al Viro 提交于 
      __d_path() API is asking for trouble and in case of apparmor d_namespace_path()
getting just that.  The root cause is that when __d_path() misses the root
it had been told to look for, it stores the location of the most remote ancestor
in *root.  Without grabbing references.  Sure, at the moment of call it had
been pinned down by what we have in *path.  And if we raced with umount -l, we
could have very well stopped at vfsmount/dentry that got freed as soon as
prepend_path() dropped vfsmount_lock.

It is safe to compare these pointers with pre-existing (and known to be still
alive) vfsmount and dentry, as long as all we are asking is "is it the same
address?".  Dereferencing is not safe and apparmor ended up stepping into
that.  d_namespace_path() really wants to examine the place where we stopped,
even if it's not connected to our namespace.  As the result, it looked
at ->d_sb->s_magic of a dentry that might've been already freed by that point.
All other callers had been careful enough to avoid that, but it's really
a bad interface - it invites that kind of trouble.

The fix is fairly straightforward, even though it's bigger than I'd like:
	* prepend_path() root argument becomes const.
	* __d_path() is never called with NULL/NULL root.  It was a kludge
to start with.  Instead, we have an explicit function - d_absolute_root().
Same as __d_path(), except that it doesn't get root passed and stops where
it stops.  apparmor and tomoyo are using it.
	* __d_path() returns NULL on path outside of root.  The main
caller is show_mountinfo() and that's precisely what we pass root for - to
skip those outside chroot jail.  Those who don't want that can (and do)
use d_path().
	* __d_path() root argument becomes const.  Everyone agrees, I hope.
	* apparmor does *NOT* try to use __d_path() or any of its variants
when it sees that path->mnt is an internal vfsmount.  In that case it's
definitely not mounted anywhere and dentry_path() is exactly what we want
there.  Handling of sysctl()-triggered weirdness is moved to that place.
	* if apparmor is asked to do pathname relative to chroot jail
and __d_path() tells it we it's not in that jail, the sucker just calls
d_absolute_path() instead.  That's the other remaining caller of __d_path(),
BTW.
        * seq_path_root() does _NOT_ return -ENAMETOOLONG (it's stupid anyway -
the normal seq_file logics will take care of growing the buffer and redoing
the call of ->show() just fine).  However, if it gets path not reachable
from root, it returns SEQ_SKIP.  The only caller adjusted (i.e. stopped
ignoring the return value as it used to do).
Reviewed-by: NJohn Johansen <john.johansen@canonical.com>
ACKed-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org
      02125a82
  9. 29 10月, 2011 1 次提交
  11. 23 10月, 2011 1 次提交
    • T
      TOMOYO: Fix incomplete read after seek. · e0b057b4
      由 Tetsuo Handa 提交于 
      Commit f23571e8 "TOMOYO: Copy directly to userspace buffer." introduced
tomoyo_flush() that flushes data to be read as soon as possible.
tomoyo_select_domain() (which is called by write()) enqueues data which meant
to be read by next read(), but previous read()'s read buffer's size was not
cleared. As a result, since 2.6.36, sequence like

   char *cp = "select global-pid=1\n";
   read(fd, buf1, sizeof(buf1));
   write(fd, cp, strlen(cp));
   read(fd, buf2, sizeof(buf2));

causes enqueued data to be flushed to buf1 rather than buf2.
Fix this bug by clearing read buffer's size upon write() request.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: NJames Morris <jmorris@namei.org>
      e0b057b4
  13. 19 10月, 2011 1 次提交
  15. 12 10月, 2011 2 次提交
  17. 28 9月, 2011 1 次提交
  19. 26 9月, 2011 3 次提交
  21. 19 9月, 2011 1 次提交
    • T
      TOMOYO: Allow specifying domain transition preference. · 6bce98ed
      由 Tetsuo Handa 提交于 
      I got an opinion that it is difficult to use exception policy's domain
transition control directives because they need to match the pathname specified
to "file execute" directives. For example, if "file execute /bin/\*\-ls\-cat"
is given, corresponding domain transition control directive needs to be like
"no_keep_domain /bin/\*\-ls\-cat from any".

If we can specify like below, it will become more convenient.

  file execute /bin/ls keep exec.realpath="/bin/ls" exec.argv[0]="ls"
  file execute /bin/cat keep exec.realpath="/bin/cat" exec.argv[0]="cat"
  file execute /bin/\*\-ls\-cat child
  file execute /usr/sbin/httpd <apache> exec.realpath="/usr/sbin/httpd" exec.argv[0]="/usr/sbin/httpd"

In above examples, "keep" works as if keep_domain is specified, "child" works
as if "no_reset_domain" and "no_initialize_domain" and "no_keep_domain" are
specified, "<apache>" causes domain transition to <apache> domain upon
successful execve() operation.

Moreover, we can also allow transition to different domains based on conditions
like below example.

  <kernel> /usr/sbin/sshd
  file execute /bin/bash <kernel> /usr/sbin/sshd //batch-session exec.argc=2 exec.argv[1]="-c"
  file execute /bin/bash <kernel> /usr/sbin/sshd //root-session task.uid=0
  file execute /bin/bash <kernel> /usr/sbin/sshd //nonroot-session task.uid!=0
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: NJames Morris <jmorris@namei.org>
      6bce98ed
  23. 15 9月, 2011 1 次提交
  25. 14 9月, 2011 5 次提交
  27. 10 9月, 2011 1 次提交
  29. 17 8月, 2011 1 次提交
  31. 08 8月, 2011 1 次提交
  33. 20 7月, 2011 1 次提交
  35. 14 7月, 2011 1 次提交
  37. 11 7月, 2011 5 次提交
  39. 08 7月, 2011 1 次提交
  41. 01 7月, 2011 1 次提交
  43. 30 6月, 2011 2 次提交