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.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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