CentOS - Sep 2013 - Looking for input SELinux/Other & post-commit hooks.

Hi All,

I'm looking for input as to how I may restrict some post commit hooks by way
of SELinux or some other mechanism.  Here's a description of the problem
that I need to solve.

I have a source code server that support SVN and soon git.  The server has no
actual users on it and we use CAS with Apache basic authentication to
authenticate and authorize users access to the repository.  This server mounts
two NFS shares, one for the mirror environment for HTTP based installations and
another NFS share for our Puppet environment.  There is a corresponding source
repository and NFS share for each "user" of the system as well as
corresponding NFS shares for mirror and puppet.  All the content is owned by the
user Apache.

Each time a user commits scripts are run to check this code out of the source
code server and into a respective

/mirror/<repotype>/<reponame>
/puppet/<repotype>/<reponame>

But there are other bits of code that the end user would like to also be able to
run, such as generating group information based on the content of a file that
was committed manual pruning of some arbitrary data and other things that I
don't want to account for in code.  Essentially allowing them to extend the
system further for their needs.

This means that I need to ensure that a user isn't able to run code like rm
-rf /etc/password or rm -rf /{mirror,puppet}/* which would essentially ruin
everyone's data. What I essentially would like to do is ensure that if
someone were to attempt to run any of the third party code that the permissions
for that run would be within the context of their own areas so that the most
damage they could do is wipe out the content of their
/mirror/<repotype>/<reponame> &
/puppet/<repotype>/<reponame> while not having to setup and destroy
a (potentially) large chroot environment each time the script is run.

-- 
James A. Peltier
Manager, IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone   : 778-782-6573
Fax     : 778-782-3045
E-Mail  : jpeltier at sfu.ca
Website : http://www.sfu.ca/itservices

?A successful person is one who can lay a solid foundation from the bricks
others have thrown at them.? -David Brinkley via Luke Shaw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/25/2013 12:35 PM, James A. Peltier wrote:
> Hi All,
> 
> I'm looking for input as to how I may restrict some post commit hooks
by
> way of SELinux or some other mechanism.  Here's a description of the
> problem that I need to solve.
> 
> I have a source code server that support SVN and soon git.  The server has
> no actual users on it and we use CAS with Apache basic authentication to
> authenticate and authorize users access to the repository.  This server
> mounts two NFS shares, one for the mirror environment for HTTP based
> installations and another NFS share for our Puppet environment.  There is a
> corresponding source repository and NFS share for each "user" of
the system
> as well as corresponding NFS shares for mirror and puppet.  All the content
> is owned by the user Apache.
> 
> Each time a user commits scripts are run to check this code out of the
> source code server and into a respective
> 
> /mirror/<repotype>/<reponame>
/puppet/<repotype>/<reponame>
> 
> But there are other bits of code that the end user would like to also be
> able to run, such as generating group information based on the content of a
> file that was committed manual pruning of some arbitrary data and other
> things that I don't want to account for in code.  Essentially allowing
them
> to extend the system further for their needs.
> 
> This means that I need to ensure that a user isn't able to run code
like rm
> -rf /etc/password or rm -rf /{mirror,puppet}/* which would essentially ruin
> everyone's data. What I essentially would like to do is ensure that if
> someone were to attempt to run any of the third party code that the
> permissions for that run would be within the context of their own areas so
> that the most damage they could do is wipe out the content of their
> /mirror/<repotype>/<reponame> &
/puppet/<repotype>/<reponame> while not
> having to setup and destroy a (potentially) large chroot environment each
> time the script is run.
> 
You can do everything you want EXCEPT, NFS Does not yes support labels.  You
could prevent a user from touch any of the OS files but not from writing to
the nfs shares.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJDIcoACgkQrlYvE4MpobMSNACg4ZT0RnjlQLKEvrKIUy95ZWUO
SWYAn3t5ITDV18XCur7eHCYCti8iOpTh
=UjyT
-----END PGP SIGNATURE-----