David P. Quigley wrote: > On Tue, 2009-12-01 at 21:43 -0800, Casey Schaufler wrote: > >>> also what happens when other transport protocols come around like sctp >>> for instance. now we need another 65k files for this as well. >>> >>> >>> >> Ok, so it would appear that the notion of a fully populated >> portfs has sufficient stumbling blocks to make it a non-starter. >> >> A dynamically maintained version, with default values for unallocated >> ports and memory based xattrs stored on request would still be viable. >> >> Yes, it's more work. I'd rather see a generally useful scheme than an >> SELinux specific one, if for no other reason than it makes the general >> case harder to sell later on. >> >> >>> Dave >>> >>> >>> -- >>> > > You still need to address my issue with port ranges. Why does the notions of port ranges make any sense at all? That sounds an awful lot like name based access control from here, and we know the evils of name based access controls. (smiley here) > Also I don't find > this interface generically useful when you have to have intimate > knowledge of the LSM to know what the correct xattrs to set are. You > pointed it out yourself that Smack handles port labeling differently > than SELinux Nope. Smack does not label ports. Ports are not policy components in Smack. I pointed out that Smack treats sockets differently than SELinux. I did so to address your issue with multiple xattrs on an object. I pointed out that it is easy to do. > so to try to shoe horn every LSM that labels ports into a > filesystem interface where the user has to know LSM specific xattrs to > set doesn't seem generic to me. > The xattr interface is generic. Yes, you have to know the name of the attribute as well as the value it should have and yes that will differ between LSMs. > Dave Now I'm glad the notion has been considered, and I can understand if it seems like too much work or if you just don't see it as a good idea. How about making it a part of the labeled networking code then? That would seem to be a more focused approach that would also, and perhaps better, address the generality concern. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
