public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Paul Moore <paul.moore@hp.com>
Cc: etienne <etienne.basset@numericable.fr>,
	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: Tue, 24 Feb 2009 19:28:08 -0800	[thread overview]
Message-ID: <49A4BAC8.30708@schaufler-ca.com> (raw)
In-Reply-To: <200902241836.59679.paul.moore@hp.com>

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

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  3: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 [this message]
2009-02-25  6:28             ` etienne
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=49A4BAC8.30708@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=etienne.basset@numericable.fr \
    --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