XML Based Policy Configuration for SELinux

XML Based Policy Configuration for SELinux

[Brandon Pollet]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

Recently there was a discussion about using XML in SELinux policy and  
so I wanted send out this Master's Report by Tyronne Nash. This paper  
covers some of the work we have done at the University of Tulsa to  
convert and extend the SELinux policy language with an XML  
specification. The abstract and a link to the full document are  
contained below. Let me know what you think.

thanks,
Brandon Pollet

Abstract

Security-Enhanced Linux provides an implementation of mandatory  
access control but
is limited by the available tools for policy configuration and  
analysis. This work ex-
amines policy management and demonstrates a method to translate the  
information in
the policy.conf file to XML. The portability of XML and availability  
of existing general
purpose XML tools will allow policy information to be analysed in new  
ways.

Link
http://personal.utulsa.edu/~brandon-pollet/XMLPolicy-TN.pdf


[-- Attachment #2: Type: text/html, Size: 2681 bytes --]

Re: XML Based Policy Configuration for SELinux

[Luke Kenneth Casson Leighton]

On Tue, Jun 21, 2005 at 12:37:16PM -0500, Brandon Pollet wrote:
> Recently there was a discussion about using XML in SELinux policy and  
> so I wanted send out this Master's Report by Tyronne Nash. This paper  
> covers some of the work we have done at the University of Tulsa to  
> convert and extend the SELinux policy language with an XML  
> specification. The abstract and a link to the full document are  
> contained below. Let me know what you think.
> 
> thanks,
> Brandon Pollet
> 
> Abstract
> 
> Security-Enhanced Linux provides an implementation of mandatory  
> access control but
> is limited by the available tools for policy configuration and  
> analysis. This work ex-
> amines policy management and demonstrates a method to translate the  
> information in
> the policy.conf file to XML. 

 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.

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

Re: XML Based Policy Configuration for SELinux

[alexander-barclay]

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

After some conversations with others in the SELinux community, we decided to deemphasize all of our projects being XML policy based. This thesis/project was intended to be the first part of a larger group of projects, and alone is not amazing, but utilizing some of the  xml tools avaliable it opens up some options that did not exist previously. 

I agree that now looking at some of the smaller configuration files is useful, any feature requests you or the mailing list have would be appreciated. Do you like the choice of using TXL? Include meta-data? etc.



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.

Alex Barclay
University of Tulsa
Enterprise Security Research Group



Quoting Luke Kenneth Casson Leighton <lkcl@lkcl.net>:

> On Tue, Jun 21, 2005 at 12:37:16PM -0500, Brandon Pollet
> wrote:
> > Recently there was a discussion about using XML in SELinux
> policy and  
> > so I wanted send out this Master's Report by Tyronne Nash.
> This paper  
> > covers some of the work we have done at the University of
> Tulsa to  
> > convert and extend the SELinux policy language with an XML 
> 
> > specification. The abstract and a link to the full document
> are  
> > contained below. Let me know what you think.
> > 
> > thanks,
> > Brandon Pollet
> > 
> > Abstract
> > 
> > Security-Enhanced Linux provides an implementation of
> mandatory  
> > access control but
> > is limited by the available tools for policy configuration
> and  
> > analysis. This work ex-
> > amines policy management and demonstrates a method to
> translate the  
> > information in
> > the policy.conf file to XML. 
> 
>  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.
> 
> --
> 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.
> 

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

Re: XML Based Policy Configuration for SELinux

[Luke Kenneth Casson Leighton]

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.

Re: XML Based Policy Configuration for SELinux

[Alex Barclay]

On Jun 21, 2005, at 5:20 PM, Luke Kenneth Casson Leighton wrote:

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

I would agree for the most part, and as a result our new projects  
(which will be given to the list for pre-development feedback in the  
near future) are geared to work on top of the existing  layers in  
SELinux. The things that have been on the list from us the past week  
or so were are first salvo for SElinux, the second salvo is being  
worked on, and will be out for feedback soon, and we just are in the  
"what if" stage for round 3.

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

In regards to your wish list, that seems like a relatively reasonable  
thing to accomplish. I like the idea, and will see if what we can do  
about this this next semester. To be honest, it depends on how many   
or if we get new researchers and their abilities.

Once again, thanks for the discussion and anyone feel free to send us  
thoughts, suggestions, improvements etc.

Alex Barclay, Masters Student
Enterprise Security Group
University of Tulsa





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

Re: XML Based Policy Configuration for SELinux

[Joshua Brindle]

Luke Kenneth Casson Leighton wrote:

>On Tue, Jun 21, 2005 at 02:59:42PM -0500, alexander-barclay@utulsa.edu wrote:
>  
>
> <snip>
>
> 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)
>  
>
This isn't true, apol, and probably other tools, read policy.conf for 
doing policy analysis.

