public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: etienne <etienne.basset@numericable.fr>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Paul Moore <paul.moore@hp.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	LSM <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH][SMACK] add a socket_post_accept hook to fix netlabel issues with labeled TCP servers V1
Date: Wed, 25 Feb 2009 07:28:06 +0100	[thread overview]
Message-ID: <49A4E4F6.5010404@numericable.fr> (raw)
In-Reply-To: <49A4BAC8.30708@schaufler-ca.com>

Casey Schaufler wrote:
> Paul Moore wrote:
>> ...
>>> well, i think it is simple : let's say i want to run a "smack-labelled
>>> server" (apache, vsftpd, ...) clients connect from internet,  so the server
>>> admin/user  will want to add a "0.0.0.0/0 @" entry in netlabel that will
>>> _fail_ because the server will send back "labeled" packets.
>>>     
>> I had to go back and look at the address based labeling patches, I had somehow 
>> forgotten that the single label support in Smack can only be used for removing 
>> labels, not adding them.  With that in mind your approach should work although 
>> you will still get really bizarre behavior in the following case:
>>
>>  * Service not running at the ambient label
>>  * Only address based label loaded into Smack is "0.0.0.0/0 @" (everything
>>    unlabeled)
>>  * Client connects to service using labeled networking
>>
>> If you and Casey can live with labeled connection suddenly becoming unlabeled 
>> (I doubt the remote host will deal with it very gracefully) then go for it.
>>   
> 
> The case where the netlabel entry "0.0.0.0/0 @" has been added
> will unfortunately be a very common case because it say that while
> the local machine does MAC the world as a whole does not. It also
> means that the admin does not understand the implication that
> local networking will no longer enforce MAC controls, or that for
> some bizarre reason that it what he wants. In either case it is
> very unlikely that he expects to connect to another system that
> speaks CIPSO. For that reason I expect that the "bizarre behavior"
> of labeled hosts to be quite rare.
> 
> I think that it might be necessary to introduce mechanism to specify
> labeled hosts in addition to unlabeled hosts. That way one could
> specify:
>     0.0.0.0/0       @
>     127.0.0.1       CIPSO
>     192.168.1.103   CIPSO
> 
yes, i guess it makes a lot of sense; the corp network can be labeled
but internet will stay  unlabeled 


> and let everyone except the local host be unlabeled while the local
> host enforces Real MAC policy.
> 
> I personally find it reprehensible that the attitude that network
> communications ought to be exempt from access controls is so
> pervasive, but I bend to the will of the people. The interest in
> Smack since the introduction of the web ("@") label has grown
> dramatically.
> 
> I am still reviewing and verifying these patches, which look
> fine so far, but I know better than to let my eyes make the
> call when I have computers that are so much better at finding
> software flaws.
> 
> Thank you again for the work and reviews. I am working on my
> end. Really.
> 
> 
> 


  reply	other threads:[~2009-02-25  6:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.eUdEnVYPYgnfwD9aw1dVY6gL1+E@ifi.uio.no>
     [not found] ` <fa.BogfdiS32WCl3kqw5KFzeBPP0jc@ifi.uio.no>
2009-02-24 22:20   ` [PATCH][SMACK] add a socket_post_accept hook to fix netlabel issues with labeled TCP servers V1 etienne
2009-02-24 22:38     ` Paul Moore
2009-02-24 22:59       ` etienne
2009-02-24 23:36         ` Paul Moore
2009-02-25  3:28           ` Casey Schaufler
2009-02-25  6:28             ` etienne [this message]
2009-02-25  6:47           ` etienne
2009-02-25 17:21           ` Paul Moore
2009-02-25 23:40             ` etienne
2009-02-24 21:28 etienne
2009-02-24 21:50 ` 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=49A4E4F6.5010404@numericable.fr \
    --to=etienne.basset@numericable.fr \
    --cc=casey@schaufler-ca.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul.moore@hp.com \
    /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