Re: RFC: disablenetwork facility. (v4)

[Michael Stone]

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

My users care about things like stopping compromised processes from leaking
their documents or sending spam; they do not use the network in the ways you
seem to be concerned about.

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

Have you actually seen this security policy in real life? I ask because it
seems quite far-fetched to me. Networks are just too easy to attack. Seems to
me, from this casual description, that you're just asking to be ARP- or
DNS-poisoned and rooted with this one.

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

I am quite familiar with how setuid works. I was suggesting a number of ways to
modify the behavior of su's *ancestors*; not su. (I apoligize that my writing
was not more clear on this point.) 

In retrospect, substituting "abort()" for "disablenetwork()" better explains my
point. Who can call disablenetwork() to cause a problem who can't just as well
have called abort() or kill(0, SIGSTOP) at the same time?

Still, I take your point that there may be people out there who have written
configurations for setuid executables under the belief that their networks are
reliable and available in the presence of attackers.

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

Perhaps for your users. For me and for the users of my software, having
CONFIGURE_SECURITY_DISABLENETWORK is far better than not having it because it
permits us to close many other far more significant holes.

> You should either:

> a) make disablenetwork reset to "enablenetwork" during setuid exec
> b) disallow setuid execs for tasks that have network disabled.

Neither of these work. The first is incorrect because a disablenetwork'ed
process could transmit anything it wants through ping. The second is one that I
feel is unsafe because I don't feel that I can predict its consequences.

However, there's a third option that I think might work. What do you think of
treating being network-disabled the same way we treat RLIMIT_NOFILE? That is,
what about:

c) permit capable processes (such as euid 0) to remove networking restrictions
   by further calls to prctl(PR_SET_NETWORK)?

Regards,

Michael
--
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/