linux-kernel - Re: RFC: disablenetwork facility. (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]

Date:	Fri, 1 Jan 2010 16:55:30 +0100
From:	Pavel Machek <pavel@....cz>
To:	David Wagner <daw-news@...erner.cs.berkeley.edu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: RFC: disablenetwork facility. (v4)

(Please use group reply, so that cc lists are preserved).

> Pavel writes:
> > 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."
> 
> Michael Stone writes:
> > Have you actually seen this security policy in real life?
> 
> Pavel responds:
> > Actually, I've seen a *lot* of similar [..] policies.
> 
> OK, so to translate: it sounds like the answer is No, you
> haven't seen this policy in real life.
> 
> More to the point, the real question is whether this policy
> is embedded in code anywhere such that Michael's mechanism would
> introduce a new security hole, and if so, whether the cost of
> that would outweigh the benefit of his mechanism.  I think the

Actually, no, this is not the (only) question. Kernel tries to be
backwards-compatible.

> answer is, No, no one even has a plausible story for how this
> policy might appear in some legacy executable that would then
> be newly subvertible due to Michael Stone's policy.  First off,

It is Michael's responsibility to prove that no legacy executable is
affected, and they clearly are.

(Another example would be DoS; imagine sendmail forking into
background from setuid program. It maybe even does that. Run that with
network disabled and you have DoSed mail system on the server.)

> I think what Michael is trying to do has the potential to be very
> valuable and should be supported, and this is not a convincing
> argument against it.

People already proposed systems (disablenetwork needs disablesuid)
that have all the advantages, and no security-related
back-compatibility problems


									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/