Date:	Tue, 29 Dec 2009 11:31:04 -0500
From:	Michael Stone <michael@...top.org>
To:	"Serge E. Hallyn" <serue@...ibm.com>
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>,
	Pavel Machek <pavel@....cz>, Al Viro <viro@...IV.linux.org.uk>,
	Michael Stone <michael@...top.org>
Subject: Re: RFC: disablenetwork facility. (v4)

Serge Hallyn writes:
> Quoting Michael Stone (michael@...top.org):
> So far, two defaults have been proposed:
> 
>   default-deny incompatible isolation (Pavel)
>   default-permit incompatible isolation (Michael)
> 
> So far, several signalling mechanisms have been proposed:
> 
>>   1) enabling a kernel config option implies default-permit
>> 
>>         - My favorite; apparently insufficient for Pavel?
>
> default under what conditions?  any setuid?  setuid-root?

My favorite option is that CONFIGURE_SECURITY_DISABLENETWORK causes
disablenetwork to function like djb describes: unprivileged and irrevocable.

(I don't have any setuid executables that I'm worried about breaking; only ones
that I think /should/ be broken and aren't, like ping.)

>   2) default-deny; disablesuid grants disablenetwork
> 
>         - "disablesuid" is my name for the idea of dropping the privilege of
>           exec'ing setuid binaries
> 
>         - Suggested by Pavel and supported by several others.
> 
>         - I think it has the same backwards-compatibility problem as
>           disablenetwork: disablesuid is an isolation primitive.
> 
>   3) default-deny; dropping a capability from the bounding set grants "permit"
> 
>         - Suggested by Serge; seems nicely fine-grained but rather indirect
> 
> Actually I think it's the opposite of what you said here:  so long as the
> capability is in pE, you can regain network.  So it would require a privileged
> process early on (like init or login) to remove the capability from the
> bounding set (bc doing so requires CAP_SETPCAP), but once that was done,
> the resulting process and it's children could not require the capability,
> and, without the capability, could not regain network.  Point being that
> privileged userspace had to actively allow userspace to trap a setuid root
> binary without networking.

What I wrote accurately (if confusingly; sorry!) reflects what you suggest: by
default, the kernel should deny processes from irrevocably dropping networking
privilege until signalled that this is acceptable by the privileged mechanism
of dropping your cap from the bounding set.

> I think during exec we can simply check for this capability in pE, and
> if present then re-enable network if turned off.  Then setuid-root binaries
> will raise that bit (if it's in the bounding set) automatically.  Now,
> that means setuid-nonroot binaries will not reset network.  Though you
> could make that happen by doing setcap cap_net_allownet+pe /the/file.
> Does that suffice?

I think I could live with it.

I find it weird that, if I call disablenetwork on a system *without* dropping
your capability, sendto(...) will fail but execve(['/bin/ping', '...']) will
succeed. 

Still, it will do what I need.

>>   4) default-deny; setting a sysctl implies permit
>> 
>>         - Suggested by Serge; works fine for me
>
>That still leaves the question of when we re-allow network.  Any
>setuid?

My intention was that prctl(PR_SET_NETWORK, PR_NETWORK_OFF) would return
-ENOTSUP or similar until the sysctl was enabled, at which point it would work
as I specified.

("As I specified" means one of "irrevocable" or "like rlimits; can be relaxed
by explicit action by privileged processes")

>> P.P.S. - On a completely unrelated note: imagine trying to use SELinux (or your
>> favorite MAC framework) to restrict the use of prctl(PR_SET_NETWORK,
>> PR_NETWORK_OFF). Am I right that sys_prctl() contains a
>> time-of-check-to-time-of-use (TOCTTOU) race (with security_task_prctl() as the
>> check and with prctl_set_network() as the use) as a result of the actual
>> argument being passed by address rather than by value?
>
> I'm probably misunderstanding your question, but just in case I'm not:  the
> answer is that you wouldn't use the prctl interface anyway.  You would strictly
> use domain transitions.  Instead of doing prctl(PR_SET_NETWORK, PR_NETWORK_OFF)
> you would move yourself from the user_u:user_r:network_allowed domain to the
> user_u:user_r:network_disallowed domain.

You misunderstood; sorry I wasn't more clear. :)

I was really saying:

   Suppose process A and process B create a share a memory segment containing an
   unsigned long pointed to by.

   unsigned long *flags;

   Can't process A call prctl(PR_SET_NETWORK, flags) while, on another
   processor, process B is twiddling bits in *flags so that

     security_task_prctl() sees the bits that process A wrote and
     prctl_set_network() sees the bits that process B wrote?

   i.e. isn't there a TOCTTOU race [1] here in every prctl option that uses a
   pointer argument? if not, what stops the race?

Regards,

Michael

[1]: http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use
--
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