Re: [PATCH 2/3] Security: Implement disablenetwork semantics. (v4)

[daw@cs.berkeley.edu (David Wagner)]

Kyle Moffett  wrote:
>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.

It's just a DOS.  There are a gazillion and one ways to DOS a typical
Linux system, especially if the attacker has an account on the system.

One alternative way: Mallory can mount such a DOS simply by flooding
the network.  That's not rocket science.

Another alternative way that might work (I don't know): What happens if
Mallory uses rlimit (RLIMIT_NOFILE) to set the maximum number of open
file descriptors very low, then runs "su -"?  Do we get the same DOS
outcome you listed above?  I'd guess yes, unless because these resource
limits are inherited across fork and exec.

I think stopping DOS is just really hard.  I'm not convinced this
is increasing the power of real-life attackers to any significant
extent.

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

I don't know.  I'm not really persuaded by your invocation of a
hypothetical sysadmin who writes their own setuid programs.  Writing
setuid programs (or programs invoked by setuid programs) securely is
really hard.  In all honesty, if your average "sysadmin and part-time
programmer" tries to roll their own setuid program for this kind of
thing, there's a fair chance that it will have a security hole --
and that's probably true whether or not you enable disablenetwork.
Introducing disablenetwork may increase the chances of insecurity in
setuid programs written by non-experts somewhat, but I bet it's only a
small increment compared to the overall risk.

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

Yeah, but we can also argue the other way from first principles too: If
you're writing a setuid program that *assumes* the network is reliable,
and fails insecurely if a packet doesn't get through, then you're
probably doing something wrong.  Networks are fundamentally unreliable.
Security-critical software shouldn't be written in a way that fails
unsafely if the network is unavailable.