LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: Tilman Baumann <tilman.baumann@collax.com>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>,
	Casey Schaufler <casey@schaufler-ca.com>,
	linux-security-module@vger.kernel.org
Subject: Re: SMACK netfilter smacklabel socket match
Date: Thu, 25 Sep 2008 15:57:21 -0400	[thread overview]
Message-ID: <200809251557.21623.paul.moore@hp.com> (raw)
In-Reply-To: <89D091CB-9AE1-4792-AD3F-98754AF13C19@collax.com>

On Thursday 25 September 2008 3:26:40 pm Tilman Baumann wrote:
> 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
> > SECMARK
> > 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
> complex.
>
> 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
> the right person to do it.
> Il try to understand the inner workings of the SECMARK stuff tough.

With SELinux the packet's CIPSO label (called the packet's peer label) 
is different from the SECMARK label.  Assuming you take a similar 
approach in Smack, you should be able to implement SECMARK without 
having to every concern yourself with the CIPSO label.

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

Yes, in the absence of the sending socket to obtain the packet's peer 
label you need to examine the packet itself and any labeling 
information present on the packet; in the case of Smack this is CIPSO.

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

Well, if you are accepting or dropping packets you are applying some 
form of access control.  I thought that was the point of your patch?  
If not perhaps I misunderstood or assumed too much.

> 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
> way.
> Please correct me if i understood you wrong.

Hmmm, the term "capability" is probably not the best term to use, but 
there are valid reasons to use the netfilter mechanism, i.e. SECMARK, 
to apply a network label to both incoming and outgoing packets.  The 
idea is that this allows the LSM to make network access control 
decisions based on the network attributes of a packet (address, 
protocol, port, etc.) and the powerful packet/connection matching 
mechanisms in netfilter.

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

I think I understand you goal now, essentially you want to route traffic 
based on the security label of the sender, yes?  There was some brief 
talk about this at the SELinux Developer's Summit this year at OLS.  
Unfortunately, it was just a casual conversation and I haven't seen any 
patches since then implementing security label based routing.

-- 
paul moore
linux @ hp

  reply	other threads:[~2008-09-25 19:58 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
2008-09-25 19:57     ` Paul Moore [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=200809251557.21623.paul.moore@hp.com \
    --to=paul.moore@hp.com \
    --cc=casey@schaufler-ca.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=tilman.baumann@collax.com \
    --subject='Re: SMACK netfilter smacklabel socket match' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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