linux-kernel - Re: RFC: disablenetwork facility. (v4)

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091229221628.GA22578@us.ibm.com>
Date:	Tue, 29 Dec 2009 16:16:28 -0600
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Valdis.Kletnieks@...edu
Cc:	Bryan Donlan <bdonlan@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	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>,
	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 Valdis.Kletnieks@...edu (Valdis.Kletnieks@...edu):
> On Tue, 29 Dec 2009 15:27:22 CST, "Serge E. Hallyn" said:
> > I think i disagree.  A uid is just a uid (or should be).  One day we may
> > have a way for a factotum-style daemon to grant the ability to an unpriv
> > task to setuid without CAP_SETUID.  I think slingling uids and gids
> > around that you already have access to should be fine.
> 
> Yes, but not doing the clear and obvious simple thing now for a "one day
> we may have" consideration seems a poor engineering tradeoff.
> 
> Yes, slinging uids and gids around *would* be nice.  But first we need a clear
> plan for making /usr/bin/newgrp a shell builtin - once that happens, *then*
> we can re-address this code. ;)

Absolutely agreed with the principle, but conflicted on the application.

I know earlier in the thread I said uid 0 even when unprivileged is
actually privileged merely by owning most of the system files.  But
in fact I think it helps to think more clearly when we separately
consider the cases of (a) changing uid, and (b) enhancing privilege.

That's why I was recommending implementation through securebits - what
we're basically saying is the task should never gain privilege.  And
effectively, since it won't have CAP_SETUID (unless it has and keeps it
in pI) it wont' be able to change uids.  But if we right off the bat
confuse changing uids with gaining privilege, I'm afraid we might end
up making some poor decisions.

Still, I won't say no to a check to refuse dropping the ability to
setuid to ensure that ruid=euid=suid and pP=pE=pI=empty.  It may
come back to bite us, but like I say I'm conflicted - willing to
go either way.

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