post direct-file-modification commands

[Steve Friedman]

On Thu, 30 Nov 2006, Joshua Brindle wrote:

>> From: Karl MacMillan [mailto:kmacmillan at mentalrootkit.com]
>>
>> Joshua Brindle wrote:
>>>> From: Steve Friedman [mailto:steve at adsi-m4.com]
>>
>> <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.