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