On Mon, 2010-08-23 at 20:58 +0200, ext Jan Engelhardt wrote: > On Monday 2010-08-23 20:45, Luciano Coelho wrote: > >> But it looks as strange as the Yama code attempt. > > > >What is so strange about it? Is it because it's possible to set the > >capability requirement from modprobe arguments? The capability check > >already exists in at least in nfnetlink, where it checks for received > >messages for the CAP_NET_ADMIN capability. Is it strange because we're > >checking for the capability when someone tries to write to a file? > > It is strange that you check this capability from a module focused on > packet handling. For lack of a better example, it's as if you tried > to check the uid of the file, the latter of which is better left to > the routines in fs/. Okay, thanks for the explanation! I'll have to figure something else out then. What I don't understand is that I see lots of components, which have nothing to do with security, making this kind of checks. Most of them (if not all) are checking for input from userspace where they provide their own interfaces (eg. ioctl calls, netlink messages). I can see that ip_tables checks for this capability when it gets "set" socket calls. Now, with the xt_condition, we're opening a new route from userspace to the kernel and I think it might be a good idea to protect that too. It's kind of useless to protect someone without CAP_NET_ADMIN from creating a condition rule if it is possible to change the condition from userspace without any capability protection. > >> This is the one time > >> where I would personally be looking into SELinux, or perhaps SMACK if > >> the former is too complex, to whether _t'ing off procfs is possible. > > > >Yeah, but it's not up to me to decide this. We have one entire team > >dedicated to figuring out how to ensure "security" in our device. It > >was that team who advised us to protect this file by checking for > >CAP_NET_ADMIN. > > You can do whatever you want with your product. I am just saying this > does not look like kernel material, and I suppose it won't go well > with the maintainers up the chain either. Yeah, my company can do whatever they want with the product. But my role here is to work with upstream, so if you guys think that what I'm doing is total bulls*it, I'll have to go back to the drawing board and restart my work ;) Again, I must stress that I really appreciate your comments and help. I know I can get good advice from people who are millions of times more experienced in this area than I am (and yes, that's *you* ;) -- and this is one of the various reasons I send my patches to netfilter-devel in the first place. Another reason is that I want to contribute my work (however shitty it is) to an eventual benefit for the community as a whole. :) -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
