what's to stop a developer from nuking the repository?
xy...@hotpop.com
> "Rhodes, Phillip C." <Phillip...@alcoa.com> writes:
> >I am nervous that all my cvs archives are owned by a group that all of
> >our developers are a member of.
> >That is, any developer with a unix account (all of them) can nuke the
> >archives.
> >
> >Besides backups.... any thoughts on this? Sorry, I am new to cvs...
>
> I use cvs over ssh and the machine is completely locked down. The only
> access other than via cvs+ssh is a restricted shell login which does not
> include access to the rm command and several other potentially dangerous
> commands). The restricted shell also places you in a chroot prison. Seems
> to work.
>
> Regards,
>
> Andrew Marlow
-- snip sig --
I have this problem also. It's already happened, and I had to restore with
backups. I need to restrict the /cvs directory so the only access to it is
via CVS, perhaps not even read access.
The problem is that the cvs directory is on the same machine as all the other
server stuff including user's server home directories. Thus, a user can
access the server via a simple 'ssh', then do 'cd /cvs' and have free rein
due to the permissions set below.
1. How do you enforce a restricted shell with a chroot prison? A hacked
version of ssh?
2. How do I muck with the permissions so that developers can't even read, much
less write to the cvs directory, but not damage regular cvs access?
That is, the system-wide passwd file has a user named "cvsaccess" ("not his
real name" :-)
Then, /etc/group has a group named 'cvs' with cvsaccess as well as all other
users that need access to CVS attached to that group.
'cvsaccess' is also listed in the CVSROOT/writers file.
All objects in the /cvs directory are owned by cvsaccess/cvs with all files
having 444 permissions, the directories having 775 permissions. This is a
mess. Since the same user that accesses the main server via ssh has write
permissions due to membership in the 'cvs' group, this allows nuking of the
repository files. How do I fix this?
Also, would it help if I enforced a provision that all users access cvs
using :ext: only via ssh? How would this work with WinCVS users?
If I need to open up another thread on this, please advise. I believe I am
on-topic here, just expanding the parent topic a bit.
Mark D. Baushke
Hash: SHA1
xy...@hotpop.com writes:
> The problem is that the cvs directory is on the same machine as all
> the other server stuff including user's server home directories.
What you describe is a non-optimal setup. Do try to use a dedicated
machine which does not allow general purpose logins to it.
If possible,
- Use a dedicated machine for your cvs server.
- Allow access via ssh only.
- Provide only stub home directories with a .ssh/authorized_keys
file that gives them their public key and restrists the command
they are able to run to the pathname to the 'cvs' command only.
If a special-purpose machine with a minimal environment for users is not
possible, then you may need to take a bit more care about how cvs is
being used.
I have known others to make the cvs executable be set-gid to a 'cvs'
group and for all directories to be owned by a user 'cvs' and group
'cvs' and have 'u=rwx,g=rwxs,o=' (2770) permissions for all directories.
This does not get around the problem that files committed or new
directories added will be owned by the user who made the change, so
those files and directories may need a periodic cron job to change
ownership in the tree of directories and ,v files. However, it may be
mitigated somewhat by the user not being able to 'see' the files under
the repository hierarchy as they are not in the group 'cvs' which only
cvs is able to see. The downside is that you need to be very careful
with taint checks for the verifymsg/commitinfo/loginfo/taginfo scripts.
> Thus, a user can access the server via a simple 'ssh', then do 'cd
> /cvs' and have free rein due to the permissions set below.
>
> 1. How do you enforce a restricted shell with a chroot prison? A hacked
> version of ssh?
While possible, I don't think a chroot prison is necessary and a
standard version of ssh should work. However, if others are already
using this method, perhaps they can be more forthcoming in its
description...
> 2. How do I muck with the permissions so that developers can't even
> read, much less write to the cvs directory, but not damage regular cvs
> access?
As the user will likely 'own' any files that have just been operated on
via a commit or tag operation, unless you have some sort of hack that
changes the ownership of files as a part of the log_accum step, it seems
unlikely that this will do you much good at all. However, if the
top-level directories that own your repository are only able to be
penetrated by a cvs executable due to its set-gid nature, that may give
you some minor protection (I still believe a dedicated machine is a
better solution).
> That is, the system-wide passwd file has a user named "cvsaccess"
> ("not his real name" :-)
Are you talking about an :ext: user or a :pserver: user?
> Then, /etc/group has a group named 'cvs' with cvsaccess as well as all other
> users that need access to CVS attached to that group.
>
> 'cvsaccess' is also listed in the CVSROOT/writers file.
The writers files is intended to be a :pserver: feature... let me be
clear, I know that many people use :pserver:.
Note: I do not consider the :pserver: feature to be useful for anything
other than anonymous read-only access to a mirror of the master
repository. It was and is a fairly insecure hack that I would rather see
removed from cvs. So, I am probably the wrong person to ask about how to
use it to allow writers...
> All objects in the /cvs directory are owned by cvsaccess/cvs with all files
> having 444 permissions, the directories having 775 permissions. This is a
> mess. Since the same user that accesses the main server via ssh has write
> permissions due to membership in the 'cvs' group, this allows nuking of the
> repository files. How do I fix this?
One way is to ensure that the users are only given access to the 'cvs'
command via SSH on login.
> Also, would it help if I enforced a provision that all users access cvs
> using :ext: only via ssh? How would this work with WinCVS users?
Yes. If only ssh access may be granted to the machine, it is possible to
use the command= feature of the OpenSSH .ssh/authorized_keys file to
restrict the command the user is able to run to that of 'cvs server'
which is desirable to limit the ways in which the user may fiddle with
files in the repository.
Both cvs.exe and TortoiseCVS users on windows boxes seem to have been
able to use PuTTY and Pageant (PuTTY's ssh agent) to access cvs servers
using :ext: over the SSHv2 protocol.
Enjoy!
-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFAQgxO3x41pRYZE/gRAudSAJ4oOh4d8dQ1MrhqeQ84b4i/BX9hDACdFDZM
wZ6DGJyLSTpefR9y4RqF0mM=
=hibW
-----END PGP SIGNATURE-----
xy...@hotpop.com
Thanks for your cogent and lucid explanation. You cleared up a lot for me.
Please see in-line comments and questions.
On Sunday 29 February 2004 5:59 pm, Mark D. Baushke wrote:
> xy...@hotpop.com writes:
> > The problem is that the cvs directory is on the same machine as all
> > the other server stuff including user's server home directories.
>
> What you describe is a non-optimal setup. Do try to use a dedicated
> machine which does not allow general purpose logins to it.
>
> If possible,
>
> - Use a dedicated machine for your cvs server.
> - Allow access via ssh only.
> - Provide only stub home directories with a .ssh/authorized_keys
> file that gives them their public key and restrists the command
> they are able to run to the pathname to the 'cvs' command only.
>
> If a special-purpose machine with a minimal environment for users is not
> possible, then you may need to take a bit more care about how cvs is
> being used.
Unfortunately, the reality of my environment is such that I must have
everything on one machine. I do not control the server farm.
>
> I have known others to make the cvs executable be set-gid to a 'cvs'
> group and for all directories to be owned by a user 'cvs' and group
> 'cvs' and have 'u=rwx,g=rwxs,o=' (2770) permissions for all directories.
> This does not get around the problem that files committed or new
> directories added will be owned by the user who made the change, so
> those files and directories may need a periodic cron job to change
> ownership in the tree of directories and ,v files. However, it may be
> mitigated somewhat by the user not being able to 'see' the files under
> the repository hierarchy as they are not in the group 'cvs' which only
> cvs is able to see. The downside is that you need to be very careful
> with taint checks for the verifymsg/commitinfo/loginfo/taginfo scripts.
So, what you are saying here is that if the cvs executable is set-gid to a
group that do NOT have the users in it, those users can still commit,
checkout, etc, but will not be able to see the directory hierarchy aside from
the cvs root?
I don't understand what you mean by 'taint checks' and how they apply here.
Do you have any sort of URL reference so I can RTFM?
>
> > Thus, a user can access the server via a simple 'ssh', then do 'cd
> > /cvs' and have free rein due to the permissions set below.
> >
> > 1. How do you enforce a restricted shell with a chroot prison? A hacked
> > version of ssh?
>
> While possible, I don't think a chroot prison is necessary and a
> standard version of ssh should work. However, if others are already
> using this method, perhaps they can be more forthcoming in its
> description...
>
> > 2. How do I muck with the permissions so that developers can't even
> > read, much less write to the cvs directory, but not damage regular cvs
> > access?
>
> As the user will likely 'own' any files that have just been operated on
> via a commit or tag operation, unless you have some sort of hack that
> changes the ownership of files as a part of the log_accum step, it seems
> unlikely that this will do you much good at all. However, if the
> top-level directories that own your repository are only able to be
> penetrated by a cvs executable due to its set-gid nature, that may give
> you some minor protection (I still believe a dedicated machine is a
> better solution).
>
> > That is, the system-wide passwd file has a user named "cvsaccess"
> > ("not his real name" :-)
>
> Are you talking about an :ext: user or a :pserver: user?
:pserver: definitely.
>
> > Then, /etc/group has a group named 'cvs' with cvsaccess as well as all
> > other users that need access to CVS attached to that group.
> >
> > 'cvsaccess' is also listed in the CVSROOT/writers file.
>
> The writers files is intended to be a :pserver: feature... let me be
> clear, I know that many people use :pserver:.
>
> Note: I do not consider the :pserver: feature to be useful for anything
> other than anonymous read-only access to a mirror of the master
> repository. It was and is a fairly insecure hack that I would rather see
> removed from cvs. So, I am probably the wrong person to ask about how to
> use it to allow writers...
>
> > All objects in the /cvs directory are owned by cvsaccess/cvs with all
> > files having 444 permissions, the directories having 775 permissions.
> > This is a mess. Since the same user that accesses the main server via
> > ssh has write permissions due to membership in the 'cvs' group, this
> > allows nuking of the repository files. How do I fix this?
>
> One way is to ensure that the users are only given access to the 'cvs'
> command via SSH on login.
This I can't do since the machine is intended to be wide open (relatively) to
all users. It's an internal server with home directories, etc...
>
> > Also, would it help if I enforced a provision that all users access cvs
> > using :ext: only via ssh? How would this work with WinCVS users?
>
> Yes. If only ssh access may be granted to the machine, it is possible to
> use the command= feature of the OpenSSH .ssh/authorized_keys file to
> restrict the command the user is able to run to that of 'cvs server'
> which is desirable to limit the ways in which the user may fiddle with
> files in the repository.
Again, see above. I can't restrict the user to what commands he/she may run.
I was thinking about a different set of users, thus giving each human two ids,
one for general server access and the other strictly for CVS over ssh. We
are a small operation so the id duplication is not that big of a deal, except
for getting everyone to update themselves (generating new keys, making a new
user on each local machine with the required home and .ssh directories).
THEN, I can limit this other user, and play with permissions to restrict as
needed. Is this a viable plan? Is anybody else doing something like this?
This seems to be a bit of a design limitation for CVS, no?
Pierre Asselin
> I have this problem also. It's already happened, and I had to restore with
> backups. I need to restrict the /cvs directory so the only access to it is
> via CVS, perhaps not even read access.
> The problem is that the cvs directory is on the same machine as all the other
> server stuff including user's server home directories. Thus, a user can
> access the server via a simple 'ssh', then do 'cd /cvs' and have free rein
> due to the permissions set below.
Give them two accounts: one normal shell account and one cvs-only account.
The cvs accounts are in group cvs but have invalid passwords; the shell
accounts have normal passwords but are not in group cvs. Put their ssh
public keys in ~cvsaccounts/.ssh/authorized_keys with permission to run
only "cvs server" (see the sshd man page, "AUTHORIZED_KEYS FILE FORMAT").
Tell them to login to their normal account, set CVS_RSH to ssh and set
their CVSROOT to :ext:cvsaccount@localhost:/path/to/repo .
That limits the main path to the repository. If you think one of them
might try to rm -rf the repository from a commitinfo hook, tighten the
permissions on the CVSROOT module and circulate a memo to explain the
concept of a "firing offense".
Mark D. Baushke
Hash: SHA1
xy...@hotpop.com writes:
> > I have known others to make the cvs executable be set-gid to a 'cvs'
> > group and for all directories to be owned by a user 'cvs' and group
> > 'cvs' and have 'u=rwx,g=rwxs,o=' (2770) permissions for all directories.
> > This does not get around the problem that files committed or new
> > directories added will be owned by the user who made the change, so
> > those files and directories may need a periodic cron job to change
> > ownership in the tree of directories and ,v files. However, it may be
> > mitigated somewhat by the user not being able to 'see' the files under
> > the repository hierarchy as they are not in the group 'cvs' which only
> > cvs is able to see. The downside is that you need to be very careful
> > with taint checks for the verifymsg/commitinfo/loginfo/taginfo scripts.
>
> So, what you are saying here is that if the cvs executable is set-gid
> to a group that do NOT have the users in it, those users can still
> commit, checkout, etc, but will not be able to see the directory
> hierarchy aside from the cvs root?
Yes.
> I don't understand what you mean by 'taint checks' and how they apply here.
> Do you have any sort of URL reference so I can RTFM?
For example, if you use perl and the egid is not the same as the gid,
then perl itself will invoke taintperl. You sould be able to find
information on that on the perl web site. Basically, you will need to
make sure that all inputs to the scripts that are run with an egid/gid
mismatch deal properly with the situation. In some cases, you may need
the script to drop egid permissions lest the user be able to subvert
your permissions.
For example, you would need to carefully check that commits to the
CVSROOT are done only by very trusted individuals so that no user may
use those scripts that are executed at commit time to raise their own
privledge level.
> > Are you talking about an :ext: user or a :pserver: user?
>
> :pserver: definitely.
I am not able in good conscience to recommend that anyone use :pserver:
for commit access to any cvs repository at any time. Opinions on this
matter differ and you will likely get a mixture of such opinions from
members of this list.
> > One way is to ensure that the users are only given access to the 'cvs'
> > command via SSH on login.
>
> This I can't do since the machine is intended to be wide open
> (relatively) to all users. It's an internal server with home
> directories, etc...
This is a not a good situation. I would strongly urge you to talk with
your management and try to remedy the situation by moving to a separate
machine to serve as your cvs server.
> I was thinking about a different set of users, thus giving each human
> two ids, one for general server access and the other strictly for CVS
> over ssh.
If you are serious, then you could move to a virtual machine such as is
being used by many ISPs. The repository would then reside inside of a
virtual machine in a chrooted environment which normal users would not
be able to visit by allowing only root to access the directory that holds
the chroot directory in which the virtual machine/chroot jail runs.
> We are a small operation so the id duplication is not that
> big of a deal, except for getting everyone to update themselves
> (generating new keys, making a new user on each local machine with the
> required home and .ssh directories). THEN, I can limit this other
> user, and play with permissions to restrict as needed. Is this a
> viable plan?
It might work, but you need to consider how growth of your company will
impact your development environment.
> Is anybody else doing something like this?
http://www.pointless.nl/~peter/stuff/cvs-server.html
> This seems to be a bit of a design limitation for CVS, no?
No, you are asking how to avoid casual or malicious damage to the
repository. It is possible to do this, but it is not required for all
users of cvs. Also, special-purpose boxes are a reasonable configuration
for cvs servers and are able to provide what is needed.
cvs has been around a long time and was originally not even a
client/server design. If you don't like it, you are welcome to
look at other systems.
Version control systems of possible interest include:
aegis, arch, bitkeeper, clearcase, cmsynergy, co-op, cvs, cvsnt,
monotone, opencm, perforce, subversion, svk, vesta
one of which may find all the features you think you want.
Good luck,
-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFAQ2wV3x41pRYZE/gRAld0AKCndxhZ6iD7tv40GwsFgFP7cAgx4gCeM/NL
UkBepdkAWRx7rGZAF37cSFU=
=+LKG
-----END PGP SIGNATURE-----