public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Wright <chrisw@osdl.org>
To: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Cc: Chris Wright <chrisw@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [patch] update: _working_ code to add device+inode check to ipt_owner.c
Date: Thu, 9 Sep 2004 17:21:35 -0700	[thread overview]
Message-ID: <20040909172134.G1924@build.pdx.osdl.net> (raw)
In-Reply-To: <20040910000819.GA7587@lkcl.net>; from lkcl@lkcl.net on Fri, Sep 10, 2004 at 01:08:19AM +0100

* Luke Kenneth Casson Leighton (lkcl@lkcl.net) wrote:
>  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 })

OK, good.  Although, this does not help xinetd, so we're still trusting
that code.

>  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

Isn't this likely to be in modcgi/modperl/etc instead of fork/exec'd?
This is one specific example (which SELinux doesn't support, so it's
moot there) where changing security domains during execution would
confuse these rules.  E.g. reducing to a more restrictive domain while
executing cgi-scripts.

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

Actually you wouldn't, just one.  It will match, then one of those
processes will get woken up and receive the data, regardless of whether
you meant to allow it.  So, having some security layer involved mediated
file desc passing clearly helps.  Point remains, any match will deliver
data to socket.  However, if socket is shared, it could be a different
process picking up data off of socket.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

  reply	other threads:[~2004-09-10  0:22 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
2004-09-10  0:21             ` Chris Wright [this message]
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=20040909172134.G1924@build.pdx.osdl.net \
    --to=chrisw@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkcl@lkcl.net \
    /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