Re: create-user

Re: create-user

[Andrew Cagney]

FYI,

A personal opinion on the create user stuff is that a little paper work
never hurt.  When asking for an account to be set up I don't expect same
day sevice and the last thing I want is for it to be rushed.

As an asside, we're going to have to find a better mechanism for
managing access to the /cvs/src repository.  This current blanket access
(don't be naughty but more likely: oops, I screwed up) isn't going to
scale in my opinion.

	Andrew

Re: Restricting permission in 'src' repository (was Re: create-user)

[Tom Tromey]

Jason> This has little to do with Stan's trustworthiness; it's a hedge
Jason> against his personal system getting compromised and a bad person
Jason> getting access to sourceware from there.

I agree.
I just used him as an example of somebody who recently left.

Tom

Re: Restricting permission in 'src' repository (was Re: create-user)

[Stan Shebs]

Chris Faylor wrote:
> 
> On Sat, Mar 04, 2000 at 03:32:32PM -0800, Tom Tromey wrote:
> >Jason> This has little to do with Stan's trustworthiness; it's a hedge
> >Jason> against his personal system getting compromised and a bad person
> >Jason> getting access to sourceware from there.
> >
> >I agree.
> >I just used him as an example of somebody who recently left.
> 
> I don't know.  I think we should block Stan at the firewall, if
> possible.  He's obviously dangerous.

Pfffth, save yourselves the trouble - I control the firewall already.
You think that in seven years I wasn't able to thoroughly infest
Cygnus and now Red Hat?  Thompson is a piker; Trojans through the
compiler, big deal.  It's much craftier to insert them through the
*debugger*... If you want your system to be truly secure, don't
ever run GDB on it!

> I don't know what this "xconq" thing is but it sounds like he's
> planning world domination through X-Windows or something.

I'll trust you guys with the secret - after all, I'm going to need
some *overseers* to help me rule, buwahahahaha!  Next, we infiltrate
Yahoo...

Sa^Htan

Re: create-user

[Chris Faylor]

On Thu, Mar 02, 2000 at 07:45:50PM -0800, Tom Tromey wrote:
>Chris> Out of curiousity, who can run this script?
>
>You have to be root to run it.
>Currently I think that is Jeff Law, Jim Kingdon, Jason Molenda, and me.
>
>Maybe accounts are cheap enough and safe enough that we could fully
>automate account creation.  Then we'd just have to automate letting
>project maintainers give write access to existing accounts.  I gather
>this is what sourceforge does.

Since cygwin seems to be finally ramping up as far as contributors are
concerned, I would like to be able to easily give people accounts
without having to send email to one of the four people above.

I don't know the best way to handle this.  We don't just give people
accounts without first getting some minimal personal information first,
right?  I guess that could be handled in a web form.

cgf

Re: create-user

[Jason Molenda]

On Thu, Mar 02, 2000 at 07:45:50PM -0800, Tom Tromey wrote:
> Chris> Out of curiousity, who can run this script?

> You have to be root to run it.

> Currently I think that is Jeff Law, Jim Kingdon, Jason Molenda, and me.

And Marc Rovner.

The access to root is kept small due to the exposed nature of
sourceware--it is one of the few systems at Cygnus which is completely
'out there' network-wise, and too many people with access to root
would surely be asking for trouble.  Even well intentioned and
experienced people can make configuration mistakes which make the
system easier to compromise.

I've always worked hard to arrange the system so you never need
root access.  The only things that require root are creating new
CVS repos, creating new accounts, creating new mailing lists,
creating new web archives.  The new accounts are the most common
task here, and even that only comes up once every few weeks.

I haven't seen any common task that maintainers perform which
requires root access on sourceware.  If I'm mistaken, please let
me know -- let's see if we can fix that.

BTW I've always created new accounts within about a week, so even
this common procedure should not have been too onerous for maintainers
to go through me.

> Maybe accounts are cheap enough and safe enough that we could fully
> automate account creation.  

That's pretty safe.  I could hose parts of the system with just
cvs write access, but it requires some actual thinking and knowledge
of cvs, both of which are beyond the grasp of the most common
network threat, script kiddies.

Jason

Re: create-user

[Chris Faylor]

On Thu, Mar 02, 2000 at 08:32:04PM -0700, Tom Tromey wrote:
>Tonight I finished the create-user script.
>It automates the process of adding a (non-Cygnus) user to sourceware.
>It is kind of a pain to run -- too many arguments.
>Still, I find it less painful than doing it by hand.
>
>Ultimately we could have a user request web page which would generate
>scripts that an admin could run once the information was validated;
>these scripts would just run create-user.

Out of curiousity, who can run this script?  I assume that it needs root
access, right?  Or does it just submit a request to someone who will add
the account.  The last I heard root access was severely limited on
sourceware.

cgf

Re: create-user

[Tom Tromey]

Jim> I suppose this is also sort of the time to start muttering about
Jim> whether we want to just start using the Sourceforge code for at least
Jim> some of this.  Or if we want to maintain our own, whether we want to
Jim> make it a sourceware project complete with anoncvs, config files
Jim> separate from the code, &c.  It's all pretty much Tom's call, though,
Jim> in the sense that I haven't noticed anyone else having time for this.

It depends on how parameterizable the sourceforge code is, and how
different their policies are from ours.
I might be backing off on sourceware work again for a while.
There's lots of other stuff to do ...

Tom

create-user

[Tom Tromey]

Tonight I finished the create-user script.
It automates the process of adding a (non-Cygnus) user to sourceware.
It is kind of a pain to run -- too many arguments.
Still, I find it less painful than doing it by hand.

Ultimately we could have a user request web page which would generate
scripts that an admin could run once the information was validated;
these scripts would just run create-user.

Tom

Re: create-user

[Tom Tromey]

Chris> I don't know the best way to handle this.  We don't just give
Chris> people accounts without first getting some minimal personal
Chris> information first, right?  I guess that could be handled in a
Chris> web form.

Here is what we ask:

http://sourceware.cygnus.com/sourceware/procedures/new-developer-required.txt

We could definitely automate this more.
I probably won't have time to do this in the near future :-(
I could probably install something somebody else writes, though.

Tom

Restricting permission in 'src' repository (was Re: create-user)

[Jason Molenda]

On Sat, Mar 04, 2000 at 09:11:44AM +1100, Andrew Cagney wrote:

> As an aside, we're going to have to find a better mechanism for
> managing access to the /cvs/src repository.  This current blanket access
> (don't be naughty but more likely: oops, I screwed up) isn't going to
> scale in my opinion.

My original plan was that everyone with write access to any part of the
src repository would be in group 'src'.  The top-level/shared files which
were not really owned by any project would be group-src writable.  Each
subdirectory would be group-writable to only the appropriate group, so
e.g. mmalloc and sim would be group 'gdb' writable and bfd/binutils would
be group 'binutils' writable.

So Andrew Cagney, who is in the GDB group, would be in groups 'src' and
'gdb'.  He would not be able to write to the binutils directories or the
cygwin directories.

Before I made the src repo live, Geoff Keating pointed out a problem
with my plan:  If Andrew wants to have both a gdb and a binutils
repository checked out, or if he does a 'cvs update -d' at the
top-level, he's going to get permission denied errors.  (because
checking out a cvs directory involves putting a read lock in that
directory which requires write permissions).  People who want to
have both a gdb and a binutils checkout AND who don't have write
access to both trees would have to check one tree out with pserver
and one with ext.  Big mess all around.

Anoncvs only works around this problem by the 'readers' file in
the CVSROOT directory, but that file works on a global level, it
is useless for this particular problem.


One possible solution may lie in putting the cvs lock files in a 
separate directory hierarchy and loosening (e.g. 0777) the permissions
on those directories.  I don't think the cvs version we're running
(1.10) supports this, and I don't know the first thing about how
it works or how one maintains a consistent directory hierarchy in
both the cvs repository and the lock dir tree.

So, in 37 lines, that's the deal.

Jason

Re: Restricting permission in 'src' repository (was Re: create-user)

[Jason Molenda]

On Sat, Mar 04, 2000 at 08:00:03AM -0500, Frank Ch. Eigler wrote:

> Since the repository is version-controlled, I am not too worried about someone
> with excessive privileges accidentally making unapproved or naughty check-ins.

Yeah, that's the same conclusion I came to when I settled on a
single group for all the projects in /cvs/src.  My note was intended
mainly to outline the rationale of the decision and the difficulties
that will be encountered in trying to fix it.

> I would be more worried about (maliciously?) bypassing the version control
> system entirely by logging straight onto sourceware.  

Contributors have their SSH access restricted so they cannot log
in.  Cygnus people and project maintainers have full shell access.
(project maintainers need shell access to put things in the ftp
site, make snapshots, and update access to any GNATS database they
might have.)

There are a handful of cases where an external contributor has
shell access because their contribution requires it -- I grant that
on a case-by-case basis.  I doubt there are more than a half a
dozen people who are in this category.

Jason

Re: Restricting permission in 'src' repository (was Re: create-user)

[Tom Tromey]

Jason> Cygnus people and project maintainers have full shell access.

I have a couple questions:

- when we move a Cygnus person to the non-Cygnus part of /etc/passwd
(e.g., when Stan left) do we revoke their shell access?

- do we know that sysadmin will never grant a given user id twice?
That is, is Stan's number retired?

Tom

Re: create-user

[Tom Tromey]

Andrew> As an asside, we're going to have to find a better mechanism
Andrew> for managing access to the /cvs/src repository.  This current
Andrew> blanket access (don't be naughty but more likely: oops, I
Andrew> screwed up) isn't going to scale in my opinion.

Each group can do this themselves by hacking the scripts in their
CVSROOT.  If you do this, please try to make it tailorable so we can
use it for all the sourceware projects.

Tom

Re: create-user

[Tom Tromey]

Chris> Out of curiousity, who can run this script?

You have to be root to run it.
Currently I think that is Jeff Law, Jim Kingdon, Jason Molenda, and me.

Maybe accounts are cheap enough and safe enough that we could fully
automate account creation.  Then we'd just have to automate letting
project maintainers give write access to existing accounts.  I gather
this is what sourceforge does.

Tom

Re: create-user

[Jim Kingdon]

> Maybe accounts are cheap enough and safe enough that we could fully
> automate account creation.  Then we'd just have to automate letting
> project maintainers give write access to existing accounts.  I gather
> this is what sourceforge does.

Yes, I'd like to see this - web based like on sourceforge.  I'd
probably like to see an account need to have a project maintainer sign
off on an application before the new account gets any kind of access
to cvs/&c, though.  At least, that would plug various opportunities
for security holes (although Jason is probably right that other
threats are larger.  In particular keeping BIND, the OS, &c up to date
with the patches from http://www.redhat.com/errata or equivalent).

I suppose this is also sort of the time to start muttering about
whether we want to just start using the Sourceforge code for at least
some of this.  Or if we want to maintain our own, whether we want to
make it a sourceware project complete with anoncvs, config files
separate from the code, &c.  It's all pretty much Tom's call, though,
in the sense that I haven't noticed anyone else having time for this.

With all due respect, Jason, I don't consider "accounts created within
about a week" to be particularly fast.  Sourceforge has a 6 hour delay
for this and other tasks (because the action actually takes place from
cron), and that is annoying enough.

Re: Restricting permission in 'src' repository (was Re: create-user)

[Jim Kingdon]

> I would be more worried about (maliciously?) bypassing the version control
> system entirely by logging straight onto sourceware.  Would it make sense to
> restrict ordinary contributor accounts to only allow the cvs server to be
> spawned on a login?  (Use command="cvs" in .ssh/authorized_keys for example).

We already do this for most contributors.

It isn't foolproof, if you want that you need to start hacking on CVS
(to restrict "cvs tag", to restrict various holes which let
non-readonly users get a shell, &c).  Which might be a good thing, but
which isn't a problem for the overseers list.

Re: Restricting permission in 'src' repository (was Re: create-user)

[Chris Faylor]

On Sat, Mar 04, 2000 at 03:32:32PM -0800, Tom Tromey wrote:
>Jason> This has little to do with Stan's trustworthiness; it's a hedge
>Jason> against his personal system getting compromised and a bad person
>Jason> getting access to sourceware from there.
>
>I agree.
>I just used him as an example of somebody who recently left.

I don't know.  I think we should block Stan at the firewall, if
possible.  He's obviously dangerous.

I don't know what this "xconq" thing is but it sounds like he's
planning world domination through X-Windows or something.

cgf

:-)

Re: Restricting permission in 'src' repository (was Re: create-user)

[Frank Ch. Eigler]

Hi -

crash wrote:
> [unix groups not good enough for this]

Since the repository is version-controlled, I am not too worried about someone
with excessive privileges accidentally making unapproved or naughty check-ins.
These could be unrolled and the person's wings appropriately clipped.

I would be more worried about (maliciously?) bypassing the version control
system entirely by logging straight onto sourceware.  Would it make sense to
restrict ordinary contributor accounts to only allow the cvs server to be
spawned on a login?  (Use command="cvs" in .ssh/authorized_keys for example).

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4wQjPVZbdDOm/ZT0RAXl/AJ43ctnDbzn2P2KZJnfDZw0k/0Fp3ACfVtGV
HN4olDk0mWm8RTr3K2pduNI=
=L59N
-----END PGP SIGNATURE-----

Re: Access MGT; Was: create-user

[Tom Tromey]

>> Each group can do this themselves by hacking the scripts in their
>> CVSROOT.  If you do this, please try to make it tailorable so we can
>> use it for all the sourceware projects.

Andrew> Sory I'm lost.  /cvs/src isn't so much a group but many many groups.

I assume that if you share a cvsroot then you all communicate one way
or another.  Anyway you can all agree who gets write access to what,
and change the scripts in /cvs/src/CVSROOT to enforce the rules.

Tom

Access MGT; Was: create-user

[Andrew Cagney]

Excerpts from mail: 3-Mar-100 Re: create-user Tom Tromey@cygnus.com (446*)

> Each group can do this themselves by hacking the scripts in their
> CVSROOT.  If you do this, please try to make it tailorable so we can
> use it for all the sourceware projects.

Sory I'm lost.  /cvs/src isn't so much a group but many many groups.

	Andrew

Re: Restricting permission in 'src' repository (was Re: create-user)

[Jason Molenda]

On Sat, Mar 04, 2000 at 03:06:00PM -0800, Tom Tromey wrote:
> Jason> Cygnus people and project maintainers have full shell access.

> - when we move a Cygnus person to the non-Cygnus part of /etc/passwd
> (e.g., when Stan left) do we revoke their shell access?

Stan is the project maintainer for xconq, so he keeps his login
access.  If Stan were merely a contributor to gdb et al, then his
shell access would be revoked.

This has little to do with Stan's trustworthiness; it's a hedge
against his personal system getting compromised and a bad person
getting access to sourceware from there.

> - do we know that sysadmin will never grant a given user id twice?
> That is, is Stan's number retired?

Yes, they don't reuse uid numbers.

Jason

create-user

[Tom Tromey]

I just checked in a `create-user' script which is supposed to automate
the process of adding a (non-Cygnus) user.  It has not yet been
tested, so please don't use it right now.  I'll send more email (and
make the appropriate symlink in /usr/sourceware) when it is ready.

Tom