Re: RFC: Securing maintainer uploads to

On Thu, Nov 10, 2011 at 03:19:07PM +0000, Maciej Marcin Piechotka wrote:
> On Thu, 2011-11-10 at 12:47 +0100, Olav Vitters wrote:
> > My thoughts to secure this is:
> > 1. Get rid of shell for ideally everyone (maintainers, release team,
> > etc)
> > 2. Uploads are done using:
> >    a. rsync over ssh using rrsync; this restricts what you can upload
> >    b. something like: ssh install-module
> >    c. the install-module command looks at what you uploaded and then
> >    calls ftpadmin on it
> >    Problem:
> >    a. rsync might be annoying / unreliable
> >    b. don't think you can delete easily with rsync
> >    c. more annoying than e.g. sftp or scp
> >    Benefit:
> >    a. rsync over ssh is easy to secure
> I may be wrong but IIRC ssh can be configured to allow only scp
> connections. Maybe solution would be (instead of rsync):
>  - Allow scp
>  - Allow install-module as default (and only) login shell

scp is shell commands, only sftp has a bit more of a protocol. But I
don't want people to be able to modify anything than uploading a
tarball (e.g. ~/.bash*). Intention is just allowing exactly what is

> > 3. Access is determined using "doap" files
> Hmm. Isn't access to git open to everyone who have key? The malicious
> attacker who compromise account one of 350+ user may alter the doap file
> (I guess it would be much easier to miss then say unexpected release
> which is followed by public e-mail).

ftpadmin informs all existing maintainers when a tarball is uploaded.
I'm intending to inform all existing + new maintainers on any changes
to the doap file. I could (but don't want) to restrict doap file updates
solely to people already marked in the doap file.

If is compromised, the attacker could pretend
everything is fine. If it instead follows the process I think is secure
enough, then it just is our policy that is wrong.

Reason I choose for lax is same reason any gnome git account can modify
any repository: eases development imo.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]