Reiner Sailer
2005-Aug-18 21:02 UTC
[Xen-devel] [PATCH] ACM: adding C-support for policy translation and labeling support for domains
This patch: * adds a C-based security policy translation tool to Xen (secpol_xml2bin) and removes the current Java security policy translator (Java dependencies). The C-based tool integrates into the Xen source tree build and install (using gnome libxml2 for XML parsing). See install.txt. * introduces security labels and related tools. Users can now use semantic-rich label names to put security-tags on domains. See example.txt, policy.txt. * moves the security configuration (currently ACM_USE_SECURITY_POLICY) from xen/Rules.mk into a separate top-level Security.mk file (it is needed by the tools/security and xen/acm). Both xen/acm and tools/security are built during the Xen build process only if ACM_USE_SECURITY_POLICY is not ACM_NULL_POLICY (which is the default setting). Comments welcome! Note: We are currently preparing a patch that introduces a new ACM command (getssid) to retrieve the security types of a running domain. This command is enables domain-internal enforcement functions based on the ACM security policy. Thanks Reiner Signed-off-by Reiner Sailer <sailer@us.ibm.com> Signed-off by Stefan Berger <stefanb@us.ibm.com> Signed-off by Ray Valdez <rvaldez@us.ibm.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
David Palmer
2005-Aug-31 23:11 UTC
Re: [Xense-devel] [PATCH] ACM: adding C-support for policy translation and labeling support for domains
I''m not clear why the getssid() needs to be introduced. Isn''t the problem better solved by introducing new object managers? With the getssid(), the code must know about the specific policy, making the policy less amenable to adjustment as problems are discovered. Wouldn''t it be better for the domains to provide object managers? This would allow the STE policy to make statements about those new objects. The code can be policy neutral by strictly following the decisions of the security server. Wouldn''t this make it easier to revoke policies and update them without having to change the code and patch? Dave On 8/18/05, Reiner Sailer <sailer@us.ibm.com> wrote:> > > This patch: > > * adds a C-based security policy translation tool to Xen (secpol_xml2bin) > and removes the current Java > security policy translator (Java dependencies). The C-based tool > integrates into the Xen source tree build > and install (using gnome libxml2 for XML parsing). See install.txt. > > * introduces security labels and related tools. Users can now use > semantic-rich label names to put security-tags > on domains. See example.txt, policy.txt. > > * moves the security configuration (currently ACM_USE_SECURITY_POLICY) > from xen/Rules.mk > into a separate top-level Security.mk <http://Security.mk> file (it is > needed by the tools/security and xen/acm). > > Both xen/acm and tools/security are built during the Xen build process > only if ACM_USE_SECURITY_POLICY > is not ACM_NULL_POLICY (which is the default setting). > > Comments welcome! > > Note: We are currently preparing a patch that introduces a new ACM command > (getssid) to retrieve the security types > of a running domain. This command is enables domain-internal enforcement > functions based on the ACM security policy. > > Thanks > Reiner > > Signed-off-by Reiner Sailer <sailer@us.ibm.com> > Signed-off by Stefan Berger <stefanb@us.ibm.com> > Signed-off by Ray Valdez <rvaldez@us.ibm.com> > > > _______________________________________________ > Xense-devel mailing list > Xense-devel@lists.xensource.com > http://lists.xensource.com/xense-devel > > > >_______________________________________________ Xense-devel mailing list Xense-devel@lists.xensource.com http://lists.xensource.com/xense-devel
Reiner Sailer
2005-Sep-01 01:10 UTC
[Xen-devel] Re: [Xense-devel] [PATCH] ACM: adding C-support for policy translation and labeling support for domains
Hi Dave, we are introducing the get_ssid ACM command to allow ACM policy-specific decisions and enforcement in policy-aware domains. One can call back into the hypervisor for policy decisions having the benefit you are naming (transparency). However doing this for every IP packet, for example, seems not efficient. Consequently, you''ll end up establishing decision cashes in the domains. Then you have the same problem as before (change in policy) without the performance benefit. If transparency (policy hiding) is the most important factor, then such a solution has merit. Another benefit of getting the whole ssid is that you can re-use this information for other decisions since you get all the types of a domain, not just a yes/no decision. Nothing speaks against having an optional "acm_decision" call that can be used by domains that don''t want to make informed decisions but blindly call the ACM (hypervisor call++ overhead) each time they make a decisions. Such a call might prove useful where decisions are made very infrequently. For example, a virtual block device domain owning a hard drive and allowing other domains to mount certain logical partitions might just ask the ACM for a decision when deciding about accepting a mount-request from a domain to a logical partition (right now, the virtual block device domain is dom0 but this could be refined in the future when other domains can ''own'' peripherals). Regards Reiner xense-devel-bounces@lists.xensource.com wrote on 08/31/2005 07:11:44 PM:> I''m not clear why the getssid() needs to be introduced. Isn''t the > problem better solved by introducing new object managers? With the > getssid(), the code must know about the specific policy, making the > policy less amenable to adjustment as problems are discovered. > Wouldn''t it be better for the domains to provide object managers? > This would allow the STE policy to make statements about those new > objects. The code can be policy neutral by strictly following the > decisions of the security server. Wouldn''t this make it easier to > revoke policies and update them without having to change the code andpatch?> > Dave >> On 8/18/05, Reiner Sailer <sailer@us.ibm.com> wrote: > > This patch: > > * adds a C-based security policy translation tool to Xen > (secpol_xml2bin) and removes the current Java > security policy translator (Java dependencies). The C-based tool > integrates into the Xen source tree build > and install (using gnome libxml2 for XML parsing). See install.txt. > > * introduces security labels and related tools. Users can now use > semantic-rich label names to put security-tags > on domains. See example.txt, policy.txt. > > * moves the security configuration (currently > ACM_USE_SECURITY_POLICY) from xen/Rules.mk > into a separate top-level Security.mk file (it is needed by the > tools/security and xen/acm). > > Both xen/acm and tools/security are built during the Xen build > process only if ACM_USE_SECURITY_POLICY > is not ACM_NULL_POLICY (which is the default setting). > > Comments welcome! > > Note: We are currently preparing a patch that introduces a new ACM > command (getssid) to retrieve the security types > of a running domain. This command is enables domain-internal > enforcement functions based on the ACM security policy. > > Thanks > Reiner > > Signed-off-by Reiner Sailer <sailer@us.ibm.com> > Signed-off by Stefan Berger <stefanb@us.ibm.com> > Signed-off by Ray Valdez <rvaldez@us.ibm.com> > > > _______________________________________________ > Xense-devel mailing list > Xense-devel@lists.xensource.com > http://lists.xensource.com/xense-devel > >> _______________________________________________ > Xense-devel mailing list > Xense-devel@lists.xensource.com > http://lists.xensource.com/xense-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
David Palmer
2005-Sep-01 18:34 UTC
Re: [Xense-devel] [PATCH] ACM: adding C-support for policy translation and labeling support for domains
Is it your experience that decision cache''s aren''t efficient? I thought the theory was that most access checks will be against the local cache in order to make calls to the security server infrequent. This is accomplished by the ACM responding to each decision request with a list of related decisions. As the cache is checked locally, it avoids the context switch and should perform well. By adding a method for the ACM to signal each object manager when to clear the cache, we''re still able to support changing the policy. This could be provided by a standard static library and promoted as the accepted method for creating object managers and should be carefully optimized. By suggesting that domains should make "informed decisions" rather than "blindly call the ACM", are you suggesting that you''ll be making the Xen security policy that everyone else will abide by? To change the policy will require changing code in each "informed" domain that wasn''t designed with that policy in mind. This would eventially make it very costly to change the policy in interesting and new ways. As long as the policy is obviously correct and accepted by everyone who will use Xen, then I suppose there isn''t a problem. Dave On 8/31/05, Reiner Sailer <sailer@us.ibm.com> wrote:> > > Hi Dave, > > we are introducing the get_ssid ACM command to allow ACM policy-specific > decisions > and enforcement in policy-aware domains. > > One can call back into the hypervisor for policy decisions having the > benefit you are > naming (transparency). However doing this for every IP packet, for > example, seems not efficient. > Consequently, you''ll end up establishing decision cashes in the domains. > Then you have the same > problem as before (change in policy) without the performance benefit. If > transparency > (policy hiding) is the most important factor, then such a solution has > merit. Another benefit of > getting the whole ssid is that you can re-use this information for other > decisions since you get > all the types of a domain, not just a yes/no decision. > > Nothing speaks against having an optional "acm_decision" call that can be > used > by domains that don''t want to make informed decisions but blindly call the > ACM > (hypervisor call++ overhead) each time they make a decisions. Such a call > might prove useful > where decisions are made very infrequently. For example, a virtual block > device domain owning a > hard drive and allowing other domains to mount certain logical partitions > might just ask the ACM for > a decision when deciding about accepting a mount-request from a domain to > a logical partition > (right now, the virtual block device domain is dom0 but this could be > refined in the future when other > domains can ''own'' peripherals). > > Regards > Reiner > > xense-devel-bounces@lists.xensource.com wrote on 08/31/2005 07:11:44 PM: > > > I''m not clear why the getssid() needs to be introduced. Isn''t the > > problem better solved by introducing new object managers? With the > > getssid(), the code must know about the specific policy, making the > > policy less amenable to adjustment as problems are discovered. > > Wouldn''t it be better for the domains to provide object managers? > > This would allow the STE policy to make statements about those new > > objects. The code can be policy neutral by strictly following the > > decisions of the security server. Wouldn''t this make it easier to > > revoke policies and update them without having to change the code and > patch? > > > > Dave > > > > > On 8/18/05, Reiner Sailer <sailer@us.ibm.com> wrote: > > > > This patch: > > > > * adds a C-based security policy translation tool to Xen > > (secpol_xml2bin) and removes the current Java > > security policy translator (Java dependencies). The C-based tool > > integrates into the Xen source tree build > > and install (using gnome libxml2 for XML parsing). See install.txt. > > > > * introduces security labels and related tools. Users can now use > > semantic-rich label names to put security-tags > > on domains. See example.txt, policy.txt. > > > > * moves the security configuration (currently > > ACM_USE_SECURITY_POLICY) from xen/Rules.mk > > into a separate top-level Security.mk <http://Security.mk> file (it is > needed by the > > tools/security and xen/acm). > > > > Both xen/acm and tools/security are built during the Xen build > > process only if ACM_USE_SECURITY_POLICY > > is not ACM_NULL_POLICY (which is the default setting). > > > > Comments welcome! > > > > Note: We are currently preparing a patch that introduces a new ACM > > command (getssid) to retrieve the security types > > of a running domain. This command is enables domain-internal > > enforcement functions based on the ACM security policy. > > > > Thanks > > Reiner > > > > Signed-off-by Reiner Sailer <sailer@us.ibm.com> > > Signed-off by Stefan Berger <stefanb@us.ibm.com> > > Signed-off by Ray Valdez <rvaldez@us.ibm.com> > > > > > > _______________________________________________ > > Xense-devel mailing list > > Xense-devel@lists.xensource.com > > http://lists.xensource.com/xense-devel > > > > > > > _______________________________________________ > > Xense-devel mailing list > > Xense-devel@lists.xensource.com > > http://lists.xensource.com/xense-devel >_______________________________________________ Xense-devel mailing list Xense-devel@lists.xensource.com http://lists.xensource.com/xense-devel
Reiner Sailer
2005-Sep-02 00:53 UTC
[Xen-devel] Re: [Xense-devel] [PATCH] ACM: adding C-support for policy translation and labeling support for domains
David Palmer <dwpalmer.xense@gmail.com> wrote on 09/01/2005 02:34:10 PM:> > Is it your experience that decision cache''s aren''t efficient?I must have expressed myself clumsily. Decision caches are extremely efficient as long as we use policies that don''t change often, which is the goal on the hypervisor level.> I thought the theory was that most access checks will be against the > local cache in order to make calls to the security server > infrequent. This is accomplished by the ACM responding to each > decision request with a list of related decisions. As the cache is > checked locally, it avoids the context switch and should perform > well. By adding a method for the ACM to signal each object manager > when to clear the cache, we''re still able to support changing the > policy. This could be provided by a standard static library and > promoted as the accepted method for creating object managers and > should be carefully optimized.The sHype security architecture for Xen is designed so that you can choose. If you like to have "policy-unaware" domains then this is absolutely OK. In this case some trusted domains act simply as the long arm of Xen access control enforcement. Additionally, you can only get decisions from the hypervisor that are based on what the hypervisor knows. For example, the hypervisor does not know about disk drives and other peripherals. You could submit the security reference of a device and the id of a domain and let the hypervisor ACM make the decision but it seems more natural that those domains that manage the peripheral make the decision (they are trusted and part of the security architecture anyway and they might have additional information on which the decision can be based). The security policy that controls sharing is (intentionally) extremely simple to implement.> By suggesting that domains should make "informed decisions" rather > than "blindly call the ACM", are you suggesting that you''ll be > making the Xen security policy that everyone else will abide by?The point I hoped to make in my last mail is quite the opposite of what I hear you saying: By exposing all the policy information (types) to appropriately privileged domains, we actually empower policy-aware domains to make their own access control decisions. Such decisions can be simply based on the received hypervisor security types, but they can also be based on additional security information available to these domains (for example: the history of users of a disk partition). When we thought about it, we felt that the "decision call" approach (that you are suggesting) is opposing the ACM policies onto upper layers (e.g. OS) and limiting them in participation in decisions. Thanks Reiner> On 8/31/05, Reiner Sailer <sailer@us.ibm.com> wrote: > > Hi Dave, > > we are introducing the get_ssid ACM command to allow ACM policy- > specific decisions > and enforcement in policy-aware domains. > > One can call back into the hypervisor for policy decisions having > the benefit you are > naming (transparency). However doing this for every IP packet, for > example, seems not efficient. > Consequently, you''ll end up establishing decision cashes in the > domains. Then you have the same > problem as before (change in policy) without the performance > benefit. If transparency > (policy hiding) is the most important factor, then such a solution > has merit. Another benefit of > getting the whole ssid is that you can re-use this information for > other decisions since you get > all the types of a domain, not just a yes/no decision. > > Nothing speaks against having an optional "acm_decision" call that > can be used > by domains that don''t want to make informed decisions but blindly > call the ACM > (hypervisor call++ overhead) each time they make a decisions. Such a > call might prove useful > where decisions are made very infrequently. For example, a virtual > block device domain owning a > hard drive and allowing other domains to mount certain logical > partitions might just ask the ACM for > a decision when deciding about accepting a mount-request from a > domain to a logical partition > (right now, the virtual block device domain is dom0 but this could > be refined in the future when other > domains can ''own'' peripherals). > > Regards > Reiner > > xense-devel-bounces@lists.xensource.com wrote on 08/31/2005 07:11:44 PM: > > > > I''m not clear why the getssid() needs to be introduced. Isn''t the > > problem better solved by introducing new object managers? With the > > getssid(), the code must know about the specific policy, making the > > policy less amenable to adjustment as problems are discovered. > > Wouldn''t it be better for the domains to provide object managers? > > This would allow the STE policy to make statements about those new > > objects. The code can be policy neutral by strictly following the > > decisions of the security server. Wouldn''t this make it easier to > > revoke policies and update them without having to change the code andpatch?> > > > Dave > > > > > On 8/18/05, Reiner Sailer <sailer@us.ibm.com> wrote: > > > > This patch: > > > > * adds a C-based security policy translation tool to Xen > > (secpol_xml2bin) and removes the current Java > > security policy translator (Java dependencies). The C-based tool > > integrates into the Xen source tree build > > and install (using gnome libxml2 for XML parsing). See install.txt. > > > > * introduces security labels and related tools. Users can now use > > semantic-rich label names to put security-tags > > on domains. See example.txt, policy.txt. > > > > * moves the security configuration (currently > > ACM_USE_SECURITY_POLICY) from xen/Rules.mk > > into a separate top-level Security.mk file (it is needed by the > > tools/security and xen/acm). > > > > Both xen/acm and tools/security are built during the Xen build > > process only if ACM_USE_SECURITY_POLICY > > is not ACM_NULL_POLICY (which is the default setting). > > > > Comments welcome! > > > > Note: We are currently preparing a patch that introduces a new ACM > > command (getssid) to retrieve the security types > > of a running domain. This command is enables domain-internal > > enforcement functions based on the ACM security policy. > > > > Thanks > > Reiner > > > > Signed-off-by Reiner Sailer <sailer@us.ibm.com> > > Signed-off by Stefan Berger <stefanb@us.ibm.com> > > Signed-off by Ray Valdez <rvaldez@us.ibm.com> > > > > > > _______________________________________________ > > Xense-devel mailing list > > Xense-devel@lists.xensource.com > > http://lists.xensource.com/xense-devel > > > > > > > _______________________________________________ > > Xense-devel mailing list > > Xense-devel@lists.xensource.com > > http://lists.xensource.com/xense-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel