| |
|
 |
|
 |
|
|
|
| |
|
|
xense-devel
Re: [Xense-devel] [PATCH] ACM: adding C-support for policy translation a
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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxx>
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@xxxxxxxxxx>
> Signed-off by Stefan Berger <stefanb@xxxxxxxxxx>
> Signed-off by Ray Valdez <rvaldez@xxxxxxxxxx>
>
>
> _______________________________________________
> Xense-devel mailing list
> Xense-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xense-devel
>
>
> _______________________________________________
> Xense-devel mailing list
> Xense-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xense-devel
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
|
|
|
| |
|
Home