On Thu, 30 Nov 2006, Joshua Brindle wrote:
> From: Karl MacMillan [mailto:email@example.com]
> Joshua Brindle wrote:
>>> From: Steve Friedman [mailto:firstname.lastname@example.org]
>>> Call me old-fashioned, but it is nice to be able to send a colleague
>>> / customer / friend a text file that can be edited, diffed, reviewed,
>>> archived, and updated. Policy servers are convenient for one
>>> organization, but sometimes this transfer occurs across organization
>>> boundaries. (Not to mention the delay between this hoped-for tool
>>> and the actual, production-ready deployment schedule...)
>> That's fine, and the bug added is to export the data, but I am dubious
>> about the usefulness of doing so. Policies probably aren't going to be
>> compatible across organization boundaries in a meaninful way, systems
>> and policies are specific to the organization. For example, why would
>> you send the selinux user and linux user to selinux user mappings to
>> another organization?
> You probably wouldn't send user mappings to other
> organizations but booleans, file context, port labeling, etc.
These should be directly dependant on the services being run and the
local configuration, if two organizations are running services in an
identical manner then sure but what about all the unrelated noise?
(exporting all ports when really you are trying to configure policy for
a single service).
Well, I'll give you some hypothetical scenarios for cross-organization
sharing (warning: I am just learning how to use selinux, so these might
- my brother-in-law writes me regarding a problem that he is having, so I
send him my working config (or take it with me on a stick) so he can see
how to configure his machine the same.
- I (as I suspect many others) have an RPM for the various configuration
files on my machine. I can use yum to ensure that the RPM stays current.
So, I would like to distribute my selinux configuration (w/o affecting the
distribution files that will be updated separately) in like manner.
> are all probably fairly portable. Additioanlly, there are
> other uses like backup, automatic system provisioning (e.g.,
> kickstart), or integration with existing administration
> scripts and processes.
Agreed, the interface for this would likely be export all, something
that is not useful for the above scenerio.
> The policy server is a particular kind of solution for a
> particular set of circumstances - no reason to not support
> other solutions. Especially as they are likely - as Steve
> points out - to be viable sooner.
That's fine, how do you suppose the exporting will work? What about
policy modules? Should it be all or nothing or do you choose which parts
you want to export? Clearly backup is a concern here, I didn't say it
wasn't, but backup can be done very simply whereas some sort of
portability of specific pieces is less trivial.
Let me give an example. We use postfix at my organization. It has a
number of configuration files. Using a makefile (an early version of
which was copied from the web), the script (via make) issues the relevant
commands to build the necessary hash files, etc. I would envision a
similar situation here: I would distribute one or more ASCII
configuration files for the local customization along with a makefile that
would determine what commands needed to be issued to build the appropriate
In effect, I was asking for the details of the makefile. After updating
(say) booleans.local, what needs to be executed, etc.