Re: XML Based Policy Configuration for SELinux

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Tue, Jun 21, 2005 at 02:59:42PM -0500, alexander-barclay@utulsa.edu wrote:
> >  this is not useful.
> > 
> >  tools to translate the *.fc, *.te, users file, etc.?
> > 
> >  that's useful.
> > 
> >  just my independent, uninformed, enthusiastic, inadviseable,
> >  egoistical and impartial opinion.
> > 
> >  l.
> 
> 
> 
> Hey Luke, thanks for your honest opinion, it is appreciated. This project was conceived over a year ago, and we as a research group have learned a lot in this timeframe.
> 
> The reasoning at the time was to work on the policy.conf since it is a        worst case scenario of the policy configuration, 

 it is not a worst-case scenario: the policy.conf file is completely
 _useless_ on its own as it only makes sense in combination with
 file_contexts and the tunables (i might have missed something else
 out... hmmm)

 policy.conf is an "intermediary": do not be deceived by it being in a
 readable flat file format!

 it's a bit like .S assembly files in that respect.  .S assembly files
 are in a readable flat file format - but nobody in their right minds
 writes code on a day-to-day basis in assembler these days except for
 extremely specialised purposes.


> and to be honest we were not sure that the fc/te/* files would stay the same format. In addition we were planning a suite of tools to work on the XML policy that would help with common configuration tasks etc. 

 okay.

 how should i put this.

 if you can provide an entire policy-development toolchain
 that can "read in" policy.conf and file_context files as an
 intial starting point, that is equivalent to or better than the
 present system [the present system compiles from the contents
 of /etc/selinux/src/* which includes *.te, *.fc, net_contexts,
 users, serviceusers, mls and rbac, _and_ incorporates the
 use of the program genhomedircon], then _great_.

 [i realise that's a long sentence].
 
 i.e. you have two (actually three but one of them's insane) jump-in points:

 - 1) policy.conf + file_contexts + tunables
 - 2) policy.NN + file_contexts + tunables
 - 3) /etc/selinux/src/* (*.te, *.fc, users, mls, rpac, net_contexts etc) +
      tunables

 if you go for 3) then anything you write is an _enhancement_ of
 the existing toolchain and the formal analysis tools developed
 to-date, including those written by that japanese company who
 did a webmin module for selinux policy (no they don't provide
 source code, damnit), and tresys's tools, and everyone's
 knowledge and understanding of the macros developed to date
 over the past four or five years.
 
 if you go for 2) then you are bypassing that entire selinux toolchain
 and collective knowledge [this is the insane option].

 if you go for 1) then you are also bypassing almost all of
 the selinux toolchain except for the binary policy converter,
 and bypassing all of the formal analysis tools.


 3) is the only "sane" - read acceptable - answer.

 not least because it requires that your code "understand"
 the key concepts supported in python code by the program
 genhomedircon, and the concept of users being associated [by
 their unix username] with multiple roles (user_r, staff_r,
 sysadm_r etc.)

 which are actually quite difficult - if not impossible - to
 "extract" from the policy.conf file, in isolation, with no
 access to the "users" file.


 basically, policy.conf and file_contexts do not provide the "full
 picture" that would make the representation of selinux policy in XML
 file format "useful" to developers and sysadmins.


 wish list item 1):

 * the ability to read /etc/selinux/src/* (*.te, *.fc, users,
   mls, rpac, net_contexts etc) + tunables into an XML formatted file

   whilst still recognising that certain areas of the policy are to do
   with certain programs / services.

   i.e. reflecting the directory "domains" and the individual files _in_
   domains in the tree structure of the XML document.  i.e. giving
   apache.te its own "node" hierarchy as distinct and completely
   separate from "src/domains//misc/kernel.te".

 wish list item 2)

 * the ability to output /etc/selinux/src/* (*.te, *.fc, users,
   mls, rpac, net_contexts etc) + tunables etc from an XML
   formatted file.
 
 _that's_ useful.

 l.

 
 
> On a side note, this thesis work was done by Tyronne Nash who passed away days before completion. We honor his spirit and seek to further his work.
 
 *respectful salute*.


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