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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