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
| ||
|
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
Powered by blists - more mailing lists