RE: post direct-file-modification commands

[Joshua Brindle]

>  From: Karl MacMillan [mailto:[e-mail]] 
>  
>  Joshua Brindle wrote:
>  >> From: Steve Friedman [mailto:[e-mail]]
>  
>  <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.

post direct-file-modification commands

[Steve Friedman]

On Thu, 30 Nov 2006, Joshua Brindle wrote:

> > From: Karl MacMillan [mailto:[e-mail]]
> >
> > Joshua Brindle wrote:
> >>> From: Steve Friedman [mailto:[e-mail]]
> >
> > <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.

post direct-file-modification commands

[Stephen Smalley]

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

-- 
Stephen Smalley
National Security Agency

post direct-file-modification commands

[Steve Friedman]

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.

post direct-file-modification commands

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency