LKML Archive on
help / color / mirror / Atom feed
From: Tilman Baumann <>
To: Paul Moore <>
Cc: Linux-Kernel <>,
	Casey Schaufler <>,
Subject: Re: SMACK netfilter smacklabel socket match
Date: Thu, 25 Sep 2008 21:26:40 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Am 25.09.2008 um 20:26 schrieb Paul Moore:

> On Thursday 25 September 2008 1:25:53 pm Tilman Baumann wrote:

>> The intention behind this patch is that i needed a way to (firewall)
>> match for packets originating from specific processes.
>> The existing owner match did not work well enough, especially since
>> the cmd-owner part is removed.
>> Then i thought about a way to tag processes and somehow match this
>> tag in the firewall.
>> I recalled that SELinux can do this (SECMARK) but SELinux would have
>> been way to complex for what i want. But the idea was born, i just
>> needed something more simple.
> It appears the simplest option would be to provide the necessary  
> support in Smack.  SECMARK has provisions for supporting different
> types of LSMs and adding Smack support should be relatively trivial.
> In fact, it is possible for SECMARK to be made entirely LSM agnostic
> and have it deal strictly with secctx/label and secid/token values.   
> We
> would need to retain the SELinux specific interface for
> legacy/compatibility reasons but I would encourage new patches to take
> this more general approach rather than LSM specific extension.

Sounds like a good idea. When i looked at the SECMARK code i could not  
get my
head around the SELinux specific stuff, so i discarded the idea as to  

For this to be complete i guess the CIPSO labels for SMACK would need
to be taken into account.
Far more than my quick and dirty approach, and probably more than i'm  
right person to do it.
Il try to understand the inner workings of the SECMARK stuff tough.

I will come back to your other comments tomorrow.

> [NOTE: you may notice the above code changing slightly in future
> kernels, it turns out that skb->sk == NULL is not a true indicator  
> of a
> non-local sender, see my labeled networking patches for 2.6.28 or
> linux-next for the revised approach]
Good to know.

>> This of course only works for packets with a local socket, but this
>> was my intention anyway.
> You could also expand it to handle non-local senders.  However, from  
> my
> discussions with Casey about Smack and network access controls,
> enforcing policy against forwarded traffic is not something he is
> interested in at this point.

I have not investigated further into that, but if there is some way to
match on CIPSO labels, there would be at least a vehicle to base this  

>> I have no kernel coding experience whatsoever and little C coding
>> history. So i would really like you guys to look over it a bit.
> [NOTE: you will want to post your patches inline in the future,  
> sending
> patches as attachments are frowned upon]

> I don't like how the access control is being done outside of the Smack
> LSM; once again I would encourage you to further investigate the
> approach taken by SECMARK.  If you must do access control outside of
> the LSM then please at least abstract the actual access control
> decision, in this case strncmp(), to a LSM interface.

Access control was actually not what i needed in this case.
This would in this case as far as i know actually be done in the SMACK  
I'm not sure how much it would make sense to base firewall decisions on
capability checks (i guess this is what you referring to).
Like decisions in the form of who/what may access a process in which  
Please correct me if i understood you wrong.

What i do with this match is just setting some CONNMARK and respectively
FWMARKS to make crazy routing rules for different kinds (marked  
of my outgoing traffic based on them.


  reply	other threads:[~2008-09-25 19:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-25 17:25 Tilman Baumann
2008-09-25 18:26 ` Paul Moore
2008-09-25 19:26   ` Tilman Baumann [this message]
2008-09-25 19:57     ` Paul Moore
2008-09-25 20:32       ` Tilman Baumann
2008-09-26 12:35   ` Tilman Baumann
2008-09-26 19:55     ` Paul Moore
2008-09-26  3:43 ` Casey Schaufler
2008-09-26  8:19   ` Tilman Baumann
2008-09-27  5:01     ` Casey Schaufler
2008-09-29 16:21       ` Tilman Baumann
2008-09-30  3:29         ` Casey Schaufler
2008-10-01 11:29           ` Tilman Baumann
2008-10-01 15:21             ` Casey Schaufler
2008-10-01 16:55               ` Tilman Baumann
2008-10-01 18:22                 ` Casey Schaufler
2008-10-06 12:57                   ` Tilman Baumann
2008-10-06 23:05                     ` Ahmed S. Darwish
2008-10-07  2:42                     ` Casey Schaufler
2008-10-17 16:57                       ` Tilman Baumann
2008-10-17 17:53                         ` Casey Schaufler
2008-10-20 12:06                           ` Tilman Baumann
2008-10-20 15:01                             ` Casey Schaufler
2008-10-22  3:36                             ` Casey Schaufler
2008-10-30 16:06                               ` Tilman Baumann
2008-10-31  3:46                                 ` Casey Schaufler
2008-12-11  0:03                                 ` Casey Schaufler
2008-12-11 10:18                                   ` Tilman Baumann
2008-12-11 16:29                                     ` Casey Schaufler
2008-10-23 11:55                           ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: SMACK netfilter smacklabel socket match' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).