netdev - Re: [RFC] Restricting MDIO reads

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] [day] [month] [year] [list]

Date:	Thu, 11 Jun 2009 21:00:44 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	bhutchings@...arflare.com
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC] Restricting MDIO reads

From: Ben Hutchings <bhutchings@...arflare.com>
Date: Thu, 11 Jun 2009 17:04:07 +0100

> Currently most drivers[1] that support the "MII" ioctls allow all users
> to read MDIO registers, while MDIO writes require CAP_NET_ADMIN.
> 
> However, some MDIO registers and register bits have read-to-clear (latch
> high, latch low or non-rollover) or multi-word latching semantics[2].
> So reading from them may interfere with the driver or other users and
> should also require CAP_NET_ADMIN.
> 
> It's not clear to me just which registers should be safe to read, and
> this can vary between PHYs.   I think the correct thing to do is either
> to restrict all MDIO reads or to whitelist standard-defined safe
> registers.
> 
> Which applications, if any, depend on performing MDIO reads as an
> unprivileged user?  Which registers do they expect to read?

I think we should apply CAP_NET_ADMIN to all register reads.

Anything without privs trying to read those things is asking
for trouble.  It's an access with arbitrary, device specific,
side effects.  Not exactly something we should ever allow the
user to do without privs.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html