post direct-file-modification commands

Joshua Brindle jbrindle at tresys.com
Thu Nov 30 16:19:05 UTC 2006


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

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




More information about the fedora-selinux-list mailing list