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)?
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
