On Fri, 5 Jul 2002, Ville Herva wrote:
> In general, I wonder if it would make sense to aim for something like
> jail(2). Chroot has its shortcomings, and I take it that many of them have
> to be preserved to maintain standard compliance. Jail isolates processes
> more completely than chroot is ever ment to.
>
> FreeBSD implements jail by adding a jail pointer to struct proc - I'm not
> sure how much of that should/could be done with mere capabilities in linux,
> and how much of the "fortificated chroot" implementation jail has overlaps
> with Al Viro's namespaces.
>
> All in all, I've seen suprisingly little conversation about jail on
> lkml. What do people think of it?
Not having had the problem of jailing things for almost a decade, I
haven't been following this field, but certainly after looking at POSIX
and chroot, I don't think we can both be secure and compliant. Adding
jail() would be a better approach, preferably with a BSD-compatible API so
people could move programs here.
I have been doing some reading on UML, and it sounds as if that could be
at least as secure as jail, but it is almost certainly higher overhead. I
want to try running multiple machines in UML and see how well it works. If
disk is the only issue it's cheap enough to to have enough per
application, but I doubt if it's practical per-user in most cases.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:15 EST