From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Palmer Subject: Re: [Xense-devel] [PATCH] ACM: adding C-support for policy translation and labeling support for domains Date: Wed, 31 Aug 2005 16:11:44 -0700 Message-ID: <7d415b2805083116114dd152@mail.gmail.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0812124234==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Reiner Sailer Cc: Ray Valdez , xen-devel@lists.xensource.com, Stefan Berger , xense-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============0812124234== Content-Type: multipart/alternative; boundary="----=_Part_5649_3071520.1125529904451" ------=_Part_5649_3071520.1125529904451 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'm not clear why the getssid() needs to be introduced. Isn't the problem= =20 better solved by introducing new object managers? With the getssid(), the= =20 code must know about the specific policy, making the policy less amenable t= o=20 adjustment as problems are discovered. Wouldn't it be better for the domain= s=20 to provide object managers? This would allow the STE policy to make=20 statements about those new objects. The code can be policy neutral by=20 strictly following the decisions of the security server. Wouldn't this make= =20 it easier to revoke policies and update them without having to change the= =20 code and patch? Dave On 8/18/05, Reiner Sailer wrote: >=20 >=20 > This patch:=20 >=20 > * adds a C-based security policy translation tool to Xen (secpol_xml2bin)= =20 > and removes the current Java=20 > security policy translator (Java dependencies). The C-based tool=20 > integrates into the Xen source tree build=20 > and install (using gnome libxml2 for XML parsing). See install.txt.=20 >=20 > * introduces security labels and related tools. Users can now use=20 > semantic-rich label names to put security-tags=20 > on domains. See example.txt, policy.txt.=20 >=20 > * moves the security configuration (currently ACM_USE_SECURITY_POLICY)=20 > from xen/Rules.mk=20 > into a separate top-level Security.mk file (it is=20 > needed by the tools/security and xen/acm).=20 >=20 > Both xen/acm and tools/security are built during the Xen build process=20 > only if ACM_USE_SECURITY_POLICY=20 > is not ACM_NULL_POLICY (which is the default setting).=20 >=20 > Comments welcome!=20 >=20 > Note: We are currently preparing a patch that introduces a new ACM comman= d=20 > (getssid) to retrieve the security types=20 > of a running domain. This command is enables domain-internal enforcement= =20 > functions based on the ACM security policy.=20 >=20 > Thanks=20 > Reiner=20 >=20 > Signed-off-by Reiner Sailer =20 > Signed-off by Stefan Berger =20 > Signed-off by Ray Valdez =20 >=20 >=20 > _______________________________________________ > Xense-devel mailing list > Xense-devel@lists.xensource.com > http://lists.xensource.com/xense-devel >=20 >=20 >=20 > ------=_Part_5649_3071520.1125529904451 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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@u= s.ibm.com> wrote:

This patch:

* adds a C-based security policy t= ranslation tool to Xen (secpol_xml2bin) and removes the current Java
security policy translator (Java d= ependencies).  The C-based tool integrates into the Xen source tree build
and install (using gnome libxml2 f= or XML parsing). See install.txt.

* introduces security labels and r= elated tools. Users can now use semantic-rich label names to put security-tags
on domains. See example.txt, polic= y.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 ar= e built during the Xen build process only if ACM_USE_SECURITY_POLICY
is not ACM_NULL_POLICY (which is t= he 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.xensour= ce.com/xense-devel




------=_Part_5649_3071520.1125529904451-- --===============0812124234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0812124234==--