idea: customizable_types.local

[Dominick Grift]

On Wed, Nov 11, 2009 at 12:09:14PM +0000, Moray Henderson (ICT) wrote:
> Dominick Wrote:
> >Now we have restorecond -u running and it can be a pain. especially for
> >people that write their own custom modules.
> >
> >for example i have a backup script that can write anywhere in
> >user_home_t. be it ~ or ~/Downloads.
> >
> >It write the backups with a special type, But restorecond -u resets it
> >to user_home_t even before its finished writing ;)
> >
> >Here comes customizable_types in. This can be used to add the type to it
> >so that restorecond -u doesnt try to reset it.
> >
> >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.
> >
> >What do you think about this idea?
> 
> I remember how I discovered customizable_types in the first place - I wanted files to be reset from their old setting to the new one, and the command that was supposed to do it updated every file except the ones I particularly needed.  I had set everything correctly in file_contexts - then eventually discovered that there was *another* file that told the system to disregard file_contexts for certain file contexts.  I remember thinking - WHY?  Isn't file_contexts supposed to be the place where you configure file contexts?
> 
> Call me old-fashioned, but as a solution for your problem, I would recommend adding file context instructions to your policy so that restorecond sets your backup files to the correct context.

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.

Same goes for example what if you have a irc client confined and it has dcc enable and you download a file to a random location in $home?

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)

> 
> Adding a new customizable file may sound like a neat solution, but in practice it would mean that someone trying to debug "Why doesn't this file have the right context?" now has to know about three different places that the problem might be coming from.
> 
> By the way, I also agree with Matthew Ife's thread from last month about the need for good, practical documentation on how to use SELinux in real system administration rather than conceptual theory.  It's especially important for those who learned the theory under an older version, but need to do things with the new.  I had such a struggle with customizable_types because it wasn't there in RHEL 4.
> 
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20091111/6dfb4ffa/attachment.sig>