lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150317022308.24592.35785.stgit@pluto.fritz.box>
Date:	Tue, 17 Mar 2015 10:44:49 +0800
From:	Ian Kent <raven@...maw.net>
To:	Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:	David Howells <dhowells@...hat.com>,
	Oleg Nesterov <onestero@...hat.com>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Benjamin Coddington <bcodding@...hat.com>,
	Al Viro <viro@...IV.linux.org.uk>,
	Jeff Layton <jeff.layton@...marydata.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: [RFC PATCH v4 00/12] Second attempt at contained helper execution

Here is another update to the attempt at contained helper execution.

The main change is I've tried to incorporate Oleg's suggestions
of directly constructing the namespaces rather than using the
open/setns approach and the addition of a namespace hash store.

I'm not particularly happy with this so far as there are a bunch
of ref counted objects and I've almost certainly got that wrong.
But also there are object lifetime problems, some I'm aware of
and for sure others I'm not. Also there is the integrity of the
thread runner process. I haven't performed a double fork on thread
execution, it might be painful to implement, so the thread runner
might end up with the wrong namespace setup if an error occurs.

Anyway, I've decided to stop spinning my wheels with this and
post an update in the hope that others can offer suggestions to
help and, of course, point out things I've missed.

The other change has been to the nfs and KEYS patches.
I've introduced the ability to get a token that can be used to
save namespace information for later execution and I've attempted
to use that for persistent namespace execution, as was discussed
previously.

I'm not at all sure I've done this in a sensible way but the
token does need to be accessible at helper execution time which
is why I've done it this way.

I definitely need advice here too. 

---

Ian Kent (12):
      nsproxy - make create_new_namespaces() non-static
      kmod - rename call_usermodehelper() flags parameter
      vfs - move mnt_namespace definition to linux/mount.h
      kmod - add namespace aware thread runner
      kmod - teach call_usermodehelper() to use a namespace
      kmod - add namespace info store
      kmod - add call_usermodehelper_ns()
      nfsd - use namespace if not executing in init namespace
      nfs - cache_lib use namespace if not executing in init namespace
      nfs - objlayout use namespace if not executing in init namespace
      KEYS - use correct memory allocation flag in call_usermodehelper_keys()
      KEYS: exec request-key within the requesting task's init namespace


 fs/mount.h                   |   12 -
 fs/nfs/cache_lib.c           |    7 +
 fs/nfs/objlayout/objlayout.c |    7 +
 fs/nfsd/netns.h              |    3 
 fs/nfsd/nfs4recover.c        |   48 +++-
 fs/nfsd/nfsctl.c             |    6 +
 include/linux/key.h          |    3 
 include/linux/kmod.h         |   56 +++++
 include/linux/mount.h        |   14 +
 include/linux/nsproxy.h      |    3 
 include/linux/sunrpc/cache.h |    2 
 kernel/kmod.c                |  465 ++++++++++++++++++++++++++++++++++++++++--
 kernel/nsproxy.c             |    2 
 net/sunrpc/cache.c           |    5 
 security/keys/gc.c           |    2 
 security/keys/key.c          |    4 
 security/keys/request_key.c  |   39 +++-
 17 files changed, 620 insertions(+), 58 deletions(-)

--
Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