All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Török Edwin" <edwin@gurde.com>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org,
	fireflier-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, martinmaurer@gmx.at
Subject: Re: [PATCH 2.6.15.4 1/1][RFC] ipt_owner: inode match supporting both incoming and outgoing packets
Date: Sat, 18 Feb 2006 22:03:41 +0200	[thread overview]
Message-ID: <200602182203.41823.edwin@gurde.com> (raw)
In-Reply-To: <43F77571.7020100@trash.net>

On Saturday 18 February 2006 21:28, Patrick McHardy wrote:
> Török Edwin wrote:
> > First of all this is what I'd like to achieve:
> > - filter packets by the program who sent the packet
> > - filter packets by the program who is going to receive the packet
> > - when multiple programs share a socket (i.e. they listen on the same
> > socket), allow the packet only if all programs are allowed to receive the
> > packet
>
> Besides the tasklist_lock issues, there is no 1:1 relationship between
> sockets and processes, which is why this can never work. You don't know
> which process is going to receive a packet until it calls recvmsg().
Can sockets be "labeled". Like creating a label for each process, and then 
apply a label to each socket they open. If a socket gets shared, then it gets 
multiple labels.
I see that you talk about SELinux labels below, but is there a way to "label" 
anything without using SELinux? (Maybe by writing another LSM module that 
does just this socket labeling?)
I could then just check the labels to see if a packet is allowed to pass/ or 
not.
>
> There is some work in progress to solve this problem in a different way,
> by adding new hooks to the protocols that get the socket as context,
> and using SElinux labels instead of process names/inodes/whatever for
> matching.
Could you tell me on which thread/mailing list this discussion/(work in 
progress) is taking place? I'd like to follow it.

Thanks
Edwin

  reply	other threads:[~2006-02-18 20:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-18 12:20 [PATCH 2.6.15.4 1/1][RFC] ipt_owner: inode match supporting both incoming and outgoing packets Török Edwin
2006-02-18 19:28 ` Patrick McHardy
2006-02-18 20:03   ` Török Edwin [this message]
2006-02-18 20:07     ` Patrick McHardy
  -- strict thread matches above, loose matches on Subject: below --
2006-02-18 12:10 Török Edwin
2006-02-18 12:25 ` Christoph Hellwig
2006-02-18 12:32   ` Török Edwin
2006-02-18 12:37     ` Christoph Hellwig
2006-02-18 12:47       ` Török Edwin
2006-02-18 13:10         ` Arjan van de Ven
2006-02-18 14:15           ` Török Edwin
2006-02-20 16:26 ` James Morris
2006-02-20 16:42   ` Patrick McHardy
2006-02-20 16:42     ` Patrick McHardy
2006-02-20 17:40   ` Török Edwin
2006-02-20 20:06     ` James Morris

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=200602182203.41823.edwin@gurde.com \
    --to=edwin@gurde.com \
    --cc=fireflier-devel@lists.sourceforge.net \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martinmaurer@gmx.at \
    --cc=netfilter-devel@lists.netfilter.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.