Re: Would the SELinux act as a TippingPoint IPS to block the nasty Trojan traffic?

[Joshua Brindle <method@manicmethod.com>]

Paul Moore wrote:
> On Tuesday 10 April 2007 8:11:44 pm Joshua Brindle wrote:
>   
>> Paul Moore wrote:
>>     
>>> On Tuesday, April 10 2007 7:30:23 am John Wan wrote:
>>>
>>> There are two things which immediately spring to mind:
>>>
>>> 1. SELinux as a general rule does not do packet inspection like some
>>> IDS/IPS solutions
>>>       
>> SELinux doesn't need to do the packet inspection. The packet inspection
>> should be done in userspace and the userspace daemon can take the
>> appropriate action.
>>     
>
> If it wasn't clear in my response, let me make it so now - I agree.  I don't 
> think packet (or more generally, data) inspection is really something that 
> SELinux is prepared to deal with in it's current form.  However, SELinux can 
> deal with protecting processes which are setup to handle packet/data 
> inspection and provide assurances as to the data flow into and out of those 
> processes.
>
>   
I know, I was saying more generally that the kernel shouldn't be doing 
inspection, not just SELinux.
>> One such action would be flipping some booleans when 
>> an attack is detected which would close down some network access. The
>> obvious disadvantage here (aside from the raciness which doesn't seem to
>> phase IPS advocates) is that there is no way of isolating a single
>> session and shutting off that access, once an attack is detected and
>> reacted to all traffic labeled the same as the session being attacked
>> would be killed (eg., if using iptables based controls any attack
>> detected on an http port would kill all http traffic).
>>     
>
> Since most of the traffic will most likely be forwarded through, and not 
> consumed on the local machine, I think a better solution would be to manage 
> the iptables/netfilter rules to block certain 
> addresses/connections/networks/etc. when a "bad thing" occurs.
>
>   
There is such a thing as a host IDS/IPS but forwarding is more general 
purpose.

>> OTOH it might be possible to use userspace queuing of packets in
>> conjunction with secmark to label bad packets something else but that is
>> barely different from just using the DROP target. Ofcourse this all
>> depends on something local receiving the traffic due to lack of
>> forwarding controls...
>>     
>
> I would be curious to see how these IDS/IPS systems work but I suspect they 
> try to handle the traffic processing in the kernel so as to avoid the 
> performance overhead of handing the data to userspace and then collecting it 
> again on the way out.
>
>   
Well, in my past life I worked with such systems and most of them worked 
in userspace, look at hogwash for example which works as a transparent 
bridge but copies frames in userspace using libpcap. Granted this is 
more efficient than using netfilter userspace queuing.

>> I'd love to see your suggestions on solving the forwarding problem, I
>> suppose those are forthcoming? :)
>>     
>
> Right now you'll have to make do with the discussion from the developer's 
> summit and my lovely emails ;)  The patches will be forthcoming but I need to 
> wrap up some loose ends on another project right now ..
for some reason I don't remember a design being discussed at the summit, 
I'm probably just forgetting. This is not secpoint based right?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.