Stephen Smalley wrote:

>On Tue, 2004-11-23 at 13:52, James Carter wrote:
>
>
>>I am OK with what the changes do, but I would rather see a new macro
>>then to just remove the connect permission from can_network().
>>
>>On the other hand, it looks like there is 119 uses of can_network() and
>>Dan is only adding 32 lines with connect permissions, so only 25% seem
>>to need the connect permisison.
>>
>>Would anyone be upset if the functionality of can_network() changes?
>>
>>Any comments?
>>
>>
>
>My preference: Feel free to refactor can_network() into smaller macros
>that can_network() then includes, but don't change the overall set of
>permissions allowed by can_network(). Instead, change the calling
>domains to use the smaller macros as appropriate, e.g. can_tcp_server()
>for domains that just want bind/listen/accept (and the usual permissions
>for basic use of the socket), can_tcp_client() for domains that just
>want connect (and the usual permissions for basic use of the socket).
>If you are reading policy and you see can_network(), you should be able
>to assume unrestricted use of the network. If you see can_tcp_client(),
>you get a clear sense as to what that means.
>
>
>

Well thats ok, but it means we change 87 instances and leave 19 instances. Which does not make much sense to me.
We are still treating name_bind separately. I see bind and connect being the similar access rights. IE Both are used to "connect" a port to a socket. So why aren't we talking about moving name_bind into the can_network series of connections?
I still think we need ability to specify which ports a network can connect to.
Any movement on providing this capability?

I can add

can_network_server()
can_network_client()
can_tcp_server()
can_tcp_client()
can_udp_server()
can_udp_client()

And then retain can_network

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.