Date: Sat, 18 Sep 1999 22:51:14 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel Message-ID: <199909190551.WAA68627@apollo.backplane.com> References: <12516.937680952@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:Jail(2) as it stands today is an IPv4 facility, and only that.
:
:The interface is specified to make sure people don't miss this
:important fact.
:
:I have not yet been able to find sufficient information on how
:multihoming and resource location will work in IPv6 to determine
:if jail(2) will even be possible for IPv6.
:
:If you are able to design a protocol independent jail(2) facility
:I really think you should do so. For starters you can make it
:work for the appletalk and ipx stacks we have in the kernel.
:
:Remember: jail(2) is a security function, not a networking function.
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
It's got a network specification in the structure, therefore it has
a networking component that needs to be addressed. You can't seriously
believe that you can call it "not a networking function" when one of
its major features is to create a jail around an IP address!
It doesn't need to support appletalk or ipx stacks, but the system
call should not be constructed such that supporting those and other
protocols in the future will result in the system call becoming
incompatible with binaries already compiled for it from prior releases.
struct sockaddr is the standard for specifying an IP address. Jail
isn't using it, not even for IPV4. It's using an unsigned 32 bit int.
Hell, it isn't even using a struct in_addr! The field is plain and
simply inappropriately specified in the structure.
It is especially important that system calls be constructed with
future binary compatibility issues in mind, especially if they
become widely adopted. If jail is going to be backported
to -STABLE and made more 'standard' in the system, then it needs to
take this issue into account *now* so we don't go around breaking all the
software that starts using it when we need to extend it. It's that
simple.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909190551.WAA68627>