public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox