In the standard policy most of the kernel/service modules allow access to unlabelled traffic, interfaces and nodes.
I have a simple question regarding this: if I were to write an additional module and include neverallow statement to deny previously granted access to such resources would this be enough (my understanding of neverallow is that it just checks whether previous 'allow' statements were issued and if so, generates a warning and stops)?
If neverallow is not the way to go, what could I do, short of altering every single policy file and remove the appropriate allow statements, to disable such access to the above resources?
On Tue, 2010-09-21 at 12:18 +0100, Mr Dash Four wrote:
In the standard policy most of the kernel/service modules allow access to unlabelled traffic, interfaces and nodes.
I have a simple question regarding this: if I were to write an additional module and include neverallow statement to deny previously granted access to such resources would this be enough (my understanding of neverallow is that it just checks whether previous 'allow' statements were issued and if so, generates a warning and stops)?
If neverallow is not the way to go, what could I do, short of altering every single policy file and remove the appropriate allow statements, to disable such access to the above resources?
neverallow rules are not "deny" rules but are instead assertions on the policy that will prevent compiling/linking from completing. And Fedora disables the neverallow checking these days (via expand-check=0 in /etc/selinux/semanage.conf) because it was a) slow, and b) generally not useful to end users (vs. policy developers, who can use the 'make validate' refpolicy Makefile target to force a check or can edit their semanage.conf files to match their needs).
There is work in progress for policy language support for transformations of policy, including the ability to delete rules, but it is still in the early development stages.
For what you want to do, there is unfortunately no good mechanism at present other than creating your own custom policy.
What you might do though is to wrap the problematic allow rules under tunable_policy blocks with some new policy boolean, and then you could enable/disable those rules by setting the boolean. That might be acceptable as a patch to the current policy that wouldn't disrupt current users.
There is work in progress for policy language support for transformations of policy, including the ability to delete rules, but it is still in the early development stages.
For what you want to do, there is unfortunately no good mechanism at present other than creating your own custom policy.
What you might do though is to wrap the problematic allow rules under tunable_policy blocks with some new policy boolean, and then you could enable/disable those rules by setting the boolean. That might be acceptable as a patch to the current policy that wouldn't disrupt current users.
That, frankly, is hair-raising stuff! It means that I would have to edit every single .te/.if file and encapsulate those blocks, not very nice... I think I already asked this before, but isn't there another - easier - way of doing this?
On Tue, 2010-09-21 at 13:25 +0100, Mr Dash Four wrote:
There is work in progress for policy language support for transformations of policy, including the ability to delete rules, but it is still in the early development stages.
For what you want to do, there is unfortunately no good mechanism at present other than creating your own custom policy.
What you might do though is to wrap the problematic allow rules under tunable_policy blocks with some new policy boolean, and then you could enable/disable those rules by setting the boolean. That might be acceptable as a patch to the current policy that wouldn't disrupt current users.
That, frankly, is hair-raising stuff! It means that I would have to edit every single .te/.if file and encapsulate those blocks, not very nice... I think I already asked this before, but isn't there another - easier - way of doing this?
Not today. That's why there is ongoing work on extensions to the policy language to support such transformations, as well as work on the policy infrastructure to support notions of priorities and localization.
There is work in progress for policy language support for transformations of policy, including the ability to delete rules, but it is still in the early development stages.
For what you want to do, there is unfortunately no good mechanism at present other than creating your own custom policy.
What you might do though is to wrap the problematic allow rules under tunable_policy blocks with some new policy boolean, and then you could enable/disable those rules by setting the boolean. That might be acceptable as a patch to the current policy that wouldn't disrupt current users.
That, frankly, is hair-raising stuff! It means that I would have to edit every single .te/.if file and encapsulate those blocks, not very nice... I think I already asked this before, but isn't there another - easier - way of doing this?
Not today. That's why there is ongoing work on extensions to the policy language to support such transformations, as well as work on the policy infrastructure to support notions of priorities and localization.
OK, I found 'a solution' which is to define a distinct packet type (say 'type unnamed_packet_t, packet_type, client_packet_t, server_packet_t;') and label all traffic which is not already labelled with this new type. Any domains in the default policy not already 'caught' by the traffic labelling where their traffic is explicitly named and enabled (through iptables) will not be allowed access to packets.
I do not like this 'solution' for at least two reasons:
1. It does not fix the initial problem and completely deny access to domains who are defined to have access to unlabelled interfaces, nodes and packets (for example they can still bind to unlabelled nodes/interfaces); and
2. It still allows domains which have been allowed access to the general 'packet_type' (with or without 'server_packet_t' and/or 'client_packet_t' attributes set) as the above type (unnamed_t) has these attributes as well.
I am open to any better suggestions that might be out there (except for going through every single policy file and manually 'wrapping' the offensive code with booleans - this, for me, is not a solution at all).
selinux@lists.fedoraproject.org
-
Mr Dash Four -
Stephen Smalley