linux-kernel - Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC traffic

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:	Thu, 12 Oct 2006 11:15:07 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Matt Domsch <Matt_Domsch@...l.com>
Cc:	Trond Myklebust <Trond.Myklebust@...app.com>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	stable@...nel.org, Justin Forbes <jmforbes@...uxtx.org>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	"Theodore Ts'o" <tytso@....edu>,
	Randy Dunlap <rdunlap@...otime.net>,
	Dave Jones <davej@...hat.com>,
	Chuck Wolber <chuckw@...ntumlinux.com>,
	Chris Wedgwood <reviews@...cw.f00f.org>,
	Michael Krufky <mkrufky@...uxtv.org>, torvalds@...l.org,
	akpm@...l.org, Chuck Lever <chuck.lever@...cle.com>
Subject: Re: [patch 03/19] SUNRPC: avoid choosing an IPMI port for RPC
	traffic

Ar Mer, 2006-10-11 am 20:53 -0500, ysgrifennodd Matt Domsch:
> > > Then their hardware is faulty and should be specifically blacklisted not
> > > make everyone have to deal with silly unmaintainable hacks.
> > 
> > They are not hacks. The actual range of ports used by the RPC client is
> > set using /proc/sys/sunrpc/(min|max)_resvport. People that don't have
> > broken motherboards can override the default range, which is all that we
> > are changing here.

No.. you have it backwards. The tiny tiny number of people with broken
boards can either set it themselves, use DMI, or ram the offending board
somewhere dark belonging to whoever sold it to them

> > To be fair, the motherboard manufacturers have actually registered these
> > ports with IANA:

This is irrelevant, they are stealing bits out of the incoming network
stream. That's not just rude its dangerous - they should have their own
MAC and IP stack for this. Port assignments are courtesy numbering to
avoid collisions on your own stack. They have no more right to steal
packets from that port than CERN does to claim all port 80 traffic on
the internet.

Why do I say dangerous - because they steal the data *before* your Linux
firewalling and feed it to an unauditable binary firmware which has
controlling access to large parts of the system without the OS even
seeing it.

Not a good idea IMHO on any box facing even a slightly insecure port.

> For the one Dell server affected, we could DMI list
> it; likewise for others.

This should be done with DMI I agree.

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