Message-ID: <20091229151146.GA32153@us.ibm.com>
Date:	Tue, 29 Dec 2009 09:11:46 -0600
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Michael Stone <michael@...top.org>, 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>,
	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>
Subject: Re: RFC: disablenetwork facility. (v4)

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> Michael Stone <michael@...top.org> writes:
> 
> > Serge,
> >
> > I think that Pavel's point, at its strongest and most general, could be
> > rephrased as:
> >
> >   "Adding *any* interesting isolation facility to the kernel breaks backwards
> >    compatibility for *some* program [in a way that violates security goals]."
> 
> *some* privileged program.
> 
> > The reason is the one that I identified in my previous note:
> >
> >   "The purpose of isolation facilities is to create membranes inside which
> >    grievous security faults are converted into availability faults."
> >
> > The question then is simply:
> >
> >   "How do we want to deal with the compatibility-breaking changes created by
> >    introducing new isolation facilities?"
> 
> You have a very peculiar taxonomy of the suggestions,
> that fails to capture the concerns.
> 
> I strongly recommend working out a way to disable
> setuid exec.  Ideally we would use capabilities to
> achieve this.  
> 
> Serge can we have a capability that unprivelged processes
> normally have an can drop without privelege?

David Madore suggested such a system several years ago:
http://lkml.org/lkml/2006/9/5/246

I have two comments on the idea:

1. We don't want to complicate the current capabilities
   concepts and API, so if we do something like this,
   we should make sure not to try to store these
   unprivileged capabilities with the current privilege
   capabilities.
	
2. This in itself does nothing to address the problem of
   unprivileged tasks denying privilege from privileged
   programs, thereby threatening the system.

In my last email last night I detailed a way to use regular
capabilities to make the prctl(PR_SET_NETWORK, PR_DROP_NET)
safer.

We could generalize that a bit:

1. we add a set of 'user_capabilities' like 'network', 'open',
etc, which are the rights to do an unprivileged network socket
create, file open, etc.

2. For each user_capability, we add a new 'CAP_REGAIN_$userpriv'
POSIX capability.

3. When a file is executed, we always add CAP_REGAIN_* to the
file permitted and effective sets.  That means that after
exec, they will always be in pE.

4. So long as CAP_REGAIN_foo is in pE toward the end of exec,
we re-enable the user_capability foo.

5. A privileged program can remove CAP_REGAIN_foo from the
capability bounding set.  It, and all it's children, will then
not have CAP_REGAIN_foo in pE after exec, so that if userspace
has removed foo from the user_capabilities set, it will not
be returned.

So, again, /bin/login, or pam, or /sbin/init can drop
CAP_REGAIN_* from its bounding set if userspace is designed
with that functionality in mind, in other words the distro or
admin trusts that privileged programs won't ruin the system if
they are denied certain features.

> I can see one of two possible reasons you are avoiding the
> suggestion to disable setuid root.
> - You have a use for setuid root executables in your contained
>   environment.  If you do what is that use?

I don't think Michael was avoiding that.  Rather, we haven't quite
spelled out what it means to disable setuid root, and we haven't
(to my satisfaction) detailed how setuid root would undo the
prctl(PR_SET_NETWORK, PR_DROP_NET) - i.e. is it only on a
privilege-granting setuid-root, or all setuids?

Eric, let me specifically point out a 'disable setuid-root'
problem on linux: root still owns most of the system even when
it's not privileged.  So does "disable setuid-root" mean
we don't allow exec of setuid-root binaries at all, or that
we don't setuid to root, or that we just don't raise privileges
for setuid-root?

> - Disabling suid root executables is an indirect path to your
>   goal.
> 
> The problem with the disable_network semantics you want
> is that they allow you to perform a denial of service attack
> on privileged users.  An unprivileged DOS attack is unsuitable
> for a general purpose feature in a general purpose kernel.

Though to be honest I'm still unconvinced that the disablenetwork
is dangerous.  I think long-term a more general solution like what
I outlined above might be good, but short-term a sysctl that
turns on or off the ability to drop network would suffice imo.
For ultra-secure sites at three-letter government agencies, we
could also provide a boot arg that disables the feature altogether,
and of course a grub password and IMA/EVM/trusted-boot could
ensure the boot arg isn't messed with.

> Your sysctl, your boot option, your Kconfig option all fail
> to be viable options for the same reason.  Your facility is
> only valid in an audited userspace.
> 
> Disabling setuid-exec especially to a subset of processes is
> valid in an unaudited userspace as it does not allow propagating
> the DOS to privileged processes.

-serge
--
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