netdev - Re: [PATCH next v1] bonding: Display LACP info only to CAP_NET

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]

Message-ID: <20150615140812.GE588@gospo.home.greyhouse.net>
Date:	Mon, 15 Jun 2015 10:08:13 -0400
From:	Andy Gospodarek <gospo@...ulusnetworks.com>
To:	Mahesh Bandewar <maheshb@...gle.com>
Cc:	Jay Vosburgh <j.vosburgh@...il.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	Veaceslav Falico <vfalico@...il.com>,
	Nikolay Aleksandrov <razor@...ckwall.org>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Maciej Zenczykowski <maze@...gle.com>
Subject: Re: [PATCH next v1] bonding: Display LACP info only to CAP_NET_ADMIN
 capable user

On Fri, Jun 12, 2015 at 12:24:47PM -0700, Mahesh Bandewar wrote:
> Actor and Partner details can be accessed via proc-fs and sys-fs
> entries. These interfaces are world readable at this moment. The
> earlier patch-series made the LACP communication secure to avoid
> nuisance attack from within the same L2 domain but it did not
> prevent "someone unprivileged" looking at that information on host
> and perform the same act.
> 
> This patch essentially avoids spitting those entries if the user
> in question does not have enough privileges.

Mahesh,

Nik just posted patches to add the ability to add actor_oper_port_state
and partner_oper.port_state to netlink and sysfs.  Since you are
restricting the display of those values in /proc and /sys to only those
users with CAP_NET_ADMIN set, there is some overlap that needs to be
resolved.

More importantly Nik's set reminds me that the netlink case for this
restriction also needs to be handled or the functionality desired is
effectively not implemented since a user could query these values via
netlink.

Since Nik's patch is smaller and it should be easy to for you rebase on
top of it, I'm going to ack his and once you pull in his changes and add
netlink support I think your patch should be fine -- as long as there
are no major objections to having a different netlink message returned
based on the netlink user.

-andy

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