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

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

[John Wan]

Hi,

I am new to SELinux, I would like to configure the SELinux (on a Linux
box running RH EL AS4 ) to work as a Proactive IPS device (such as
TippingPoint Intrusion Prevention Systems--- Proactive Network Security,
it would cost about $20K, which is way beyond my budget). I wish the
SELinux would work as an IPS device to protect our staff network from
our wireless network (the Linux RH EL AS4 box with Chillispots & SELinux
connects the staff network and the wireless network).  For example, a
student wireless laptop with a Trojan virus would not be able to go
through the Linux box (with Chillispots &SELinux) from the wireless
network to the staff network. This is because of the SELinux would act
as a TippingPoint IPS to block the nasty Trojan traffic. 

 My question is: Is this possible? 

I also realise the SELinux approach is totally different from the most
security products in the anti-virus and intrusion prevention and
detection markets. 

Anti-virus and IDS/IPS systems based on signatures are reactive,
operating only on known threats, which is why zero-day exploits are so
prized by malware authors.

SELinux, on the other hand, can be compared to a firewall with a default
"deny any" rule, and a set of "allow" rules to only permit actions that
are necessary for proper system operation.

My ultimate goal is to use the SELinux policy to block the abnormal
network traffic (such as a Trojan virus) from one network to another
network. Or the Linux box would be able to stop the contagious network
traffic in the wireless network by using the SELinux policy. 

Is that possible? Or am I terribly wrong here?

Any information and help would be much appreciated.

Many thanks in advance,

John Wan



--
_______________________________________________________________________________

 

Notice from Melbourne Business School Ltd 


The information contained in this e-mail is confidential, and is intended for
the named person's use only.  It may contain proprietary or legally privileged
information. If you have received this email in error, please notify the
sender and delete it immediately.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you are not
the intended recipient

Internet communications are not secure. You should scan this message and any
attachments for viruses. Melbourne Business School does not accept any
liability for loss or damage which may result from receipt of this message or
any attachments.

______________________________________________________________________________ 



 



--
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.

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

[Paul Moore]

On Tuesday, April 10 2007 7:30:23 am John Wan wrote:
> I am new to SELinux, I would like to configure the SELinux (on a Linux
> box running RH EL AS4 ) to work as a Proactive IPS device (such as
> TippingPoint Intrusion Prevention Systems--- Proactive Network Security,
> it would cost about $20K, which is way beyond my budget). I wish the
> SELinux would work as an IPS device to protect our staff network from
> our wireless network (the Linux RH EL AS4 box with Chillispots & SELinux
> connects the staff network and the wireless network).  For example, a
> student wireless laptop with a Trojan virus would not be able to go
> through the Linux box (with Chillispots &SELinux) from the wireless
> network to the staff network. This is because of the SELinux would act
> as a TippingPoint IPS to block the nasty Trojan traffic.
>
>  My question is: Is this possible?

I'm not very familiar with TippingPoint but I assume from you description that 
what you are looking for is a piece of software that would identify certain 
network traffic signatures and trigger blocking behavior when such signatures 
were found.  If that is the case I think SELinux (in it's current form) alone 
will not accomplish what you are trying to do, however, it could be part of 
the solution used to protect the integrity of the router.

> Anti-virus and IDS/IPS systems based on signatures are reactive,
> operating only on known threats, which is why zero-day exploits are so
> prized by malware authors.
>
> SELinux, on the other hand, can be compared to a firewall with a default
> "deny any" rule, and a set of "allow" rules to only permit actions that
> are necessary for proper system operation.
>
> My ultimate goal is to use the SELinux policy to block the abnormal
> network traffic (such as a Trojan virus) from one network to another
> network. Or the Linux box would be able to stop the contagious network
> traffic in the wireless network by using the SELinux policy.
>
> Is that possible? Or am I terribly wrong here?

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
2. SELinux does not provide any packet forwarding access controls

Granted, item #2 is something we (or at least I) want very badly and will be 
working on over the course of this year.  The initial work will most likely 
be limited to external labels (CIPSO, labeled IPsec, etc.), but it should be 
possible to expand the packet forwarding controls to make use locally 
generated labels as well (SECMARK).  As for item #1, perhaps others have some 
thoughts on this, but I don't see this happening anytime soon.

-- 
paul moore
linux security @ hp

--
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.

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

[Joshua Brindle]

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. 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).

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'd love to see your suggestions on solving the forwarding problem, I 
suppose those are forthcoming? :)

