Re: Problem with admin privileges
Todd Denniston wrote: CLIP The only reason I am using pserver is that it allows my users to have CVAS controlled access to the respositories without giving them dierct write access to them. If you can suggest another way of doing that, I'd be glad to use it. As Far As I Know, you are correct, but at best you are only protecting them from a fat fingering while in the repository and do not have malicious intent. The first rule of the repository for users should be that if you are not the admin you never execute any non cvs command against it. The first rule of the repository for admins is back it up appropriately, as hardware/network/software faults can damage the work. With these two rules, I believe you should have at least as good a set of protection as pserver would get you, because you don't have developers with malicious intent and who follow the rules :} Pretty much true: if it isn't, I've got worse problems :) As long as the developers are using only :ext: cvs commands against the repository, I believe you should still be able to meet your FAA requirements: FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. but would be counting on the backups to prevent you from loosing any lifecycle data, which is what you would be back to if they were looking at you with strictness when there is a known hole in pserver. In final, Yes using pserver will probably make it easier to show up front that everything meets the requirements, but in the past it has been the bain of security with cvs. I belive you are in the middle ground between the restricted execution of CVS Mark D. Baushke told you about, and the trusting developers ground of :ext: on a system they can execute more than cvs on. I further belive that you are only mildly protected from what you worry about, using your method. Where as one of the restricted execution of CVS would probably allow much more of the FAA level security lock down and logging. if you want further reading I suggest searching the list's archive for Greg Woods AND pserver OR Greg Woods AND authentication AND|OR authorization. I think the horse is dead, so I'll stop beating. SNIP Well I think the horse has completed the track, and I think we've won the race, inasmuch as I have fat-finger protection, which is all I need: I am backing up, after all, as you suggest (and as insisted upon by our friends at the FAA, in fact), and the backup includes logs, so I'm meeting the obligation. There is rarely a perfect solution for special needs situations such as this, but I think I've got the closest practical solution, and as long as my local FAA officer is happy, then so am I. Todd, you obviously spent plenty of time thinking and writing. Thank you very much for your opinions, insight and help. julian. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius wrote: SNIP Thanks for this input! The problem is that each of these articles achieve their intended results by restricting commands to cvs. I don't want to do that: my CVS users are my engineering department members with legitimate logins. It's only access to the CVS repositories that I have to control. PServer through ssh does exactly what I want in that regard. Big question: What do you think using :pserver: at this point, gain you and your users over just :ext: over ssh? Because they already have (and will continue to have) valid system shell login, from here it only looks like more admin trouble to setup and maintain pserver, plus it probably reduces the authentication or authorization you had from the ssh and system level, especially when a new pserver hole comes out. I have solved most of my admin problem by running admin users as their themselves using $CVSROOT/CVSROOT/passwd entries like this: username:password rather than as the global cvs user: username:password:cvs SNIP Why use the $CVSROOT/CVSROOT/passwd at all, just use the system authentication fallback, it SHOULD make your life easier because only the system level auth files need scrubbed when someone leaves not the system level AND all the cvs repos. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Todd Denniston wrote: Big question: What do you think using :pserver: at this point, gain you and your users over just :ext: over ssh? Because they already have (and will continue to have) valid system shell login, from here it only looks like more admin trouble to setup and maintain pserver, plus it probably reduces the authentication or authorization you had from the ssh and system level, especially when a new pserver hole comes out. How does a hole in pserver reduce security? Is ssh protecting me or not? I realize that all security is additive, but pserver would seem to be no more than paint on the wall of ssh, meaning that if ssh goes down, pserver won't help, but then again it won't hinder either. I have solved most of my admin problem by running admin users as their themselves using $CVSROOT/CVSROOT/passwd entries like this: username:password rather than as the global cvs user: username:password:cvs SNIP Why use the $CVSROOT/CVSROOT/passwd at all, just use the system authentication fallback, it SHOULD make your life easier because only the system level auth files need scrubbed when someone leaves not the system level AND all the cvs repos. The only reason I am using pserver is that it allows my users to have CVAS controlled access to the respositories without giving them dierct write access to them. If you can suggest another way of doing that, I'd be glad to use it. From a security perspective, my understanding is that ssh gives me adequate protection from invasion from the outside world, (ssh is the only port mapped through NAT to the server) and I have not yet identified a need to protect my data from malicious intent from inside, so I'm not really sure what the risks of pserver over ssh really are. As a final disclaimer: I'm an embedded software engineering manager, not a network guru, and the network is a means to an end, not a reason to live, so if I'm missing something, please feel free to snicker and roll your eyes - as long as you then enlighten me as to what I should be doing ;-) Cheers! julian. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Mark D. Baushke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julian Opificius [EMAIL PROTECTED] writes: Larry Jones wrote: Julian Opificius writes: I'm not quite sure what you mean by mapping users. Using the third field of the CVSROOT/passwd file to have the server run as some user other than the actual user. Yep, that's what I am/was doing. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. There's no need to use pserver for that. In fact, pserver is a giant security hole that is best avoided. Since you're giving your users ssh access to the server anyway, the best thing for you to do is to use :ext: mode with ssh rather than rsh (which should be the default if you're running CVS 1.12). Each user logs in as themselves and you can then use ordinary file permissions to control who has access to what. See the manual for details: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. How can I maintain this level of integrity without pserver: keeping the repository itself inaccessible, while allowing write access through cvs? Using ssh in a restricted execution mode in general and for restricted execution of CVS is discussed in many places. I suggest you may find more reading useful... try these documents: http://www.idealx.org/doc/chrooted-ssh-cvs-server.en.html http://www.prima.eu.org/tobez/cvs-howto.html http://www.informatimago.com/linux/chrooted-ssh-cvs.html You may also find other documentions via your favorite search engine. Thanks for this input! The problem is that each of these articles achieve their intended results by restricting commands to cvs. I don't want to do that: my CVS users are my engineering department members with legitimate logins. It's only access to the CVS repositories that I have to control. PServer through ssh does exactly what I want in that regard. I have solved most of my admin problem by running admin users as their themselves using $CVSROOT/CVSROOT/passwd entries like this: username:password rather than as the global cvs user: username:password:cvs The only problem now is that if a cvsadmin user introduces a directory into the cvs repository using add, the directory is owned by him, not by the global cvs user, and nobody else can check into/out of that directory. How do I automatically force new directories created by the cvs server to be owned by the global cvs user, rather than the effective user? Maybe there is a Linux feature - something akin to setuid - that operates on the top level repository directory? julian. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julian Opificius [EMAIL PROTECTED] writes:
The only problem now is that if a cvsadmin user introduces a directory
into the cvs repository using add, the directory is owned by him, not
by the global cvs user, and nobody else can check into/out of that
directory.
How do I automatically force new directories created by the cvs server
to be owned by the global cvs user, rather than the effective user?
This is the wrong question.
Maybe there is a Linux feature - something akin to setuid - that
operates on the top level repository directory?
You could have the directories all be in a 'cvs' group and use
find $CVSROOT -type d -exec chgrp cvs g+s {} \;
find $CVSROOT -type d -exec chmod g+s {} \;
The cvs user could belong to this group 'cvs' as well as your admin
users. New files and directories created will inherit the groupid of the
parent directory. A crontab job could go thru and change the ownership
of the files and directories in the tree to that of the 'cvs' user on a
periodic basis as additional cleanup if desired.
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCxwa73x41pRYZE/gRAhQ3AJ9W5T0ZFGxZhOLYa3WqSNIZAgOCmACgzSMz
adob8OzUA267AGIbaEy8mK4=
=q9hb
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Mark D. Baushke wrote:
The only problem now is that if a cvsadmin user introduces a directory
into the cvs repository using add, the directory is owned by him, not
by the global cvs user, and nobody else can check into/out of that
directory.
How do I automatically force new directories created by the cvs server
to be owned by the global cvs user, rather than the effective user?
This is the wrong question.
why is that? Maybe I should be talking group here not owner?
You could have the directories all be in a 'cvs' group and use
find $CVSROOT -type d -exec chgrp cvs g+s {} \;
find $CVSROOT -type d -exec chmod g+s {} \;
The cvs user could belong to this group 'cvs' as well as your admin
users. New files and directories created will inherit the groupid of the
parent directory. A crontab job could go thru and change the ownership
of the files and directories in the tree to that of the 'cvs' user on a
periodic basis as additional cleanup if desired.
g+s is not a valid arg for chgrp. what did you really mean here?
my admin users do already belong to the cvs group, as do all the
repository directories.
I think what you're effectively saying here is that by setting sticky on
the directories, then new directories are created group cvs, and owner
is not important. Is that right?
j.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Hi Julian. Julian Opificius wrote: Mark D. Baushke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julian Opificius [EMAIL PROTECTED] writes: The only problem now is that if a cvsadmin user introduces a directory into the cvs repository using add, the directory is owned by him, not by the global cvs user, and nobody else can check into/out of that directory. How do I automatically force new directories created by the cvs server to be owned by the global cvs user, rather than the effective user? Maybe there is a Linux feature - something akin to setuid - that operates on the top level repository directory? julian. I solved by putting this in loginfo file (i.e. during commit): new_dir (chgrp -Rf global_cvs_user $CVSROOT/new_dir) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julian Opificius [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
The only problem now is that if a cvsadmin user introduces a directory
into the cvs repository using add, the directory is owned by him, not
by the global cvs user, and nobody else can check into/out of that
directory.
How do I automatically force new directories created by the cvs server
to be owned by the global cvs user, rather than the effective user?
This is the wrong question.
why is that? Maybe I should be talking group here not owner?
Why are new files and directories being created with the wrong group
on the server? Read: https://ccvs.cvshome.org/fom//cache/33.html
See also the paragraph of section '2.2.2 File permissions' of the manual:
https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13
You could have the directories all be in a 'cvs' group and use
find $CVSROOT -type d -exec chgrp cvs g+s {} \;
Sorry about the typo.
: all the groups should be owned by group cvs
find $CVSROOT -type d -exec chgrp cvs {} \;
: all the group members should be able to write to it
find $CVSROOT -type d -exec chmod g+rwxs {} \;
find $CVSROOT -type d -exec chmod g+s {} \;
The cvs user could belong to this group 'cvs' as well as your admin
users. New files and directories created will inherit the groupid of the
parent directory. A crontab job could go thru and change the ownership
of the files and directories in the tree to that of the 'cvs' user on a
periodic basis as additional cleanup if desired.
g+s is not a valid arg for chgrp. what did you really mean here?
Oops, that was a typo... sorry about that.
my admin users do already belong to the cvs group, as do all the
repository directories.
I think what you're effectively saying here is that by setting sticky
on the directories, then new directories are created group cvs, and
owner is not important. Is that right?
Yes.
This is true for GNU/Linux, AIX, and Solaris.
The g+s bit is not needed for FreeBSD or NetBSD which has this behavior
by default.
See also 'Creating a cvs repository with pserver authentication'
http://www.korayguclu.de/index.php?file=linux.cvs.pserver.xml
Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCxySW3x41pRYZE/gRAotPAKCy9ittECD0XWxhvMnmjeSOxTKungCgkaNi
N9BSSqGJpnQiSrFHZb5y9q0=
=hpPV
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Larry Jones wrote: Julian Opificius writes: I just instigated admin controls by opening up and configuring the UserAdminOptions setting. My account is a member of Linux cvsadmin group, yet like non-privileged users I cannot execute admin commands. Then you're not really a member of the cvsadmin group. If you just added your account to the group, you have to log out and back in again before it takes effect. The id command will show you which groups you're really a member of. That's the confusing thing; id tells me I'm a member of cvsadmin. Is there any restriction about userid range? I'm 1000, cvsadmin group is 502. julian. = -Larry Jones Girls are so weird. -- Calvin tell me about it - I've married three of them so far ... ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: I just instigated admin controls by opening up and configuring the UserAdminOptions setting. My account is a member of Linux cvsadmin group, yet like non-privileged users I cannot execute admin commands. Then you're not really a member of the cvsadmin group. If you just added your account to the group, you have to log out and back in again before it takes effect. The id command will show you which groups you're really a member of. -Larry Jones Girls are so weird. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: That's the confusing thing; id tells me I'm a member of cvsadmin. Is there any restriction about userid range? I'm 1000, cvsadmin group is 502. In that case, my guess is that you're not using your account, you're using the generic cvs account (you say all of your CVS users are mapped to the same cvs system user and it's the system user that has to be in the cvsadmin group). Mapping all of your CVS users to the same system user destroys any system-level security or accountability since everyone appears to be the same user. If you have SSH access to the system, you're much better off using it directly in :ext: mode as individual system users rather than tunnelling pserver and mapping everyone to the same user. -Larry Jones When you're as far ahead of the class as I am, it doesn't take much time. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Larry Jones wrote: Julian Opificius writes: That's the confusing thing; id tells me I'm a member of cvsadmin. Is there any restriction about userid range? I'm 1000, cvsadmin group is 502. In that case, my guess is that you're not using your account, you're using the generic cvs account (you say all of your CVS users are mapped to the same cvs system user and it's the system user that has to be in the cvsadmin group). Mapping all of your CVS users to the same system user destroys any system-level security or accountability since everyone appears to be the same user. If you have SSH access to the system, you're much better off using it directly in :ext: mode as individual system users rather than tunnelling pserver and mapping everyone to the same user. -Larry Jones I'm not quite sure what you mean by mapping users. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. I need Internet access, which is why I tunnel across ssh. The instructions I followed to configure cvs suggested I use a userlogin:password:cvsaccount structure to the $CVSROOT/CVSROOT/passwd file, so each user would have his/her specific cvs-related privileges, but that the server would run as user cvs. If I'm not understanding this correctly, please let me know :-) j. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: I'm not quite sure what you mean by mapping users. Using the third field of the CVSROOT/passwd file to have the server run as some user other than the actual user. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. There's no need to use pserver for that. In fact, pserver is a giant security hole that is best avoided. Since you're giving your users ssh access to the server anyway, the best thing for you to do is to use :ext: mode with ssh rather than rsh (which should be the default if you're running CVS 1.12). Each user logs in as themselves and you can then use ordinary file permissions to control who has access to what. See the manual for details: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones I obey the letter of the law, if not the spirit. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Larry Jones wrote: Julian Opificius writes: I'm not quite sure what you mean by mapping users. Using the third field of the CVSROOT/passwd file to have the server run as some user other than the actual user. Yep, that's what I am/was doing. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. There's no need to use pserver for that. In fact, pserver is a giant security hole that is best avoided. Since you're giving your users ssh access to the server anyway, the best thing for you to do is to use :ext: mode with ssh rather than rsh (which should be the default if you're running CVS 1.12). Each user logs in as themselves and you can then use ordinary file permissions to control who has access to what. See the manual for details: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. How can I maintain this level of integrity without pserver: keeping the repository itself inaccessible, while allowing write access through cvs? j. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julian Opificius [EMAIL PROTECTED] writes: Larry Jones wrote: Julian Opificius writes: I'm not quite sure what you mean by mapping users. Using the third field of the CVSROOT/passwd file to have the server run as some user other than the actual user. Yep, that's what I am/was doing. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. There's no need to use pserver for that. In fact, pserver is a giant security hole that is best avoided. Since you're giving your users ssh access to the server anyway, the best thing for you to do is to use :ext: mode with ssh rather than rsh (which should be the default if you're running CVS 1.12). Each user logs in as themselves and you can then use ordinary file permissions to control who has access to what. See the manual for details: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. How can I maintain this level of integrity without pserver: keeping the repository itself inaccessible, while allowing write access through cvs? Using ssh in a restricted execution mode in general and for restricted execution of CVS is discussed in many places. I suggest you may find more reading useful... try these documents: http://www.idealx.org/doc/chrooted-ssh-cvs-server.en.html http://www.prima.eu.org/tobez/cvs-howto.html http://www.informatimago.com/linux/chrooted-ssh-cvs.html You may also find other documentions via your favorite search engine. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCwF2X3x41pRYZE/gRAv1sAJ0e08Qbt74VqXR4ELjguqFkoruPPwCdHKna u9OpZ7vumWiDN1fHzzEFa/s= =sqVv -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius wrote: SNIP I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. How can I maintain this level of integrity without pserver: keeping the repository itself inaccessible, while allowing write access through cvs? If you search the list[1] and some of the howtos you should be able to figure out how to set ssh so that the users can only execute one command on the server, that command is 'cvs'. If you are already giving them SSH access to the machine, to then run pserver, you have less accountability (and/or authentication [I can never remember which]) than if you were just giving them SSH (with no restrictions on commands), because all logs show the cvs user they are mapped to instead of the real user name (look for some of Greg A. Woods posts[2] on these matters). [1] http://lists.gnu.org/archive/html/info-cvs/ A promising hit is http://lists.gnu.org/archive/html/info-cvs/2003-09/msg00203.html [2] http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=woods+AND+ssh+AND+pserveridxname=info-cvsmax=20result=normalsort=score -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. Please note that CVS was designed to enable collaboration, not to enforce access controls and audit trails. -Larry Jones The problem with the future is that it keeps turning into the present. -- Hobbes ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
