On Mon, Jun 12, 2006 at 04:57:19PM -0400, James Carlson wrote: > Nicolas Williams writes: > > IMO "end-points in different zones" means "this isn't IPC." > > That might be true in some usages, but not true in others. > > For instance, suppose I have applications segregated by zone. I have > one application (say, a web server) that is permitted to talk to the > Internet. The other applications in the other zones are not permitted > to talk to the Internet, but they do talk to the web server. > > Should I be thinking about revoking PRIV_NET_(something) from those > other zones? If zones are treated as non-IPC, then the answer is no, > I can't do that. If they're treated as IPC, then I can. > > More fundamentally, I'm not sure where the line is between a feature > like this and something like IP Filter. If we have both, how do they > interact?
Like other basic privileges, these would be the kind you want to drop only when you know nothing else will need them for the life of the process. That makes basic privileges generally unsafe to drop because you rarely know you'll never need them. If you know that from the call to setppriv(2) to exit(2) you'll never, ever, need to to connect()/ listen()/accept() or other moral equivalents, then you could drop these sorts of privileges, and the distinctions you ask about might not matter. It's because I expect there to be so few occasions where one can be certain that such privs will not be needed that I don't think they'll be useful. > (You didn't answer the questions about loopback addresses, versus > drivers that behave as loopback or IPCs, and versus local but > non-loopback and non-zoned IP addresses. I'll assume they're all > under the IPC umbrella, but I don't know the right answer.) I thought my answer to the zones question should answer the other. Perhaps it'd not be easy to distinguish "end-points are local, within the same zone" where the access controls would need to be enforced. > I think having four separate privileges where one might do reasonably > is "extravagant." More so when we're not even in clear agreement on > the definition or the exact usage of these things. One privilege might do, but even so it'd remain a hammer in search of a nail. Isn't that the right answer, "tell us what programs would drop this basic privilege?" > I also remain concerned about the mapping of these privileges between > TCP and UDP. It doesn't sound right to me, and I suspect it leads to > impossible cases: where you don't (for instance) want to enable > outbound TCP connections, but you have no choice because you must > allow outbound UDP packets. Solving the which leads closer and closer to packet filters. Which in turn privileges are the wrong tool for, except for controlling the ability to set per-app/process packet filters. BTW, that'd be nice! Look at sshd(1M) and look at the sorts of controls you can specify via authorized_keys file entries; some are like packet filters! Such controls can only apply to port forwarding as implemented by sshd, but can't be inherited by, say, shell processes started by sshd, which in turn could be used to tunnel forbidden traffic. Packet filters that could be associated with cred_t could address that... Nico -- _______________________________________________ networking-discuss mailing list [email protected]
