netdev - Re: [RFC PATCH net-next 0/5] Ease netns management for userland

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

Message-ID: <87mwxh6a8y.fsf@xmission.com>
Date:	Thu, 13 Dec 2012 11:08:13 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	nicolas.dichtel@...nd.com
Cc:	netdev@...r.kernel.org, davem@...emloft.net, aatteka@...ira.com
Subject: Re: [RFC PATCH net-next 0/5] Ease netns management for userland

Nicolas Dichtel <nicolas.dichtel@...nd.com> writes:

> Le 12/12/2012 22:48, Eric W. Biederman a écrit :
>> ebiederm@...ssion.com (Eric W. Biederman) writes:
>>
>>> It is very wrong to presume that without context you know the reason for
>>> the exsitence of any network namespace and that you should or even that
>>> you can manage it.  Think of running your multi-network namespace
>>> managing application in a container.
>>
>> A good example of a network namespace you don't want to mess with are
>> the network namespaces created by vsftp and chrome for security purposes
>> to remove any possibility of creating new connections to the network.
>>
> Ok, I get the point.
>
> A last question: from an administration point of view, is it intended to
> not be able to monitor which netns are currently used? Like it can be done
> for sockets, files, ...

No.  The difficulty monitoring which network namespaces are being used
is an unintended side effect.

My pending changes to /proc/<pid>/ns/net and friends that allow you to
stat those files and compare if two network are the same network
namespace should make that monitoring much easier.  It isn't perfect as
there currently isn't a way to take a socket and say which network
namespace is this socket in.  But the current solution should tell you
what is happening most of the time.

struct net allocates it's own slab type so /proc/slabinfo on a good day
can tell you how many network namespace structures have been allocated
and are in use.

Eric

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