Re: [PATCH 2.6.15.4 1/1][RFC] ipt_owner: inode match supporting both incoming and outgoing packets

["Török Edwin" <edwin.torok@level7.ro>]

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