Quoting Julian Elischer <jul...@elischer.org> (from Wed, 02 Dec 2009
09:43:25 -0800):
Alexander Leidinger wrote:
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...).
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
_______________________________________________
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"
