Quoting Linda Messerschmidt <linda.messerschm...@gmail.com> (from Tue,
1 Dec 2009 10:22:02 -0500):
On Mon, Nov 30, 2009 at 10:14 AM, Ivan Voras <ivo...@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...).
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.
Bye,
Alexander.
--
Is death legally binding?
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
