Re: RFC: disablenetwork facility. (v4)

From: Michael Stone
Date: Mon Dec 28 2009 - 01:06:06 EST


Pavel Machek wrote:
"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:

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

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.

3. As I pointed out before, disablenetwork _is_ controlled by a build-time
configuration option, its use _is_ still subject to any existing MAC
policy, and it _is_ easy to control for simply by talking to a
known-unrestricted process over an unrestricted IPC channel like a Unix
socket.

and a short meta-response:

As I see it, the whole point of isolation facilities like disablenetwork is
to convert _nasty_ faults like secrecy and integrity faults into _local_
availability faults. Consequently, it is completely unsurprising that we
can't meet stringent availability goals via isolation without either relaxing
our other security goals or falling back to strong assumptions about the
state of our initial environment.

However, we should not therefore ignore the bottom line which is that
the additional isolation enabled by disablenetwork represents an excellent
security risk/reward tradeoff for many people and should be made more widely
available to these people on these grounds.

Regards,

Michael

P.S. - Thanks again for your assistance in thinking through these scenarios and
in refining the security case for the disablenetwork feature.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/