--
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.

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

[Paul Moore]

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.

> 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.

> 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.

> 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 ...

-- 
paul moore
linux security @ hp

--
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.

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

[Joshua Brindle]

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.

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

[Paul Moore]

On Tuesday, April 10 2007 10:58:13 pm Joshua Brindle wrote:
> >> 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?

It was discussed but towards the end of the day in the networking discussion 
block.  See the notes that Stephen posted a while ago.

The idea is to create a new iptables "target" (probably the wrong term, but 
I'm not an iptables expert ... yet) which had an assigned label, you would 
then create iptables rules which would match certain traffic to 
that "target".  The packets which hit the "target" would have an access check 
similar to the following:

 allow <target_label> <external_packet_label> : class perm;

So it's very similar to the secpoint (or whatever it was being called) idea.  
Also, just to re-iterate this - I HAVE NO PLANS TO MERGE THE INTERNAL AND 
EXTERNAL LABELS.  The original intent is to only provide support for 
external, i.e. NetLabel and labeled IPsec, labeling mechanisms; if we decide 
to provide support for internal labeling mechanisms like SECMARK we will do 
so in parallel with additional access checks.

-- 
paul moore
linux security @ hp

--
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.

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

[Venkat Yekkirala]

Just FYI-I did propose filtering in the filter table in the past,
and this has been on my todo list.

"Implementation issues aside, lately I have been wondering about doing
something in the filter table using something we could call secfilter
or so.

You would still use secmark to label the packets, but they (along with
any external labels) could get filtered in the secfilter module. This
way we could control what external labels could come thru from what peers.
For internal labels it would be more of an assurance thing. This would also
automatically take care of forwarding controls."

More at: http://marc.info/?l=selinux&m=116232831800159&w=2

> -----Original Message-----
> From: Paul Moore [mailto:paul.moore@hp.com]
> Sent: Wednesday, April 11, 2007 8:16 AM
> To: Joshua Brindle
> Cc: John Wan; selinux@tycho.nsa.gov
> Subject: Re: Would the SELinux act as a TippingPoint IPS to block the
> nasty Trojan traffic?
> 
> 
> On Tuesday, April 10 2007 10:58:13 pm Joshua Brindle wrote:
> > >> 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?
> 
> It was discussed but towards the end of the day in the 
> networking discussion 
> block.  See the notes that Stephen posted a while ago.
> 
> The idea is to create a new iptables "target" (probably the 
> wrong term, but 
> I'm not an iptables expert ... yet) which had an assigned 
> label, you would 
> then create iptables rules which would match certain traffic to 
> that "target".  The packets which hit the "target" would have 
> an access check 
> similar to the following:
> 
>  allow <target_label> <external_packet_label> : class perm;
> 
> So it's very similar to the secpoint (or whatever it was 
> being called) idea.  
> Also, just to re-iterate this - I HAVE NO PLANS TO MERGE THE 
> INTERNAL AND 
> EXTERNAL LABELS.  The original intent is to only provide support for 
> external, i.e. NetLabel and labeled IPsec, labeling 
> mechanisms; if we decide 
> to provide support for internal labeling mechanisms like 
> SECMARK we will do 
> so in parallel with additional access checks.
> 
> -- 
> paul moore
> linux security @ hp
> 
> --
> 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.
> 

--
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.

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

[Paul Moore]

On Wednesday, April 11 2007 11:10:16 am Venkat Yekkirala wrote:
> Just FYI-I did propose filtering in the filter table in the past,
> and this has been on my todo list.
>
> "Implementation issues aside, lately I have been wondering about doing
> something in the filter table using something we could call secfilter
> or so.
>
> You would still use secmark to label the packets, but they (along with
> any external labels) could get filtered in the secfilter module. This
> way we could control what external labels could come thru from what peers.
> For internal labels it would be more of an assurance thing. This would also
> automatically take care of forwarding controls."

This is what I was talking about, although I called it "secpoint" (too many 
names <g>).  The approach seemed to have promise in that it seemed to be 
easily understood be everyone and I brought it up again because I didn't want 
it to get lost; the discussion trailed off after initial idea was proposed 
and you hadn't posted anyting regarding it since then.

Do you have an estimate of when you are planning to work on it?  I want to try 
and avoid duplicating our efforts.

-- 
paul moore
linux security @ hp

--
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.

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

[Venkat Yekkirala]

> -----Original Message-----
> From: Paul Moore [mailto:paul.moore@hp.com]
> Sent: Wednesday, April 11, 2007 10:18 AM
> To: vyekkirala@trustedcs.com
> Cc: Joshua Brindle; John Wan; selinux@tycho.nsa.gov
> Subject: Re: Would the SELinux act as a TippingPoint IPS to block the
> nasty Trojan traffic?
> 
> 
> On Wednesday, April 11 2007 11:10:16 am Venkat Yekkirala wrote:
> > Just FYI-I did propose filtering in the filter table in the past,
> > and this has been on my todo list.
> >
> > "Implementation issues aside, lately I have been wondering 
> about doing
> > something in the filter table using something we could call 
> secfilter
> > or so.
> >
> > You would still use secmark to label the packets, but they 
> (along with
> > any external labels) could get filtered in the secfilter 
> module. This
> > way we could control what external labels could come thru 
> from what peers.
> > For internal labels it would be more of an assurance thing. 
> This would also
> > automatically take care of forwarding controls."
> 
> This is what I was talking about, although I called it 
> "secpoint" (too many 
> names <g>).  The approach seemed to have promise in that it 
> seemed to be 
> easily understood be everyone and I brought it up again 
> because I didn't want 
> it to get lost; the discussion trailed off after initial idea 
> was proposed 
> and you hadn't posted anyting regarding it since then.

Well, thanks for keeping it under the limelight. As for
the name, I think secfilter will do full justice since it's
really filtering (only security context-based) and would thus
be intuitive. Also, secpoint might confuse people that were
already exposed to the failed secpoint paradigm.

> 
> Do you have an estimate of when you are planning to work on 
> it?  I want to try 
> and avoid duplicating our efforts.

I am getting very close to getting to it. Will keep y'all posted.

--
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.

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

[Joshua Brindle]

Venkat Yekkirala wrote:
> Just FYI-I did propose filtering in the filter table in the past,
> and this has been on my todo list.
>
> "Implementation issues aside, lately I have been wondering about doing
> something in the filter table using something we could call secfilter
> or so.
>
> You would still use secmark to label the packets, but they (along with
> any external labels) could get filtered in the secfilter module. This
> way we could control what external labels could come thru from what peers.
> For internal labels it would be more of an assurance thing. This would also
> automatically take care of forwarding controls."
>
> More at: http://marc.info/?l=selinux&m=116232831800159&w=2
>   
so from what I gather the secfilter module would be querying the selinux 
policy to determine whether or not to drop something, that would mean a 
change in iptables changes the enforcement policy (not just the labeling 
policy as is the case now) which is a little disconcerting.

How does this work into the idea we had during the summit about SELinux 
having its own table? The table would presumably be a mangle table for 
labeling but could it also be a filter table? I'm not clear on what is 
possible in netfilter.



--
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.

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

[Paul Moore]

On Wednesday, April 11 2007 1:01:24 pm Joshua Brindle wrote:
> Venkat Yekkirala wrote:
> > Just FYI-I did propose filtering in the filter table in the past,
> > and this has been on my todo list.
> >
> > "Implementation issues aside, lately I have been wondering about doing
> > something in the filter table using something we could call secfilter
> > or so.
> >
> > You would still use secmark to label the packets, but they (along with
> > any external labels) could get filtered in the secfilter module. This
> > way we could control what external labels could come thru from what
> > peers. For internal labels it would be more of an assurance thing. This
> > would also automatically take care of forwarding controls."
> >
> > More at: http://marc.info/?l=selinux&m=116232831800159&w=2
>
> so from what I gather the secfilter module would be querying the selinux
> policy to determine whether or not to drop something, that would mean a
> change in iptables changes the enforcement policy (not just the labeling
> policy as is the case now) which is a little disconcerting.

It a tradeoff: we gain the flexibility of the iptables packet/connection 
matching rules but we rely on the rules to be present.  It's very similar in 
principal to the discussions that have been going on with SECMARK; I suspect 
we can solve this problem in a similar manner.

> How does this work into the idea we had during the summit about SELinux
> having its own table? The table would presumably be a mangle table for
> labeling but could it also be a filter table? I'm not clear on what is
> possible in netfilter.

I'm not a netfilter expert myself, although I'm learning more and more about 
it each day.  I don't see how this couldn't fit into the proposed 
LSM/SELinux/security table in fact I think I mentioned something like this at 
one point (although, maybe it was just to myself).

-- 
paul moore
linux security @ hp

--
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.

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

[Venkat Yekkirala]

> > How does this work into the idea we had during the summit 
> about SELinux
> > having its own table? The table would presumably be a 
> mangle table for
> > labeling but could it also be a filter table? I'm not clear 
> on what is
> > possible in netfilter.
> 
> I'm not a netfilter expert myself, although I'm learning more 
> and more about 
> it each day.  I don't see how this couldn't fit into the proposed 
> LSM/SELinux/security table in fact I think I mentioned 
> something like this at 
> one point (although, maybe it was just to myself).

To share some preliminary thoughts on this, we might be able to have
the security table have 2 built-in chains, say, secmark and secfilter,
and have these chains traversed at the appropriate points as in the
following example for the INPUT case:

...
mangle PREROUTE
security SECMARK
filter INPUT
security SECFILTER
...

It's also conceivable that we might, in fact, have two tables (secmark
and secfilter), all things considered.

