[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091217171447.GJ9804@basil.fritz.box>
Date: Thu, 17 Dec 2009 18:14:47 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Mark Seaborn <mrs@...hic-beasts.com>
Cc: Michael Stone <michael@...top.org>,
Andi Kleen <andi@...stfloor.org>,
Ulrich Drepper <drepper@...il.com>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
linux-security-module@...r.kernel.org, David Lang <david@...g.hm>,
Oliver Hartkopp <socketcan@...tkopp.net>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Herbert Xu <herbert@...dor.apana.org.au>,
Valdis Kletnieks <Valdis.Kletnieks@...edu>,
Bryan Donlan <bdonlan@...il.com>,
Evgeniy Polyakov <zbr@...emap.net>,
"C. Scott Ananian" <cscott@...ott.net>,
James Morris <jmorris@...ei.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Bernie Innocenti <bernie@...ewiz.org>
Subject: Re: [PATCH] Security: Add prctl(PR_{GET,SET}_NETWORK) interface.
> This is not very good because in some situations it is useful to disable
> connect() and bind() while still allowing ptracing of other processes. For
> example, Plash creates a new UID for each sandbox and it is possible to use
> strace and gdb inside a sandbox. Currently Plash is not able to block
> network access or allow only limited network access. If you treat ptrace()
> this way we won't have the ability to use strace and gdb while limiting
> network access.
No that's not what the hunk does. I first thought the same. But it actually
just limits these processes from initiating ptracing themselves. You can still
attach gdb/strace to them.
Now I'm not sure if that's closing all holes, but at least I can't come
up with any obvious ones currently. I think I would still prefer a more
general security container in general.
-Andi
--
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists