UNIX domain sockets on nullfs still broken?

[Alexander Leidinger]

Quoting Julian Elischer <julian at elischer.org> (from Wed, 02 Dec 2009  
09:43:25 -0800):

> Alexander Leidinger wrote:
>> Quoting Linda Messerschmidt <linda.messerschmidt at gmail.com> (from  
>> Tue, 1 Dec 2009 10:22:02 -0500):
>>
>>> On Mon, Nov 30, 2009 at 10:14 AM, Ivan Voras <ivoras at freebsd.org> wrote:
>>>>> What's the sane solution, then, when the only method of communication
>>>>> is unix domain sockets?
>>>>
>>>> It is a security problem. I think the long-term solution would be to add a
>>>> sysctl analogous to security.jail.param.securelevel to handle this.
>>>
>>> Out of curiosity, why is allowing accessing to a Unix domain socket in
>>> a filesystem to which a jail has explicitly been allowed access more
>>> or less secure than allowing access to a file or a devfs node in a
>>> filesystem to which a jail has explicitly been allowed access?
>>
>> Answer A: There is no difference.
>>
>> Answer B: You open up a direct communication channel between two  
>> systems, which may not have been able to communicate before  
>> (firewall rules, ...). With files you can do something similar too,  
>> but having a socket there makes it more easy and you do not need to  
>> write extra code. It is similar to enabling SHM access in jails  
>> (currently all jails share the same SHM area). And depending on the  
>> application with the socket, you may be able to change files on the  
>> other side, to which you do not have access to otherwise (think  
>> about a daemon which changes passwords...).
>
> I have used chroots and jails in a way that relies on the ability of a
> shared unix domain pipe being usable to communicate between them, and
> I also see why it may not be good.

What worries me is, that it seems from comments in this thread, that  
nullfs is having a tighter security regarding jails than UFS/ZFS. I  
think all should work consistently in this regard (which would mean  
there will be a regression for some people if we switch UFS/ZFS to  
work in the same way).

> I suggest that the ability to do so might be somehow controllable by
> the jail creator in some way.
>
>>
>> Answer A is good if you control what is run where and how, and if  
>> you use jails for easy data migration and program separation  
>> (lightweight virtualization).
>>
>> Answer B is valid if you are an ISP which rents jails (in this case  
>> you do not share a FS read-write anyway (at leat you shouldn't) and  
>> the point does not really matter).
>>
>> Pick the answer depending on your viewpoint / security requirements  
>> and the software you are using.
>>
>> As both points are valid, we should provide the possibility to have  
>> both situations working.
>
> yes please.
>  A sysctl would do at a pinch, but maybe a per-jail setting might be  
> possible too.

Per-Jail is not a problem, I just need to know where the priv check is  
which is causing this behavior (so far I thought it is some limitation  
of nullfs and not a priv check). So far I hadn't the time to search  
for it, I want to finish the import of v4l in the linuxulator first.

Bye,
Alexander.

-- 
BOFH excuse #102:

Power company testing new voltage spike (creation) equipment

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137