[gitolite] repo config for delegated projects

[gitolite] repo config for delegated projects

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Dear Sitaram, dear Teemo, dear gitolite-fans,

src/gl-compile-conf:261 prohibits delegated repositories to make use
of the functionality to configure config variables of the
repositories:

  die "$WARN $fragment attempting to set repo configuration\n"
    if $fragment ne 'master';

This is a bit unfortunate and makes me reconsider the use of
delegations.

What is the reason for this restriction?

Are there settings that are potentially compromising?

Would it be worth to consider making it configurable (e.g.
~/.gitolite.rc) whether to allow delegated repos to set config
variables?

-- 
 .''`.   martin f. krafft <madduck@d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"there are two major products that come out of berkeley: lsd and unix."
 one caused me an addiction
                                                             -- fyodor

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gitolite] repo config for delegated projects

[Teemu Matilainen]

On Thu, 04 Feb 2010, martin f krafft wrote:

> src/gl-compile-conf:261 prohibits delegated repositories to make use
> of the functionality to configure config variables of the
> repositories:
> 
>   die "$WARN $fragment attempting to set repo configuration\n"
>     if $fragment ne 'master';
> 
> This is a bit unfortunate and makes me reconsider the use of
> delegations.
> 
> What is the reason for this restriction?

Well, the main reason probably is that I don't personally use delegation
and got tired of even thinking about the security concerns. =)

> Are there settings that are potentially compromising?

I think it depends on the setup and especially hooks.
Can't come up with any real problem, though.

> Would it be worth to consider making it configurable (e.g.
> ~/.gitolite.rc) whether to allow delegated repos to set config
> variables?

That's Sitaram's call. :)


-- 
	- Teemu

Re: [gitolite] repo config for delegated projects

[Sitaram Chamarty]

On Thu, Feb 04, 2010 at 09:22:49AM +1300, martin f krafft wrote:
> Dear Sitaram, dear Teemo, dear gitolite-fans,
> 
> src/gl-compile-conf:261 prohibits delegated repositories to make use
> of the functionality to configure config variables of the
> repositories:
> 
>   die "$WARN $fragment attempting to set repo configuration\n"
>     if $fragment ne 'master';
> 
> This is a bit unfortunate and makes me reconsider the use of
> delegations.
> 
> What is the reason for this restriction?

Like Teemu said, inability to think through all the possible
repurcussions of allowing a delegated admin to set config
variables.  There are too many of them for me to go through,
and they'll keep changing.

To recap, what gitolite wants to do is broadly the
following:

  - no one who is not admin can do anything to a repo that
    the config file does not permit him to do (this is not
    affected by the topic of this email; just adding it for
    completeness)

  - the main admin (who has RW/RW+ access to all of the
    gitolite-admin repo) cannot get shell access on the
    server.  This is a relatively new restriction; initially
    I did not think to keep these two privileges separate

  - a delegated admin cannot manage any sort of access to
    repos that the main admin did not delegate to him.

> 
> Are there settings that are potentially compromising?
> 
> Would it be worth to consider making it configurable (e.g.
> ~/.gitolite.rc) whether to allow delegated repos to set config
> variables?

I wouldn't mind making it configurable, with the default
being off.  Rather than a blanket

    $ALLOW_DELEGATE_CONFIGS = 1;

how about

    $DELEGATED_CONFIGS = "hooks.mailinglist,hooks.showrev";

(to take Teemu's example config file and the config
variables he uses), so that you (or whoever has shell
access, which is required for changing RC file) can sort of
limit the potential damage.

And the defaults would all be commented out anyway so people
who don't car about this will never have to worry about it.

Regards,

Sitaram

Re: [gitolite] repo config for delegated projects

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1418 +1300]:
> how about
> 
>     $DELEGATED_CONFIGS = "hooks.mailinglist,hooks.showrev";

Excellent idea.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
now I lay me back to sleep.
the speaker's dull; the subject's deep.
if he should stop before I wake,
give me a nudge for goodness' sake.
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gitolite] repo config for delegated projects

[Sitaram Chamarty]

On Thu, Feb 4, 2010 at 9:38 AM, martin f krafft <madduck@madduck.net> wrote:
> also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1418 +1300]:
>> how about
>>
>>     $DELEGATED_CONFIGS = "hooks.mailinglist,hooks.showrev";
>
> Excellent idea.

OK I've run into a little decision-point here.

The problem above is of making sure that a delegated admin cannot
misuse the gitconfig mechanism to do stuff he's not allowed to do, but
it's actually worse than that :(

First some background.  For a long time I treated the "main" admin
(anyone who has RW/RW+ rights to gitolite.conf) to be eqvt to having
shell access.  Then we started moving away from that, and that is good
because having shell access allows him to bypass the logging that
gitolite does, thus polluting the audit trail.  Preventing that makes
a lot of sense in a corporate environment, and lets you allow a lot
more people to manage the gitolite access list.

Now I just looked up hooks.showrev, and it's supposed to be any shell
command.  Clearly this means anyone who can set that gitconfig option
now has shell capability, and it's game over.

Regardless of how I look at it, I can't think of a cure for this short
of either:
  - putting all the allowed gitconfigs in the RC file, and not in the
config (writing the RC file requires shell access, and we presume the
"root of trust" person has enough smarts to know what to allow and
what not to allow), and allowing repo admins to *refer* to them to use
whichever they want
  - someone coming up with a list of gitconfig's that are "safe", and
specific values for those that are unsafe (like saying "if you use
showrev, you can only use this command  as the value", and forcing
only those.

I'm leaning toward the former; easier for me ;-)  Meanwhile, I'm
punting this to Teemu until the morning fog in my brain clears :)

Re: [gitolite] repo config for delegated projects

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]

also sprach Sitaram Chamarty <sitaramc@gmail.com> [2010.02.06.1350 +1300]:
> OK I've run into a little decision-point here.
> 
> The problem above is of making sure that a delegated admin cannot
> misuse the gitconfig mechanism to do stuff he's not allowed to do,
> but it's actually worse than that :(

Let me thus challenge the whole delegation mechanism.

When I first encountered it, I thought it was a great idea, but it
seems to promise more than it can do. I understand that the reasons
for that are security-related, and I tip my hat to you for being so
conscious about this — better have a secure system with limited
functionality, than an insecure system that can do everything (why
am I thinking of PHP apps right now???).

The wildrepos branch is a definite improvement to proper delegation.
Without it, the main admin has to change the main configuration file
every time that a delegated admin wants to add a new repo.

However, given the somewhat awkward configuration (you need to add
delegated admins in multiple places), and the restrictions, I am
starting to wonder what use-case delegations solve that couldn't be
addressed easier with multiple accounts and gitolite instances.
Thoughts?

> Regardless of how I look at it, I can't think of a cure for this short
> of either:
>   - putting all the allowed gitconfigs in the RC file, and not in the
> config (writing the RC file requires shell access, and we presume the
> "root of trust" person has enough smarts to know what to allow and
> what not to allow), and allowing repo admins to *refer* to them to use
> whichever they want
>   - someone coming up with a list of gitconfig's that are "safe", and
> specific values for those that are unsafe (like saying "if you use
> showrev, you can only use this command  as the value", and forcing
> only those.

I think the second path is a red herring. However, I don't
understand why we would need to go via the RC file instead of the
main config. Only the main admin can modify that, or appoint others
to modify it. Plus, it's managed in Git and thus has a history
attached to it.

Speaking of shell access, I notice gl-auth-command has the -s
option. Is there a configuration variable that I overlooked which
allows me to give shell login rights to specific users?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
review of a chemistry paper:
  "paper should be greatly reduced or completely oxidized."
                                                    -- frank vastola
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gitolite] repo config for delegated projects

[Sitaram Chamarty]

On Sat, Feb 06, 2010 at 05:22:22PM +1300, martin f krafft wrote:
> also sprach Sitaram Chamarty <sitaramc@gmail.com> [2010.02.06.1350 +1300]:
> > OK I've run into a little decision-point here.
> > 
> > The problem above is of making sure that a delegated admin cannot
> > misuse the gitconfig mechanism to do stuff he's not allowed to do,
> > but it's actually worse than that :(
> 
> Let me thus challenge the whole delegation mechanism.
> 
> When I first encountered it, I thought it was a great idea, but it
> seems to promise more than it can do. I understand that the reasons
> for that are security-related, and I tip my hat to you for being so
> conscious about this — better have a secure system with limited
> functionality, than an insecure system that can do everything (why
> am I thinking of PHP apps right now???).
> 
> The wildrepos branch is a definite improvement to proper delegation.
> Without it, the main admin has to change the main configuration file
> every time that a delegated admin wants to add a new repo.
> 
> However, given the somewhat awkward configuration (you need to add
> delegated admins in multiple places), and the restrictions, I am
> starting to wonder what use-case delegations solve that couldn't be
> addressed easier with multiple accounts and gitolite instances.
> Thoughts?

In theory, none at all.  And if you're not in a corporate
environment, having separate accounts and instances is
probably easier, as I myself suggest to people sometimes
when they need *more* from delegation than what it has now.

What it gives you is *one* central place for all the code,
one set of users/ids and one entity to approve new ones, and
the means to delegate only the most volatile changes (like
at the branch-within-project level), and not the longer term
ones like actually adding a new user or a new project
(assuming you're not using wildrepos).

It turns out that this is closer to what corporate
environments want.  I use it, and a few groups in my $DAYJOB
also use it, afaik.

But I guess my original question was more for Teemu.  As it
stands, I need to redo the ability for even the "main" admin
to add gitconfigs... it allows him to get a shell too
easily.

> > Regardless of how I look at it, I can't think of a cure for this short
> > of either:
> >   - putting all the allowed gitconfigs in the RC file, and not in the
> > config (writing the RC file requires shell access, and we presume the
> > "root of trust" person has enough smarts to know what to allow and
> > what not to allow), and allowing repo admins to *refer* to them to use
> > whichever they want
> >   - someone coming up with a list of gitconfig's that are "safe", and
> > specific values for those that are unsafe (like saying "if you use
> > showrev, you can only use this command  as the value", and forcing
> > only those.
> 
> I think the second path is a red herring. However, I don't
> understand why we would need to go via the RC file instead of the
> main config. Only the main admin can modify that, or appoint others
> to modify it. Plus, it's managed in Git and thus has a history
> attached to it.

That's what I used to think, that it doesn't matter.

But there's a notion (and once I realised it I agreed with
it) that the ability to do "shell" things on the server is a
step higher than the ability to update gitolite's access
list.

Some people needed this, and I agreed.  Nothing prevents any
installation from giving anyone any rights, but I'd like to
prevent them acquiring it via gitolite, even if they can
write to the admin repo.

So right now (coming back to the ability to set gitconfig
from within gitolite) I'm thinking:

    $GL_GITCONFIG_KEYS = "core.foo core.baz";
        # actually list of regexes for valid keys

and advising people that these are the choices in terms of
allowing gitconfig from the admin repo (or delegation; no
difference):

  - (ultra paranoid mode): set the variable above to empty;
    no gitconfig allowed from gitolite.conf or delegated
    conf files
  - (just your normal everyday paranoia mode): set the
    variable to stuff that you know will not give shell
    access (example: the aforementioned hooks.mailinglist)
  - ("what, me worry?" mode): set that variable to ".*" and
    allow any damn gitconfig so they won't keep pestering
    you to add a config for them!

In the first 2 cases, someone with shell access must do all
required gitconfigs manually on the server when needed.

> Speaking of shell access, I notice gl-auth-command has the -s
> option. Is there a configuration variable that I overlooked which
> allows me to give shell login rights to specific users?

yes; it's in the RC file.  If you want to give anyone shell
access, add their name to a space-sep list in $SHELL_USERS
and push the config once.

The documentation for this is in a weird place (doc/6);
sorry about that!  Will move it to doc/3 soon.

-- 
Sitaram

Re: [gitolite] repo config for delegated projects

[Teemu Matilainen]

On Sat, 06 Feb 2010, Sitaram Chamarty wrote:

> Now I just looked up hooks.showrev, and it's supposed to be any shell
> command.  Clearly this means anyone who can set that gitconfig option
> now has shell capability, and it's game over.

But of course you need to have a hook that runs the command.  And
setting hooks requires shell access.

Sorry for not thinking any problems with the config thing.  I personally
don't use the delegation and on the other hand all our gitolite
administrators anyway have shell access to the server...

> Regardless of how I look at it, I can't think of a cure for this short
> of either:
>   - putting all the allowed gitconfigs in the RC file, and not in the
> config (writing the RC file requires shell access, and we presume the
> "root of trust" person has enough smarts to know what to allow and
> what not to allow), and allowing repo admins to *refer* to them to use
> whichever they want

This sounds better solution for me.

>   - someone coming up with a list of gitconfig's that are "safe", and
> specific values for those that are unsafe (like saying "if you use
> showrev, you can only use this command  as the value", and forcing
> only those.

Might get too complicated.  Anyway the person setting the hook script
should know what it does and which configuration keys it uses and how.


-- 
	- Teemu