All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Chris Wright <chrisw@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] update: _working_ code to add device+inode check to ipt_owner.c
Date: Fri, 10 Sep 2004 01:08:19 +0100	[thread overview]
Message-ID: <20040910000819.GA7587@lkcl.net> (raw)
In-Reply-To: <20040909160449.E1924@build.pdx.osdl.net>

On Thu, Sep 09, 2004 at 04:04:49PM -0700, Chris Wright wrote:

> >  what's the disconnect between the task_list and the sockets (sk_buff)
> >  that makes that [not knowing which one will be woken up] relevant?
> 
> There's nothing stopping the following:  
> 
> exec good_proc
> 	socket()
> 	fork
> 	exec bad_proc
 
> Now good_proc and bad_proc are sharing a socket.  Packet comes in
> destined for that socket.  Rule says it's ok to deliver to socket
> (because of good_proc).  

> Packet delivered to socket, wakes up waiters
> (good and bad).  Now, what's stopping the bad_proc from reading from the
> socket?

 okay.

 i am not so worried about this scenario _because_:

 under an selinux system, you would set up a policy which only
 allowed the good_proc to exec other_good_procs (with the
 macro can_exec(good_proc, { other_good_proc1, other_good_proc2 })


 consequently, you'd design your firewall rules (in conjunction with
 your selinux policy) to add _two_ dev+inode-program-enabled firewall rules
 to cover the same socket, e.g. apache2 (good_proc) and some cgi script
 helper (other_good_proc) - one for each program:

	 iptables -A INPUT -m tcp --dport=80 -m program --exe=/usr/bin/apache2 -j ACCEPT

 and:

	 iptables -A INPUT -m tcp --dport=80 -m program --exe=/usr/cgi-bin/blahblah -j ACCEPT

 
> >  so it's a socket: let's take an example - and i'm assuming for now
> >  that things like passing file descriptors over unix-domain-sockets
> >  between processes just ... doesn't happen, okay? :)
> 
> These do happen, which is part of the problem ;-)
 
 i would not consider this to be a problem [in an environment where
 you specify DENY as the default and ALLOW specific instances]

 under such circumstances [file descs passed between programs]...
 you would end up having to create _two_ program-specific rules, like
 above.

 one for each of the two programs.

 [this has got to be better than the present situation, where you have
  to "iptables -A OUTPUT -m tcp --sport=25" and that allows ANY process
  under the sun to have data escaping on port 25.]

 l.

-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


  reply	other threads:[~2004-09-09 23:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-09 16:22 [patch] update: _working_ code to add device+inode check to ipt_owner.c Luke Kenneth Casson Leighton
2004-09-09 16:19 ` Chris Wright
2004-09-09 18:10   ` Luke Kenneth Casson Leighton
2004-09-09 18:48     ` Chris Wright
2004-09-09 21:25       ` Luke Kenneth Casson Leighton
2004-09-09 23:04         ` Chris Wright
2004-09-10  0:08           ` Luke Kenneth Casson Leighton [this message]
2004-09-10  0:21             ` Chris Wright
2004-09-10  0:59               ` Luke Kenneth Casson Leighton
2004-09-10  1:08                 ` Chris Wright
2004-09-10  1:34                   ` Luke Kenneth Casson Leighton
2004-09-09 21:38     ` Luke Kenneth Casson Leighton
2004-09-09 23:41       ` Chris Wright
2004-09-10  0:10         ` Luke Kenneth Casson Leighton
2004-09-09 16:29 ` Stephen Smalley
2004-09-09 16:33   ` Stephen Smalley
2004-09-09 17:44   ` Luke Kenneth Casson Leighton

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=20040910000819.GA7587@lkcl.net \
    --to=lkcl@lkcl.net \
    --cc=chrisw@osdl.org \
    --cc=linux-kernel@vger.kernel.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.