[colug-432] Puppet + Subversion + SELinux

[Scott Merrill]

Thanks for the reply, Russ. I appreciate your insight on this.

On Thu, Feb 24, 2011 at 1:37 PM, R P Herrold <herrold at owlriver.com> wrote:
> On Thu, 24 Feb 2011, Scott Merrill wrote:
>
>> for its various files; but I suspect that the SELinux context issue
>> will still arise. Indeed, I did try placing the files in
>> /usr/local/puppet, and setting the context on that directory to
>> httpd_sys_content_t so that the post-commit hook could write to it.
>   *******************
>> While the puppetmaster daemon started, the audit log reported a number
>> of denials:
>>
>> type=AVC msg=audit(1298560236.944:186278): avc:  denied  { search }
>> for  pid=3254 comm="puppetmasterd" name="pki" dev=dm-0 ino=1703985
>> scontext=unconfined_u:system_r:puppetmaster_t:s0
>> tcontext=system_u:object_r:cert_t:s0 tclass=dir
>            ***************************
>
> here the puppetmasterd is looking to read a certificate, and
> the read is blocked because there is not an allow rule in the
> indicated context.  From the puppet mailing list, I know that
> this has caused hard to diagnose issues

Yeah, inclusion of this audit item is a red herring for this specifics
of my original post. The pki stuff it's looking for is in
/var/lib/puppet/ssl, which is not version controlled, and not part of
the problem I'm currently trying to resolve.

I did have to relabel some of the sub-directories under
var/lib/puppet/ in order to quiet the audit log. I'll look through
.bash_history and submit that upstream somewhere...

>> type=AVC msg=audit(1298560237.269:186279): avc:  denied  { getattr }
>> for  pid=3254 comm="puppetmasterd"
>> path="/usr/local/puppet/manifests/site.pp" dev=dm-0 ino=5224
>> scontext=unconfined_u:system_r:puppetmaster_t:s0
>> tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file
>
> again, the .pp script is read-blocked, and so will fail is a
> manner which might be predicted by examining the caller and
> the code not able to be read

So here's where things get interesting to me.

Out of the box, I would expect the puppetmasterd daemon to have the
necessary (SELinux) permissions to read /etc/puppet, since that's
where the files live, by default.

The actual denial is { getattr }. Does that prevent the reading of the
file altogether? That's not entirely clear to me.

> Basically, the process is to run a new application through all
> its options, to cause all code paths to be _attempted_ [and
> initially blocked by SELinux].  With that in hand one
> 'loosens' a bit with a new ruleset, and repeats the process.
> Eventually, one ends up with a complete rule set, but it is an
> iterative process.

Indeed, as I discovered.

> I might note that Steve Smalley, and others involved with
> SELinux at the NSA and Red Hat welcome, and are quite
> responsive to reports of problems through the Red Hat
> bugzilla, and also on their mailing list.  They actively
> solicit and promptle resolve such access issues.

When I'm sure that the situation I'm experiencing is, in fact, worthy
of a bugzilla report I will definitely file one. I don't want to waste
anyone's time on problems of my own doing.

> I note you have used the /usr/local/ point in the file syste,
> which Red Hat has intentionally avoided.  This implies local
> non-package managed content, although this is not a necessary
> constraint.

The on-disk location of the Subversion repository is
/usr/local/svn/puppet. The only access to this directory in this
scenario is via the `svn` command. The entire /usr/local/svn directory
is owned by Apache, and has the appropriate SELinux contexts, per the
comments in the /etc/httpd/conf.d/subversion file:

# To create a new repository "http://localhost/repos/stuff" using
# this configuration, run as root:
#
#   # cd /var/www/svn
#   # svnadmin create stuff
#   # chown -R apache.apache stuff
#   # chcon -R -t httpd_sys_content_t stuff

I don't think the use of /usr/local/ in my discussion has much of
anything to do with the questions I posed at the end of my original
post.

> It may be worth participating in the puppet
> mailing list, and generalizing and upstreaming your code so
> it gets folded into the base distribution [the puppet folks
> are also an active and enthusiastic bunch]

I suspect I will end up subscribing to the mailing list, but sweet
merciful fates there are only so many mailing lists to which I can
subscribe and remain sane. :(

> [Subversion is NOT where the 'cool kids' play these days --
> they have all moved to the 'git' dvcs, and github and
> work-alikes, it seems  ;) ]

Subversion works. It does exactly what we need. I don't need
distributed revision control for this application, and I've yet to
have anyone articulate any situations in which I really do need a
DVCS. If anyone has any such explications, please consider presenting
your arguments in the form of a COLUG presentation!

Cheers,
Scott