netdev - Re: [PATCH 2/3] Security: Implement disablenetwork semantics. (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: <f73f7ab81001101418x3b3f8652j256f6311ad6244c5@mail.gmail.com>
Date:	Sun, 10 Jan 2010 17:18:49 -0500
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Michael Stone <michael@...top.org>
Cc:	James Morris <jmorris@...ei.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>,
	"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>, Pavel Machek <pavel@....cz>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH 2/3] Security: Implement disablenetwork semantics. (v4)

On Sun, Jan 10, 2010 at 16:54, Michael Stone <michael@...top.org> wrote:
> On Fri, 1 Jan 2010, Pavel Machek wrote:
>> > > For the record: NAK, as it introduces security holes.
>>
>> Please elaborate.
>
> Pavel's position is that disablenetwork is likely to permit some attacker
> somewhere to deny network access to some setuid app some day in a way that
> violates some security policy.
>
> He has mentioned specific concern over scenarios like:
>
>  Alice configures PAM auth to 'fail open' by checking login credentials
>  against a restrictive LDAP server and, if the server is unavailable,
> against
>  a very permissive files database.
>
>  Alice updates her kernel to a version with disablenetwork.
>
>  Mallory calls disablenetwork, calls su -, and vanquishes all.

No, there is a *MUCH* bigger security issue here.  There are existing
PAM modules which lazily fork background processes to handle
authentication, authorization, logging, etc.  Now assume that one of
those PAM modules is hooked from /etc/pam.d/su.

(1) Mallory runs "disablenetwork su -"
(2) The PAM module lazily starts its background daemon with a
10-minute idle timeout.
(3) The daemon has network disabled, and so it is completely nonfunctional.
(4) The daemon automatically denies all logins because it cannot
communicate with the login server
(5) Alice tries to run "su -" from her regular terminal.
(6) Alice's "su" process communicates with the running daemon and
fails because "the network is down".

All of that software is perfectly reasonably designed... the daemon is
even fail-secure in the event that the network really is inaccessible.
 Unfortunately it lets Mallory easily DoS every superuser login on the
system without generating a single audit log.  The only process that
knows what he did is the one that cannot communicate with the remote
audit daemon.

Moreover, that DoS would continue until the 10-minute idle timeout
actually expired.  As Alice keeps trying to log in, it will keep
automatically extending the daemon's lifetime.

Now, you can try to claim "Nobody has it configured like that" or
"None of the standard Linux PAM modules do that"... but that does not
resolve the problem.  A sysadmin and part-time programmer (not knowing
about a little-documented "disablenetwork" feature) could very easily
write software like that and assume that it is secure.

The #1 rule for setuid binaries is that you DO NOT INHERIT ANYTHING.
Any kernel feature or setuid program which violates that rule is just
going to cause big security holes.  Security models must be either
obviously correct or mathematically provable (or both)... and this is
neither.

Cheers,
Kyle Moffett
--
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