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]
Date:	Tue, 24 Feb 2009 19:28:08 -0800
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Paul Moore <paul.moore@...com>
CC:	etienne <etienne.basset@...ericable.fr>,
	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

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.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