Change request: SELinux tweaks.

[Mike McGrath]

On Mon, 1 Dec 2008, Luke Macken wrote:

> On Wed, Nov 26, 2008 at 12:55:28PM +0100, Nils Philippsen wrote:
> > On Fri, 2008-11-21 at 16:49 -0500, Luke Macken wrote:
> > > On Fri, Nov 21, 2008 at 01:12:13PM -0800, Toshio Kuratomi wrote:
> > > > Luke Macken wrote:
> > > > > On Fri, Nov 21, 2008 at 02:17:53PM -0600, Mike McGrath wrote:
> > > > >> On Fri, 21 Nov 2008, Luke Macken wrote:
> > > > >>
> > > > >>> Attached are some patches that will fix many AVC's that are currently
> > > > >>> happening within our infrastructure.
> > > > >>>
> > > > >>> Patch 0010-Fix-our-semanage_fcontext-function-to-work-on-symlin.patch
> > > > >>> /should/ fix the problem introduced in
> > > > >>> 41acfbc83c80d12d915a0d6087e841aba2c7e78c that caused restorecon to flip
> > > > >>> out when trying to apply context to a symlink.
> > > > >>>
> > > > >>> The rest should all be fairly straight-forward fixes that involve
> > > > >>> flipping booleans, setting context, and creating custom policy modules.
> > > > >>> Apologies for the binary blobs in the diffs :)
> > > > >>>
> > > > >> What is the impact of actually implementing these changes?  Also whats the
> > > > >> risk if stuff goes horribly wrong?
> > > > >
> > > > > These changes will greatly decrease the amount of SELinux AVCs
> > > > > generated, and in the case of bastion will also decrease the number of
> > > > > prelude alerts being sent to our prelude-manager.  Since we're
> > > > > in permissive mode, all AVCs are essentially harmless, but we need to
> > > > > fix them to not only move forward with our SELinux deployment, but also
> > > > > for the IDS deployment as well (we currently have too many AVCs for our
> > > > > audit-driven prelude IDS to be useful).
> > > > >
> > > > > The only thing I can think of that could go "horribly wrong" is if patch
> > > > > 0010 does not fix the symlink issue, and it would trigger a 'restorecon
> > > > > -R /', which would only cause a little bit of disk churn.  When these
> > > > > are applied, I will manually run puppet on our hosted machine to ensure
> > > > > that the symlink issue is properly fixed.
> > > > >
> > > > How does patch 0010 fix the problem?  It looks like trying to use this
> > > > on /git will still result in restorecon -R / being run.
> > >
> > > Good catch.  So, for symlinks such as /cvs, defining them like this
> > > should do the trick:
> > >
> > >     --- a/manifests/servergroups/cvs.pp
> > >     +++ b/manifests/servergroups/cvs.pp
> > >     @@ -28,7 +28,7 @@ class cvs {
> > >               bool => 'on'
> > >          }
> > >
> > >     -    semanage_fcontext { '/cvs':
> > >     +    semanage_fcontext { '/cvs(/.*)?':
> > >              type => 'httpd_sys_content_t'
> > >          }
> >
> > Sorry to jump in uninformed, but will this actually catch files
> > beneath /cvs (if /cvs is a symlink)? IMO, the "real" path needs to be
> > specified here (e.g. /srv/cvs/... if /cvs pointed to /srv/cvs).
> >
> > Or do restorecon & co. actually follow symlinks (and thus would
> > potentially treat files differently depending on whether they were
> > reached by the canonical or a symlinked path)?
>
> The way we created the semanage_fcontext is that so that it will always
> run `restore -R` on the dirname of the path, with some sed "magic",
> so it should ideally follow everything below the symlink.
>
>     define semanage_fcontext($type) {
>         exec { "/usr/sbin/semanage fcontext -a -t $type '$name'; /sbin/restorecon -R `/usr/bin/dirname '$name/' | /bin/sed 's/(.*//'`":
>             unless => "/usr/sbin/matchpathcon `/usr/bin/dirname '$name' | /bin/sed 's/(//'` | grep -qe $type",
>             cwd => '/',
>         }
>     }
>
> Yes, it's a nasty hack, but it works for now until puppet can handle this stuff
> better (the latest version may actually be able to, I'm not quite sure)
>

Side note about the new puppet version, I was going to do that this week
but I'll be in phoenix starting on Thursday until Monday (maybe later
depending on how things go).  I don't want to change puppet and have it do
horrible things while I'm actually on site.

Having said that...  If someone else wants to do the upgrade
(sysadmin-main) and take responsibility for making sure it went ok and
that things are working have at it (let us know though).  From what I
understand old puppetmaster and new puppet don't totally work right so
you'd have to upgrade the puppet master then upgrade puppet on each host.

Its been my experience that this can be a manual process but we do have
func in most places now so this should be helpful.  If no one does it I'll
get it mid-december at some point.

	-Mike