Date: Wed, 02 Dec 2009 09:43:25 -0800 From: Julian Elischer <julian@elischer.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt <linda.messerschmidt@gmail.com>, Ivan Voras <ivoras@freebsd.org> Subject: Re: UNIX domain sockets on nullfs still broken? Message-ID: <4B16A73D.4040503@elischer.org> In-Reply-To: <20091202111600.12126yini7bmy4o4@webmail.leidinger.net> References: <20091130142950.GA86528@logik.internal.network> <hf0lle$5mk$1@ger.gmane.org> <20091130150127.GA82188@logik.internal.network> <hf0ngp$cpb$1@ger.gmane.org> <237c27100912010722g2f6c4647ga82370284bc26e20@mail.gmail.com> <20091202111600.12126yini7bmy4o4@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Leidinger wrote: > Quoting Linda Messerschmidt <linda.messerschmidt@gmail.com> (from Tue, 1 > Dec 2009 10:22:02 -0500): > >> On Mon, Nov 30, 2009 at 10:14 AM, Ivan Voras <ivoras@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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B16A73D.4040503>