--
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.

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

[Venkat Yekkirala]

A minor correction below.

> -----Original Message-----
> From: Venkat Yekkirala [mailto:vyekkirala@trustedcs.com]On Behalf Of
> Venkat Yekkirala
> Sent: Thursday, April 12, 2007 12:51 PM
> To: 'Paul Moore'; Joshua Brindle
> Cc: Venkat Yekkirala; John Wan; selinux@tycho.nsa.gov;
> 'jmorris@namei.org'
> Subject: RE: Would the SELinux act as a TippingPoint IPS to block the
> nasty Trojan traffic?
> 
> 
> > > How does this work into the idea we had during the summit 
> > about SELinux
> > > having its own table? The table would presumably be a 
> > mangle table for
> > > labeling but could it also be a filter table? I'm not clear 
> > on what is
> > > possible in netfilter.
> > 
> > I'm not a netfilter expert myself, although I'm learning more 
> > and more about 
> > it each day.  I don't see how this couldn't fit into the proposed 
> > LSM/SELinux/security table in fact I think I mentioned 
> > something like this at 
> > one point (although, maybe it was just to myself).
> 
> To share some preliminary thoughts on this, we might be able to have
> the security table have 2 built-in chains, say, secmark and secfilter,
> and have these chains traversed at the appropriate points as in the
> following example for the INPUT case:
> 
> ...
> mangle PREROUTE

s/PREROUTE/INPUT/

> security SECMARK
> filter INPUT
> security SECFILTER
> ...
> 
> It's also conceivable that we might, in fact, have two tables (secmark
> and secfilter), all things considered.
> 

--
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.