linux-kernel - Re: [PATCH 3/3] net/udevns: Netlink module to forward uevent to containers

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: <55F324FB.1070803@alcatel-lucent.com>
Date:	Fri, 11 Sep 2015 15:01:15 -0400
From:	Michael J Coss <michael.coss@...atel-lucent.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	gregkh@...uxfoundation.org, davem@...emloft.net,
	linux-kernel@...r.kernel.org, containers@...ts.linuxcontainers.org,
	serge.hallyn@...ntu.com, stgraber@...ntu.com
Subject: Re: [PATCH 3/3] net/udevns: Netlink module to forward uevent to
 containers

On 9/10/2015 9:05 PM, Eric W. Biederman wrote:
> "Michael J. Coss" <michael.coss@...atel-lucent.com> writes:
>
>> New generic netlink module to provide an interface with the new
>> forwarding interface for uevent.  The driver allows a user to
>> direct a uevent as read from the kernel to a specific network
>> namespace by providing the uevent message, and a target process id.
>> The uapi header file provides the message format.
> If we can't just pass the message thourgh I don't expect genetlink is a
> particularly good interface for this.
>
> It would be nice if we could open some appropriate thing and the act of
> getting a file descriptor ould suppress all of the uevent broadcast
> messages in that network namespace.
>
> Further GENL_ADMIN_PERM is an unfortunate choice for a permission check.
> I don't see it as exploitable but I am not certain CAP_SYS_ADMIN is the
> best capability to check.    Beyond that we probably want to arrange
> things so that we can use ns_capable so we can allow containers to hand
> off their devices to child containers.
>
> Implementations that do not allow for containers to nest bother me.
>
>
I've done several different approaches with this.  I really just wanted
an interface to the kernel function to provide forwarding.  The first
choice was just a pseudo device that you wrote uevent messages to and
that message was forwarded.  This is yet another take on that.  I'm not
sure whether one is better or worse than the other.

Thanks for the feedback.

-- 
---Michael J Coss

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