Messages in this thread | | | From | Török Edwin <> | Subject | Re: [PATCH 2.6.15.4 1/1][RFC] ipt_owner: inode match supporting both incoming and outgoing packets | Date | Mon, 20 Feb 2006 19:40:40 +0200 |
| |
On Monday 20 February 2006 18:26, James Morris wrote: > On Sat, 18 Feb 2006, Török Edwin wrote: > > This is a patch based on Luke Kenneth Casson Leighton's patch [1] > > One problem with that patch was that it couldn't be used for filtering > > incoming packets, due to the fact that more than one process can listen > > on the same socket ([2],[3]). > > Have a look at my skfilter patches: > http://people.redhat.com/jmorris/selinux/skfilter/kernel/ I already looked at them yesterday evening,(I found a link in a lwn.net article). Nice work :-) Having your patches applied to mainline kernel would solve many of my problems. > > These implement a scheme for matching incoming packets against sockets by > adding a new hook in the socket layer.
AFAICT this solves the "incoming packets" problem and will I also be able to filter data sent through raw sockets?
If selinux is enabled and available then the skfilter patch solves all of fireflier's problems. Nice.
In the following I will be referring to 16-skfilter-ipt_owner-ctx.patch:
However I'd like to do filtering based on owner (process) even when selinux is not available. Your context match explicitly requires selinux to be enabled, and a policy loaded. Is there a way to do context matching, when booting with selinux=0, i.e. is there a way to enable just a minimal subset of selinux, that would do this: - (auto)label processes based on its inode/mount-point - (auto)label all sockets that a process has access to with the process's label (or better: its domain) - do context matching based on these labels (if I understood correctly this is what your patch does)
Could you please use LSM hooks (like inode_getsecurity) instead of directly using selinux? I'd want to provide my own implementation of labeling (a very,very simple labeling, a very small subset of what selinux does, but which wouldn't require much configuration). In other words, I want to write a LSM, and then mod_register_security() my module.
Or if the above is not possible, could you provide some hooks, where I could register my hooks to provide these: - int available() - int ctx_to_id(char*,u32*) - int socket_to_ctxid(struct sock*,u32*)
(Of course I could create another match that would use my module to do the matching on the SOCKET chain. But this would uselessly duplicate functionality&code, an additional hook would be a much cleaner solution).
What is your opinion on what I said above? I am open to suggestions, criticism, advice....
Thanks, Edwin > > For upstream merge, the issues are: > - should the new socket hook be used for all incoming packets? > - ensure IP queuing still works > > Patrick: any other issues? > > > > - James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |