Nicolas Williams writes:
> On Mon, Jun 12, 2006 at 04:13:36PM -0400, James Carlson wrote:
> > Nicolas Williams writes:
> > > But more importantly, I'm not sure we can really restrict IPC at all.
> > > You can always use plain regular files for IPC.
> >
> > Agreed. But the argument gets strange from that point on. If we
> > don't restrict local IPC, why would we restrict loopback use of any
> > networking protocol? The same argument seems to say that we should
> > not do that.
>
> That's not strange, that's logical. Earlier I proposed
> PRIV_{NET|IPC}_{INITIATE|ACCEPT}, if we do this at all.
That ignores both the datagram- versus connection-oriented issues
(read and write are not at all the same as accept and connect), as
well as the interesting wrinkles added by Zones.
Is loopback (127.1) an IPC or a network? Is a separate zone on the
same machine an IPC?
Is opening a device or file and writing to it an IPC? Does the
logging device count? What about the tl driver?
We're in an area where I think we can't quite define what it is we
want to restrict, but that we know it when we see it. :-/
> > But I'm not sure how far you can go down that road before you've
> > invented per-application packet filters.
>
> Privileges are awfully coarse. Per-application packet filters, and a
> basic privilege for creating/modifying/deleting them, sound like a
> better idea, though it wouldn't make the library evolution problem go
> away.
>
> Another possibility: packet filtering by cred_t/execname :)
Yep.
My point is that if we use a dull instrument to solve the problem,
then we'll just end up with a new set of problems. Once we figure out
how to solve _those_, we'll be left carrying around the baggage for
the previous attempt at solving the problem.
In that case, less extravagant design is probably better.
--
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]
