Re: Looking for input SELinux/Other & post-commit hooks.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



----- Original Message -----
| -----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.

Ya, that's what I thought too from my research.  It looks like i'm going to have to go with plan B which is to mount the NFS shares for each user repository type and repository name somewhere so that that mount point becomes their root location

mount <mirror location> /mnt/repo_type/user/mirror
mount <puppet location> /mnt/repo_type/user/puppet

and then have the scripts only point of reference be from /mnt/repo_type/user .  This could potentially mitigate the problem in a similar fashion.  Always good to get others ideas though.  Thanks Dan!


-- 
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@xxxxxx
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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos





[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux