Re: history and val-tags locks.

[Mark D. Baushke]

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

Derek Price <derek@ximbiot.com> 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-----