Date: Thu, 03 Dec 2009 08:55:51 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Julian Elischer <julian@elischer.org> 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: <20091203085551.14402tdw5nwmmm0w@webmail.leidinger.net> In-Reply-To: <4B16A73D.4040503@elischer.org> 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> <4B16A73D.4040503@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Julian Elischer <julian@elischer.org> (from Wed, 02 Dec 2009 09:43:25 -0800): > 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091203085551.14402tdw5nwmmm0w>