linux-kernel - Re: [PATCH][SMACK] add a socket_post_accept hook to fix netlabel issues with labeled TCP servers V1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49A4E4F6.5010404@numericable.fr>
Date:	Wed, 25 Feb 2009 07:28:06 +0100
From:	etienne <etienne.basset@...ericable.fr>
To:	Casey Schaufler <casey@...aufler-ca.com>
CC:	Paul Moore <paul.moore@...com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	LSM <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH][SMACK] add a socket_post_accept hook to fix netlabel
 issues with labeled TCP servers V1

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/