Change request: SELinux tweaks.

[Nils Philippsen]

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 at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011