-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Derek Price <[EMAIL PROTECTED]> writes:
> Mark D. Baushke wrote: > > > For pserver, the administrator has full control over > > the command line. > > > > For server, if the administrator is using a > > restricted shell for users, they may or may not be > > able to restrict command-line arguments (it > > depends on how the restricted shell is > > implemented). > > For server, OpenSSH, at the very least, allows > the command line to be restricted. Are we really > worried about the security of the command line > if the user is still using a vulnerable tool > like RSH to access their server? Well, I would like to try not to impose implementation decisions on administrators if possible. Just because the $HOME/.ssh/authorized_keys file is able to specify a command= parameter for OpenSSH does not mean that is the only version of secure transport that exists (cf gssapi). > > I have used (am using) a set-gid cvs and it > > does not disable the use of UNIX uids at all. > > Yes, it does inhibit gids as the entire > > repository uses the same gid ('cvs'), but the > > cvs_acls deals with permissions for commit and > > anyone with a login to the special-purpose CVS > > server has already been granted read > > permissions for checkout in any case. > > > > I will grant you that this is not necessarily a > > normal situation, but I make note of it as setuid > > is not the only configuration possiblity here. > > > Well, no, but for a secure setup, aren't we > still recommending that the admin rely on a > transport such as SSH and filesystem permissions > or ACLs for access restriction in the > repository? Yes. > The stated position of the CVS developers has > been that users should rely on systems that get > more thorough security audits than CVS does to > provide the secure portions of their setups. Yes. > This means using SSH as a transport, restricting > the command line, and relying on system > permissions/ACLs to restrict access to the > various portions of a repository. Sure, but is would be better to not make for fragile configurations that are accidentally broken by administrators who do not understand the subtle holes that might be available. > setuid and setgid CVS executables both disable > the fine-grained access restrictions that would > otherwise be possible, limiting you, basically, > to one group per repository/server. Actually, one rational for going to a set-gid CVS executable was that there were so many groups in use on the system that it exceeded the Solaris maximum number at the time. Letting everyone play with a set-gid executable gave them an extra group without burning thru the maximum number allowed by the OS. Fine grained access can go to far in some cases and it is best to allow the administrators as much flexibility as possible. > > As an alternative, I would not have a problem with > > allowing cvs to be built with a list of > > directories that could be searched for a valid > > config file. So, a --enable-config-prefix=/etc/cvs > > might mean that /etc/cvs/$CVSROOT/config would looked > > at before $CVSROOT/config ... doing that means that > > the administrator would still have complete control > > over the configurations and would not need to rely > > on the user to make the right choice. > > > This compromise does sound reasonable. Would you > then consider a default value of > `--enable-config-prefix=/etc' as reasonable > here? i.e. the ability to override the config > would default to `on', with access to config > files restricted to /etc and subdirs. Sure. However, /etc is fairly crowded which is why I suggested /etc/cvs as an alternative. > > The downside is that src/sanity.sh tests for this > > case would be more painful. > > Well, we could test that the restricted paths > were disabled, at least. Sure. > > As far as your src/sanity.sh tests, I believe you > > should use the -c CONFIG-FILE to determine if cvs > > has been configured with this option or not before > > you fail the tests (granted STABLE does not have > > that available to sanity.sh) > > > If it defaults to on, with config-prefix used as > you suggest, would you still consider this last > important? No. If we go with a config-prefix, then defaulting to ON would be okay in my opinion. Note: It may be desirable to consider config-prefix to be a prefered list of directories with the last directory searched being $CVSROOT/CVSROOT ... So, --config-prefix='/etc/cvs:/usr/local/etc/cvs' would mean that the config file would be the first of /etc/cvs/$CVSROOT/config /usr/local/etc/cvs/$CVSROOT/config $CVSROOT/CVSROOT/config that existed. -- Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCi6PI3x41pRYZE/gRAqcEAJ9iujX545bLiG28OHM+2JXob/nl0QCgyTLa fNJYVUPgm/bZ2ofYQB2fD3E= =gGYI -----END PGP SIGNATURE----- _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs