Message-ID: <20091228060759.GB13266@heat>
Date:	Mon, 28 Dec 2009 01:07:59 -0500
From:	Michael Stone <michael@...top.org>
To:	Pavel Machek <pavel@....cz>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Andi Kleen <andi@...stfloor.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>,
	Mark Seaborn <mrs@...hic-beasts.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Samir Bellabes <sam@...ack.fr>,
	Casey Schaufler <casey@...aufler-ca.com>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	Michael Stone <michael@...top.org>
Subject: Re: RFC: disablenetwork facility. (v4)

Pavel Machek wrote:
> "I can't see" is not strong enough test, I'd say.
> 
> For example, I can easily imagine something like pam falling back to
> local authentication when network is unavailable. If you disable
> network for su...
> 
> It would be also extremely easy to DoS something like sendmail -- if
> it forks into background and then serves other users' requests.

Pavel,

I spent some time this afternoon reflecting on the scenarios that you sketched
above. This reflection resulted in three concrete responses:

   1. Anyone depending on their network for authentication already has to deal
      with availability faults. disablenetwork doesn't change anything
      fundamental there.

   2. Anyone able to use disablenetwork to block a privilege escalation via su
      or to influence sendmail will be able to disrupt the privilege escalation
      or mail transfer by manipulating the ancestors of su or sendmail in plenty
      of other ways including, for example, via ptrace(), kill(), manipulation
      of PATH, manipulation of X11 events and IPC, manipulation of TTYs, and so
      on. 

   3. As I pointed out before, disablenetwork _is_ controlled by a build-time
      configuration option, its use _is_ still subject to any existing MAC
      policy, and it _is_ easy to control for simply by talking to a
      known-unrestricted process over an unrestricted IPC channel like a Unix
      socket.

and a short meta-response:

   As I see it, the whole point of isolation facilities like disablenetwork is
   to convert _nasty_ faults like secrecy and integrity faults into _local_
   availability faults. Consequently, it is completely unsurprising that we
   can't meet stringent availability goals via isolation without either relaxing
   our other security goals or falling back to strong assumptions about the
   state of our initial environment.

   However, we should not therefore ignore the bottom line which is that
   the additional isolation enabled by disablenetwork represents an excellent
   security risk/reward tradeoff for many people and should be made more widely
   available to these people on these grounds.

Regards,

Michael

P.S. - Thanks again for your assistance in thinking through these scenarios and
in refining the security case for the disablenetwork feature.
--
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