idea: customizable_types.local

[Dominick Grift]

On Wed, 2009-11-11 at 14:06 -0500, Daniel J Walsh wrote:
> On 11/11/2009 12:21 PM, Dominick Grift wrote:
> > On Wed, 2009-11-11 at 16:04 +0000, Moray Henderson (ICT) wrote:
> >> Dominick wrote:
> >> <snip>
> >>>> Thats cool, but what if you update your selinux policy? will
> >>>> customizable_types be overwritten? Maybe it would be good to have a
> >>>> customizable_types.local so that you can add your customizable types
> >>>> there and not have to worry about policy updates or restorecond -u.
> >>
> >> I've checked selinux-policy-targeted-2.4.6-255.el5_4.1, and customizable_types is marked as a config file.  It would be overwritten, but you would get an rpmsave file so that you could reapply custom changes.  Some of the other files in the contexts dir are config(noreplace); maybe making this one noreplace too would be the better solution.
> >>
> >>
> >> <snip>
> >>> That is just the issue. Sometimes it is not feasible or sometimes its not
> >>> possible to add a context specification.
> >>> For example the name of you backup file is changable and also its location.
> >>> You might call it backup.tgz and store it in ~ or call it bla.tgz and
> >>> store it in ~/Documents (just an example.
> >>
> >> Would
> >>
> >> /home/.*/.+\.tgz  --  mybackup_script_home_t
> > 
> > That would be too broad. Not every *.tgz in $home is also actually a
> > backup :)
> > 
> >> do it?  Although I would have my backup scripts use more standardised names and locations anyway.
> >>
> > 
> > The backup is just an example.
> > 
> >> <snip>
> >>> Another example is kismet, it will store logs where ever you start it. So
> >>> if you start it in ~ it will (try to) put the logs there. So lets say you
> >>> allow kistmet to manage files with kismet_home_t in user_home_t, Run
> >>> kismet and it starts logging to ~, along comes restorecond -u and resets
> >>> the contexts of the logs to user_home_t (to which kismet incidentally
> >>> cannot write/append)
> >>
> >> Not familiar with kismet.  Creating logs wherever it is started sounds like bad behaviour quite apart from any SELinux implications, especially if there really is no way to distinguish a kismet log from any other random *.log file.  Maybe a wrapper script to ensure it starts in a consistent location?  You're right though, that must be the sort of thing customizable_types was designed for.
> >>
> >> <snip>
> >>> What if i have a policy that allows some domain to manage a file in
> >>> user_home_t with its own type (example blah_home_t). I start the confined
> >>> domain and notice that any file created by it has user_home_t (instead of
> >>> blah_home_t), whilst i implicitly defined a type transition.
> >>>
> >>> I would expect the file to have the type that i defined and not
> >>> user_home_t. That is confusing as well.
> >>
> >> So far when I have been creating policy I have been able to identify unique locations or filename patterns for the files whose types I need to manage.  I put those into the .fc file when writing my policy and therefore the files do get the types I define.
> >>
> >> Your way is more flexible than mine, but it would come at the cost of adding another bit of complexity to SELinux - and when it comes to SELinux and complexity, "adding more" is not the first thing I think of :-)
> >>
> > complexity or flexibility? (i guess a little bit of both)
> >>
> >> Moray.
> >> "To err is human.  To purr, feline"
> >>
> >>
> >>
> >> --
> >> fedora-selinux-list mailing list
> >> fedora-selinux-list at redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> > 
> > 
> > --
> > fedora-selinux-list mailing list
> > fedora-selinux-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> > 
> > 
> customizable_types predates the semange fcontext stuff.  The main idea was admins were throwing http_sys_content_t labels around with chcon and restorecon/setfiles was removing the labels.
> 
> With semanage fcontext, customizable_types became much less important.  
> 
> I would recommend setting the labeling for the homedir or turning off restorecond from the autostart.
> Or adding entries to customizable_types.  I think we can change the designation of customizable_types in the spec file to change rpm to not overwrite changes, since I don't intend to add more customizable types to base policy.

By the way, if i remember my argument for putting httpd_user* types in
customizable_types correct, then i think we can by now remove them again
from customizable_types as currently you can add home dir context
specifications with semanage.

I think my argument at the time was that admins could not add custom
locations with semanage fcontext in /home/*/. This works fine now.

To be honest, and i hope i am wrong, i think that you may not take into
account the behavior of user apps and the prospect of more and more
confined user apps in the future.

By excluding the customized_types file from being updated i think the
issue may be solved. However i am not sure whether the policy needs to
be rebuild after manual modification.