> policy.conf is an "intermediary": do not be deceived by it being in a
> readable flat file format!
>
sure but it also contains all the information you need to see how the 
loaded policy will work

><snip>
>
> - 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
>  
>
tunables will be part of the language once the modules are in use and 
therefore will be preserved in the binary module format

><snip>
>  
>
> which are actually quite difficult - if not impossible - to
> "extract" from the policy.conf file, in isolation, with no
> access to the "users" file.
>
>  
>
that is precisely what all the analysis do

> 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.
>  
>
file_contexts are an initial configuration and not necessarilly as 
interesting as the actual filesystem contexts

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

Why? XML's only purpose in life is to transform from a generalized 
format to some other format, mostly for human consumption. Having the 
rules themselves in XML does very little in the way of making the policy 
easier to read (or rather detracts from that) and you'd just have to 
convert it to the existing format anyway. The XML in the reference 
policy is for documentation only, and is used to convert from the inline 
docs to html, text, possibly man pages and so on, it is not meant to be 
read directly.

>   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".
>
>  
>
Thats what the type hierarchy patch we sent a while back is suppose to 
do. So you make an "apache" type and then children types that are 
constrained by the permissions of apache. This is a compiler and 
infrastructure enforced constraint that is very useful for doing things 
such as delegating access to parts of the policy and ensuring it doesn't 
exceed the original permissions granted.

> 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.
>  
>
How is it useful exactly? what would the XML be used for? converting 
something to XML for the sake of doing so doesn't really accomplish 
anything.

Joshua Brindle
Tresys Technology

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

Re: XML Based Policy Configuration for SELinux

[Luke Kenneth Casson Leighton]

[joshua thank you for the corrections]

Wish List item 3)

that the tools that do the converting to/from XML be
written in python!!!


On Tue, Jun 21, 2005 at 07:45:29PM -0400, Joshua Brindle wrote:

> >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.
> > 
> >
> How is it useful exactly? what would the XML be used for? 

> converting 
> something to XML for the sake of doing so doesn't really accomplish 
> anything.
 
 i get the impression that you like XML as little as i did when the
 buzz-word first came out.

 i agree with you that XML is not particularly useful for
 being read by humans (although it can be which is useful
 for debugging, if the tool/library that generated the XML
 file includes appropriate white space, which they frequently
 don't *sigh*...)

 it _is_, however, useful for being read by computer programs.

 XML is the sort of thing that allows people with very little
 understanding of e.g. selinux to write, write, using simple
 libraries, their Own Glorious parsing analysis and communication
 tools.

 my guess is that once all the hard work is done of specifying
 an XML file format and writing (hopefully in python *hope*,
 *hope*, hint, hint) a parsing/converter tool to convert
 `cd /etc/selinux/src; make distclean; find .` in and out of
 XML file format, that:

 - writing a python program that took an XML file and generated an
   HTML report would take about... *shrug* - two to three hours

   [i did a similar thing for converting a fwbuilder's XML file
    into an HTML report because fwbuilder is missing a
    print option.  so it would take _me_ under 90 mins
    to convert my fw_report.py program to understand an
    SE-Linux-Policy-DTD-compliant XML file]

 - writing a python tcl/tk program that took an XML selinux file
   as input and output that could be used to write SElinux policy
   would take... mmm... *finger-in-air* ... ten days?

 - you could write a program similar to fwbuilder that understood
   SE/Linux policy [instead of firewall rules].

   fwbuilder's file format is in XML.

   adapting fwbuilder as the basis for a GUI-based selinux policy
   writing tool would take... *finger-in-air* ... four weeks?

   (fwbuilder is written in c++).

 

 the same cannot be said for programs having to understand
 the /etc/selinux/src/* policy files directly.

 the above timescales all would need, individually, to have
 the cost of writing a read-write parser to them in each of
 the python and c++ languages, respectively.
 
 and it would _need_ to be a library [not a file format].

 you wanna write such a library?  fine!!  [i don't!!]

 bottom line: i strongly suggest using the right kind of
 words that will encourage the people at this university to
 do this work!!!

 l.


-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

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

Re: XML Based Policy Configuration for SELinux

[Joshua Brindle]

Luke Kenneth Casson Leighton wrote:

>[joshua thank you for the corrections]
>
>Wish List item 3)
>
>that the tools that do the converting to/from XML be
>written in python!!!
>  
>
The doctool to generate module.conf, tunables.conf and the html docs for 
the reference policy is in python :)

> <snip>
>
> 
> i get the impression that you like XML as little as i did when the
> buzz-word first came out.
>
>  
>
No, I think XML is very useful for the right tasks

> i agree with you that XML is not particularly useful for
> being read by humans (although it can be which is useful
> for debugging, if the tool/library that generated the XML
> file includes appropriate white space, which they frequently
> don't *sigh*...)
>
> it _is_, however, useful for being read by computer programs.
>
> XML is the sort of thing that allows people with very little
> understanding of e.g. selinux to write, write, using simple
> libraries, their Own Glorious parsing analysis and communication
> tools.
>
>  
>
I'm not sure what this means. How does XML help people that don't 
understand selinux do anything?
Changing the language to XML might add parsers but tools won't magically 
appear. Further, there are plenty of tools that parse the current 
format, there is little reason to move to an XML based policy language 
when totally functional parsers already exist to do anything you need.

> my guess is that once all the hard work is done of specifying
> an XML file format and writing (hopefully in python *hope*,
> *hope*, hint, hint) a parsing/converter tool to convert
> `cd /etc/selinux/src; make distclean; find .` in and out of
> XML file format, that:
>
>  
>
the modules might be in XML but there will be lots of m4 that will still 
have to be processed before any XML parser could use the output..

> - writing a python program that took an XML file and generated an
>   HTML report would take about... *shrug* - two to three hours
>
>   [i did a similar thing for converting a fwbuilder's XML file
>    into an HTML report because fwbuilder is missing a
>    print option.  so it would take _me_ under 90 mins
>    to convert my fw_report.py program to understand an
>    SE-Linux-Policy-DTD-compliant XML file]
>
> - writing a python tcl/tk program that took an XML selinux file
>   as input and output that could be used to write SElinux policy
>   would take... mmm... *finger-in-air* ... ten days?
>
> - you could write a program similar to fwbuilder that understood
>   SE/Linux policy [instead of firewall rules].
>
>   fwbuilder's file format is in XML.
>
>  
>
I'm not sure it's fair to compare a policy language which is often in 
implementations with 300k+ rules with a firewall app that probably 
rarely has 1000. I can't ever imagine a time when selinux policy is 
written directly in expanded format (no macros or templates of some 
sort, whether it's m4 or not) and using XML on the unexpanded format is 
again, not possible

>   adapting fwbuilder as the basis for a GUI-based selinux policy
>   writing tool would take... *finger-in-air* ... four weeks?
>
>   (fwbuilder is written in c++).
>
> 
>
> the same cannot be said for programs having to understand
> the /etc/selinux/src/* policy files directly.
>
>  
>
Parsers exist for this

> the above timescales all would need, individually, to have
> the cost of writing a read-write parser to them in each of
> the python and c++ languages, respectively.
> 
> and it would _need_ to be a library [not a file format].
>
>  
>
we have some: libapol, libsepol and an upcoming API for modifying the 
policy through an infrastructure like the policy modules or the policy 
server

> you wanna write such a library?  fine!!  [i don't!!]
>
>  
>
we did :)

> bottom line: i strongly suggest using the right kind of
> words that will encourage the people at this university to
> do this work!!!
>  
>
I think you misunderstood. Clearly I want the university guys to do work 
that helps SELinux, I just question how this specific work could.


Joshua Brindle

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

Re: XML Based Policy Configuration for SELinux

[Luke Kenneth Casson Leighton]

On Tue, Jun 21, 2005 at 11:46:30PM -0400, Joshua Brindle wrote:

> >Wish List item 3)
> >
> >that the tools that do the converting to/from XML be
> >written in python!!!
> > 
> >
> The doctool to generate module.conf, tunables.conf and the html docs for 
> the reference policy is in python :)
 
 wheeeee :)

> >XML is the sort of thing that allows people with very little
> >understanding of e.g. selinux to write, write, using simple
> >libraries, their Own Glorious parsing analysis and communication
> >tools.
> >
> > 
> >
> I'm not sure what this means. How does XML help people that don't 
> understand selinux do anything?

 to illustrate: i did not need to understand anything about the ordering
 of the application of incoming NAT and incoming firewall rules which
 are different from the ordering of the application of outgoing NAT and
 outgoing firewall rules in order to write my fw_builder.py program,
 which simply takes the output of fwbuilder (an XML file) and spews
 forth a prettified HTML version of the firewall policy.
 
 more later.

 l.

 

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

Re: XML Based Policy Configuration for SELinux

[Joshua Brindle]

Luke Kenneth Casson Leighton wrote:

>On Tue, Jun 21, 2005 at 11:46:30PM -0400, Joshua Brindle wrote:
>
>  
>
>>>Wish List item 3)
>>>
>>>that the tools that do the converting to/from XML be
>>>written in python!!!
>>>
>>>
>>>      
>>>
>>The doctool to generate module.conf, tunables.conf and the html docs for 
>>the reference policy is in python :)
>>    
>>
> 
> wheeeee :)
>
>  
>
glad you approve :)

>>>XML is the sort of thing that allows people with very little
>>>understanding of e.g. selinux to write, write, using simple
>>>libraries, their Own Glorious parsing analysis and communication
>>>tools.
>>>
>>>
>>>
>>>      
>>>
>>I'm not sure what this means. How does XML help people that don't 
>>understand selinux do anything?
>>    
>>
>
> to illustrate: i did not need to understand anything about the ordering
> of the application of incoming NAT and incoming firewall rules which
> are different from the ordering of the application of outgoing NAT and
> outgoing firewall rules in order to write my fw_builder.py program,
> which simply takes the output of fwbuilder (an XML file) and spews
> forth a prettified HTML version of the firewall policy.
> 
> more later.
>  
>
This isn't right. The XML part of this equation is just the route those 
authors chose to get a free parser, the tool would work exactly the same 
from the user prespective if the file format was binary using 
alternating happy faces and frowny faces. It's just the tool and the 
developers that have to deal with the backend storage format. It might 
be nice in the firewall case to transform the config file into html but 
I can't think of a way this is helpful for SELinux policy.

The bottom line is that the tools would be great but the XML has nothing 
to do with that.

Joshua

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

Re: XML Based Policy Configuration for SELinux

[Luke Kenneth Casson Leighton]

On Wed, Jun 22, 2005 at 07:22:43AM -0400, Joshua Brindle wrote:
> Luke Kenneth Casson Leighton wrote:
 
> The bottom line is that the tools would be great 

 i agree with that.

> but the XML has nothing 
> to do with that.

 then we will have to agree to disagree on that point, because
 there are far more XML parsing libraries in virtually every known
 useable language under the sun.
 
 here are the options, as i see them:

 * a tool, written in i-don't-really-care-what-language-but-i-like-python,
   which takes `find /etc/selinux/src/*` and turns it into formally-defined,
   well-structured XML format which has a formal DTD representing users,
   *.te, *.fc, macros, etc.
   
   then utilities and programs written which understand the DTD
   and therefore can "manipulate" selinux policy for any purpose
   can be written in any programming language which has an XML library.


 * a library, written in [probably] c and then wrapped with swig,
   which understands and provides access to the contents of
   /etc/selinux/*

   then, utilities and programs which "manipulate" selinux policy can
   conveniently be written in c and with some awkwardness [due to swig]
   written in any other programming language.

 some questions for you:

	 which of these two options is less of a maintenance headache?
 
 and
 
	 which of these two options provides the most flexibility?
 
 and

 	which of these two options would be most acceptable to
	non-expert selinux admins and developers for writing their
	own home-grown tools?

 most people look at the /etc/selinux/src and go "yukk".


 oh - btw - the idea about "function definitions" in the m4 language?
 GREAT idea - i believe it would make the "formal definition" in XML
 format that much easier.

 l.


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

Re: XML Based Policy Configuration for SELinux

[Ivan Gyurdiev]

>  * a library, written in [probably] c and then wrapped with swig,
>    which understands and provides access to the contents of
>    /etc/selinux/*
> 
>    then, utilities and programs which "manipulate" selinux policy can
>    conveniently be written in c and with some awkwardness [due to swig]
>    written in any other programming language.

I'd like to note that I'm currently working on a small piece of 
that - placing the necessary code to work with file_contexts
and net_contexts, and local.users from the libsepol library.
Basically, I need to integrate useradd utilities with
the selinux code, so roles and per user contexts are
added/deleted/modified automatically.

It's not what you're describing, but at least it provides
some parsing code that generates a data structure (record)
that you can later pass to handlers and accomplish various
things more easily. I have written functions to iterate
a file of a single kind of record (such as the file_contexts 
file) and execute arbitrary handler that's individually
passed each record. I can also modify records with
a handler, delete records, and re-write
the file (preserving comments). Current status is debugging, 
and adding more validation/rollback features to the 
few handlers I've written.

It's not what you're describing, but it mostly does what
we need for useradd integration, and can be extended 
with more features later. The point is, it's not so
hard to get something up and running in C, as you
describe it.


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

Re: XML Based Policy Configuration for SELinux

[Junji Kanemaru]

Hi guys,

I'm impressed xml based policy discussion here.
Is there XML based policy project home page that you are working on?
The idea, having policy in XML is similar to what we have been discussing
here in Japan.

What we are thinking is:

1) Policy maintainer creates policy source
2) Convert the source to XML and put them into XMLDB using tool
3) Users(regular admins I'd say) pickup and download policy fragments
    what exactly they need from XMLDB with XML query
4) Then convert the XML source to regular policy source and compile
    and apply.

Some people would think it is wasteful, why not having raw policy
source in DB. But I think XML makes things easier for adding, modifing
and deleting some part of policy.

IMO, currently it is very difficult to find dependencies in the policy source
but if we have it in XML it is easier.

-- Junji
Linuon Inc.
Tokyo Japan


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