[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20120824.133646.1032154931939291652.davem@davemloft.net>
Date: Fri, 24 Aug 2012 13:36:46 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: pablo@...filter.org
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH] netlink: fix possible spoofing from non-root processes
From: pablo@...filter.org
Date: Thu, 23 Aug 2012 14:09:11 +0200
> From: Pablo Neira Ayuso <pablo@...filter.org>
>
> Non-root user-space processes can send Netlink messages to other
> processes that are well-known for being subscribed to Netlink
> asynchronous notifications. This allows ilegitimate non-root
> process to send forged messages to Netlink subscribers.
>
> The userspace process usually verifies the legitimate origin in
> two ways:
>
> a) Socket credentials. If UID != 0, then the message comes from
> some ilegitimate process and the message needs to be dropped.
>
> b) Netlink portID. In general, portID == 0 means that the origin
> of the messages comes from the kernel. Thus, discarding any
> message not coming from the kernel.
>
> However, ctnetlink sets the portID in event messages that has
> been triggered by some user-space process, eg. conntrack utility.
> So other processes subscribed to ctnetlink events, eg. conntrackd,
> know that the event was triggered by some user-space action.
>
> Neither of the two ways to discard ilegitimate messages coming
> from non-root processes can help for ctnetlink.
>
> This patch adds capability validation in case that dst_pid is set
> in netlink_sendmsg(). This approach is aggressive since existing
> applications using any Netlink bus to deliver messages between
> two user-space processes will break. Note that the exception is
> NETLINK_USERSOCK, since it is reserved for netlink-to-netlink
> userspace communication.
>
> Still, if anyone wants that his Netlink bus allows netlink-to-netlink
> userspace, then they can set NL_NONROOT_SEND. However, by default,
> I don't think it makes sense to allow to use NETLINK_ROUTE to
> communicate two processes that are sending no matter what information
> that is not related to link/neighbouring/routing. They should be using
> NETLINK_USERSOCK instead for that.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@...filter.org>
Applied and queued up for -stable, thanks Pablo.
--
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
Powered by blists - more mailing lists