netdev - Re: [PATCH net-next] [RFC] netns: enable cross-ve Unix sockets

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 01 Oct 2008 17:18:42 +0200
From:	Daniel Lezcano <dlezcano@...ibm.com>
To:	"Denis V. Lunev" <den@...nvz.org>
CC:	Pavel Emelyanov <xemul@...nvz.org>, netdev@...r.kernel.org,
	containers@...ts.linux-foundation.org, benjamin.thery@...l.net,
	ebiederm@...ssion.com
Subject: Re: [PATCH net-next] [RFC] netns: enable cross-ve Unix sockets

Denis V. Lunev wrote:
> On Wed, 2008-10-01 at 15:46 +0200, Daniel Lezcano wrote:
>> Denis V. Lunev wrote:
>>> On Wed, 2008-10-01 at 14:31 +0200, Daniel Lezcano wrote:
>>>> Pavel Emelyanov wrote:
>>>>>> So there are 2 cases:
>>>>>>   * full isolation : restriction on VPS
>>>>>>   * partial isolation : no restriction but *perhaps* problem when migrating
>>>>>>
>>>>>> Looks like we need an option per namespace to reduce the isolation for 
>>>>>> af_unix sockets :)
>>>>>>   - on (default): current behaviour => full isolation
>>>>>>   - off : partial isolation
>>>>> You mean some sysctl, that enables/disables this check in unix_find_socket_byinode?
>>>> Yes.
>>> I do not see much sense with sysctl as:
>>> - check (cross-connected sockets) is required as we can start namespace
>>>   with already opened socket
>> Check when checkpointing ? If you inherit a socket from your parent 
>> namespace, this socket belongs to your parent and you should not 
>> checkpoint it, no ?
>>
>> In case you allow cross-connected sockets, this check is mandatory I agree.
>>
>>> - this kind of sharing is not implicit but explicit as normal isolated
>>>   containers _must_ have separate filesystems. In this case this
>>>   sharing requires explicit host administrator action to link socket
>>>   between containers
>> What are "normal isolated containers" ? Are they OpenVZ containers ? 
>> These containers belong to the system containers family. What happens 
>> with application containers, if I want to share the filesystem without 
>> breaking the isolation of the afunix sockets ?
> 
> then you are doomed as you will have a FIFO opened from 2 namespaces and
> checking the absences of external references is still mandatory
>> The current code provides full isolation and this is in mainline. I 
>> don't think it is reasonable to change that. What I propose is to keep 
>> the current behaviour.
>>
>> When you create a network namespace, you can change the behaviour inside 
>> this namespace via /proc/sys/net/unix/isolated (for example).
>>
>> This option allows:
>> 1 - to connect to af_unix not belonging to the container
>> 2 - to accept af_unix connection from outside the container (avoid a 
>> container to forbid the checkpoint of another container);
> 
> this should be at least per/namespace option controlled from parent
> container from my POW

Yes per namespace, I agree.

If the option is controlled by the parent and it is done by sysctl, you 
will have to make proc/sys per namespace like Pavel did with /proc/net, no ?

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