Darren Reed writes:
> I should have included that my observations with dtrace indicate
> that looking at db_credp->cr_zoneid (using dtrace) is quite reliable
> for packets going out of the system as a means to determine the
> zone that "owns" a packet.
It works only when the buffer allocation itself has process context.
So, for instance, you won't see the right result on outbound packets
that are generated by the kernel itself (e.g., ECHO-REPLY). Try
running a script like this:
#!/usr/sbin/dtrace -qs -
fbt:ip:icmp_inbound:entry
{
self->trace++;
self->cred = (struct cred *)0;
}
fbt::put:entry
/self->trace/
{
self->cred = ((mblk_t *)arg0)->b_datap->db_credp;
}
fbt::put:entry
/self->cred && self->cred->cr_zone == 0/
{
printf("no zone pointer\n");
}
fbt::put:entry
/self->cred && self->cred->cr_zone/
{
printf("%d\n", self->cred->cr_zone->zone_id);
}
fbt:ip:icmp_inbound:return
{
self->trace--;
}
"Quite reliable" probably isn't good enough for some security-related
purposes.
> But if you've got a process in a zone that has been granted
> net_rawaccess can't it then go and write packets out with any
> IP header? This would make matching on IP address somewhat
> useless for outbound packets, if so.
I'd think so.
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
