From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
Joshua Brindle wrote:
From: Steve Friedman [mailto:steve@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.
On Thu, 30 Nov 2006, Joshua Brindle wrote:
From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
Joshua Brindle wrote:
From: Steve Friedman [mailto:steve@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.
On Thu, 2006-11-30 at 14:05 -0500, Steve Friedman wrote:
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.
Yes, at present, it would be a matter of copying the new booleans.local into place and running semodule -B on the target machine. Going forward, we need utilities that can export/dump and import the data without requiring manual copying of the raw files. In the booleans case, that just means an option to getsebool to dump local booleans in a format easily consumed by setsebool (or some new option to setsebool); this requires finally migrating getsebool over to using libsemanage rather than directly reading the kernel state via selinuxfs (or at least supporting such an option as well).
On Thu, 30 Nov 2006, Stephen Smalley wrote:
On Thu, 2006-11-30 at 14:05 -0500, Steve Friedman wrote:
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.
Yes, at present, it would be a matter of copying the new booleans.local into place and running semodule -B on the target machine. Going forward, we need utilities that can export/dump and import the data without requiring manual copying of the raw files. In the booleans case, that just means an option to getsebool to dump local booleans in a format easily consumed by setsebool (or some new option to setsebool); this requires finally migrating getsebool over to using libsemanage rather than directly reading the kernel state via selinuxfs (or at least supporting such an option as well).
Great. One last question, if I may: are there any other ".local" files besides booleans.local and file_contexts.local? This, plus Dan Walsh's blog post (http://danwalsh.livejournal.com/8637.html, for the archives), and I think that I am set.
On Thu, 2006-11-30 at 14:32 -0500, Steve Friedman wrote:
On Thu, 30 Nov 2006, Stephen Smalley wrote:
Yes, at present, it would be a matter of copying the new booleans.local into place and running semodule -B on the target machine. Going forward, we need utilities that can export/dump and import the data without requiring manual copying of the raw files. In the booleans case, that just means an option to getsebool to dump local booleans in a format easily consumed by setsebool (or some new option to setsebool); this requires finally migrating getsebool over to using libsemanage rather than directly reading the kernel state via selinuxfs (or at least supporting such an option as well).
Great. One last question, if I may: are there any other ".local" files besides booleans.local and file_contexts.local? This, plus Dan Walsh's blog post (http://danwalsh.livejournal.com/8637.html, for the archives), and I think that I am set.
There can be, if local definitions are created via semanage by the admin, e.g. ports.local - local labeling of TCP or UDP ports interfaces.local - local labeling of network interfaces nodes.local - local labeling of hosts based on (netmask,address) users.local - local additions of SELinux users seusers - map Linux users to SELinux users
Also, there can be local modules created by the admin, which could be named anything (*.pp) under the modules subdirectory; the names are just the module names. So local.pp would be common for people using audit2allow -M local as per the Fedora SELinux FAQ, but people may also be defining any number of more precisely named local modules to e.g. fix up issues they encounter with particular programs.
Safest thing to do is to just rsync the entire policy tree and semodule -B it.
selinux@lists.fedoraproject.org
-
Joshua Brindle -
Stephen Smalley -
Steve Friedman