Re: [Fireflier-devel] Re: [PATCH][RFC] Security marking

["Török Edwin" <edwin@gurde.com>]

On Tuesday 18 April 2006 04:01, James Morris wrote:
> On Mon, 17 Apr 2006, edwin@gurde.com wrote:
> > Secmark, or skfilter is exactly what fireflier needs to solve the shared
> > socket issue. Thanks for working on this. If this gets integrated in
> > mainline, fireflier LSM will be dropped.
>
> I think you probably need skfilter as a standalone option.
I'll use skfilter then.
>
> > Is it possible to have an SELinux policy that reinjects the packets if
> > didn't match any rules? I.e. if a program that listens on port 80 doesn't
> > have access to the packet, (because it doesn't have the proper domain,)
> > and the SELinux won't allow the program to read the packet: is it
> > possible to reinject this packet in the netfilter chain, instead of
> > dropping it?
> >
> > This would allow creating rules interactively (fireflier).
>
> This could be done with nfqueue, modular policy and a pretty simple tool.
How do I determine if the policy needs to be changed? I.e. how do I determine 
if the packet would be dropped? You say packets are silently dropped, won't 
they generate an avc denied at least? (at least the first time?)
Once I determine that, I understand what you are saying: 
catch the packet with a nfqueue target, and write a proper "allow  my_t 
my_packet_t:packet { recv }" to a modular policy .te file, build that as 
a .pp, and load it using semodule (or libsemanage).
> > P.S.: Where can I get the full secmark patches, so I can test them to see
> > if they really fit my needs? Do you have an estimate timeline for
> > mainline integration? (in terms of n weeks, m months)
>
> The rest of the secmark related patches don't exist yet, I posted the core
> changes needed, and the others will be SELinux-specific.  Mainline
> integration would hopefully be 2.6.18, if it all works out ok.
Sounds good.
>
>
> If you're looking for skfilter:
> http://people.redhat.com/jmorris/selinux/skfilter/
Thanks, I know , I tested them already.
>
> Patrick McHardy has some ideas on resolving some of the skfilter issues.
Patrick what is the status of solving the skfilter issues? Can I help with 
testing patches,  etc.?

On Monday 20 February 2006 18:42, Patrick McHardy wrote:
> Confirmation of conntrack entries. They shouldn't be confirmed before
> packets have passed the socket hooks. This is the tricky part because
> we don't know if packets will be delivered to a raw socket or not
> when calling the regular LOCAL_IN hook.
> The only way to solve this 
> seems to be to use the socket hooks for all incoming packets, that
> way we can defer confirmation unconditionally.
Are there any problems with using socket hooks for all packets?
> The nicest way would 
> be to just move the regular LOCAL_IN hook to the socket hooks, but
> this doesn't work with SNAT in LOCAL_IN because the socket lookup
> needs the already NATed address.
Move just the non SNAT part of LOCAL_IN to socket hooks?(does this make 
sense?)


As you can see at http://fireflier.isgeeky.com/wiki/Ipt_fireflier_test, 
skfilter is working, although my test case was a very simple one. 
Could you provide a simple testcase where skfilter is not working right 
(conntrack...), so that I can test it too?

I applied only the ipv4 iptables related patches , there were a few failures 
due to the move to x_tables, but I think I solved them correctly. So here are 
the patch I actually applied: 
http://edwintorok.googlepages.com/linux-2.6.16.1-skfilter.patch, let me know 
if there is something wrong there.


P.S.: Fireflier will use SELinux for labeling processes (and sockets), and 
skfilter to do the actual filtering

Cheers,
Edwin