UNIX domain sockets on nullfs still broken?

[Julian Elischer]

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.

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.


> 
> Bye,
> Alexander.
>