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)
luke
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
