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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Dec 2009 11:10:06 +0100
From:	Pavel Machek <pavel@....cz>
To:	Michael Stone <michael@...top.org>
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>
Subject: Re: RFC: disablenetwork facility. (v4)

Hi!

> >"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:

There's more. You are introducing security holes. Don't.

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

Actually it does. Policy may well be "If the network works, noone can
log in locally, because administration is normally done over
network. If the network fails, larger set of people is allowed in,
because something clearly went wrong and we want anyone going around
to fix it."

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

Please learn how setuid works. No, you can't ptrace su. Yes, su has to
deal with poisonous PATH. setuid programs are generally carefully
written to handle _known_ problems. You are adding disablenetwork that
they'll need to handle, and that's bad.

>   3. As I pointed out before, disablenetwork _is_ controlled by a build-time
>      configuration option, its use _is_ still subject to any existing MAC

CONFIG_ADD_SECURITY_HOLE is still bad idea.

You should either:

a) make disablenetwork reset to "enablenetwork" during setuid exec

or

b) disallow setuid execs for tasks that have network disabled.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/