On Thu, 30 Nov 2006, Joshua Brindle wrote:
From: Karl MacMillan [mailto:kmacmillan@xxxxxxxxxxxxxxxxx]
Joshua Brindle wrote:
From: Steve Friedman [mailto:steve@xxxxxxxxxxx]
<snip>
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
be trivial):
- 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
policy.
In effect, I was asking for the details of the makefile. After updating
(say) booleans.local, what needs to be executed, etc.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
