Moving repos to nymeria
 

On 06.09.2012 17:23, Stéphane Gaudreault wrote:
> Could we run sogrep on nymeria ?

I don't really see a benefit there. You can already run it on brynhild
and sogrep needs a databases which is updated via a cron job so you
probably won't even see a difference in update latency between the two.

> Also, could you please explain why browsing the repo in a shell account
> will be disabled ? I found this very useful when moving a large number
> of packages from staging/testing to extra/core.

The idea is to reduce the possible damage an attacker can cause if he
happens to obtain a dev's/TU's ssh key. Without a shell and only a few
whitelisted commands the box should be very safe. That allows us to use
a server stored signing key for the database without having to worry
about someone using a kernel exploit and gaining access to the key.

sftp will still be available so if all you want is a file list you can
use that. You can also run "sudo syncrepo" on brynhild to force a sync
at any time and then browse there.

--
Florian Pritz

Moving repos to nymeria
 

[2012-09-06 17:39:03 +0200] Florian Pritz:
> The idea is to reduce the possible damage an attacker can cause if he
> happens to obtain a dev's/TU's ssh key. Without a shell and only a few
> whitelisted commands the box should be very safe. That allows us to use
> a server stored signing key for the database without having to worry
> about someone using a kernel exploit and gaining access to the key.

Did we abandon the idea of having packagers download the old DB, check
its signature, do changes to it, sign the new DB, and upload it back?
Because I would certainly find this much safer and trustworthy than
having a black-box server blindly signs anything it is given.

And I would also find it too bad to lose the flexibility actual non-root
Linux accounts give, such as being able to fix things ourselves when
they go wrong (like when pushing to the wrong repo).

Cheers.

--
Gaetan

Moving repos to nymeria
 

On Thu, Sep 6, 2012 at 12:46 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
> [2012-09-06 17:39:03 +0200] Florian Pritz:
>> The idea is to reduce the possible damage an attacker can cause if he
>> happens to obtain a dev's/TU's ssh key. Without a shell and only a few
>> whitelisted commands the box should be very safe. That allows us to use
>> a server stored signing key for the database without having to worry
>> about someone using a kernel exploit and gaining access to the key.
>
> Did we abandon the idea of having packagers download the old DB, check
> its signature, do changes to it, sign the new DB, and upload it back?
> Because I would certainly find this much safer and trustworthy than
> having a black-box server blindly signs anything it is given.


Agree.

>
> And I would also find it too bad to lose the flexibility actual non-root
> Linux accounts give, such as being able to fix things ourselves when
> they go wrong (like when pushing to the wrong repo).

What will happen to our personal web space? And what about
/srv/ftp/other/ ? Will they move to the new server? If so, we'll need
to whitelist enough commands so we can use them without being a PITA.
Could you give us a more detailed list of the commands that will be
allowed? I'm concerned that the shell would become so crippled that
it would be practically unusable.

Eric


>
> Cheers.
>
> --
> Gaetan

Moving repos to nymeria
 

On 06.09.2012 19:18, Eric Bélanger wrote:
> On Thu, Sep 6, 2012 at 12:46 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
>> [2012-09-06 17:39:03 +0200] Florian Pritz:
>>> The idea is to reduce the possible damage an attacker can cause if he
>>> happens to obtain a dev's/TU's ssh key. Without a shell and only a few
>>> whitelisted commands the box should be very safe. That allows us to use
>>> a server stored signing key for the database without having to worry
>>> about someone using a kernel exploit and gaining access to the key.
>>
>> Did we abandon the idea of having packagers download the old DB, check
>> its signature, do changes to it, sign the new DB, and upload it back?
>> Because I would certainly find this much safer and trustworthy than
>> having a black-box server blindly signs anything it is given.
>
>
> Agree.
>
>>
>> And I would also find it too bad to lose the flexibility actual non-root
>> Linux accounts give, such as being able to fix things ourselves when
>> they go wrong (like when pushing to the wrong repo).

Pierre said that we should support using devtools inside screen (db-move
can take quite long) and screen allows to run other commands so limiting
the shells doesn't seem possible right now.

Limiting the shell creates a trusted server which makes signing the
databases way more secure because even if we use remote signing the hash
is calculated on the server.

I understand either way and I don't care if we limit them or not so I'm
not going to argue about that.

--
Florian Pritz

Moving repos to nymeria
 

Am 15.09.2012 23:24, schrieb Florian Pritz:
> Pierre said that we should support using devtools inside screen (db-move
> can take quite long) and screen allows to run other commands so limiting
> the shells doesn't seem possible right now.

It's dbscripts actually. As packages are signed an attacker cannot
inject any code. We should isolate svn though. A shell account with
limited permissions (no direct write access to the repos or svn) should
be secure enough then.

Maybe one day we will reimplement the whole process; but this wont be
done anytime soon.

> Limiting the shell creates a trusted server which makes signing the
> databases way more secure because even if we use remote signing the hash
> is calculated on the server.

We do not sign databases anyway atm. And imho we shouldn't do it until
it's possible to tell pacman to trust certain keys only for the
database. Then the worst case would be a replay attack which we would
detect. Using our packager keys to sign something that is calculated on
the server is a bad idea. The server cannot be trusted and our setup
should be based on that fact.

But this might go off-topic. Right now we don't sign databases and we
don't have a finished concept for this. So I'd say keep this in mind but
let us not limit by this.

Back to the actual topic: the community repo should be moved from
sigurd as we are running out of disk space. It is also benifitial to
have the dev and tu repos on the same server. Therefor an easy solution
would be:

* have shell accounts for every dev and tu
* maybe review our group setup
* package files and svn files cannot be accessed by these accounts. Use
some sudo and dedicated user magic here so that only dbscripts can write
packages and the svn repo can only be access via an svn client.

We can ave a more advanced setup later.

Greetings,

Pierre

--
Pierre Schmitz, https://pierre-schmitz.com

Moving repos to nymeria
 

[2012-09-15 23:24:57 +0200] Florian Pritz:
> >> Did we abandon the idea of having packagers download the old DB, check
> >> its signature, do changes to it, sign the new DB, and upload it back?
> >> Because I would certainly find this much safer and trustworthy than
> >> having a black-box server blindly signs anything it is given.
>
> Limiting the shell creates a trusted server which makes signing the
> databases way more secure because even if we use remote signing the hash
> is calculated on the server.

Do we really need remote signing for the DB, given that each of us
already downloads the DB when upgrading, most likely several times a
day? I do not think downloading it a couple more times when pushing
packages will change much. Then I see no need to trust the server: I
download the current DB and its signature, check it (it's by Florian P,
and of course I trust him), apply my changes, sign and upload back.

--
Gaetan

Moving repos to nymeria
 

On 16/09/12 15:59, Gaetan Bisson wrote:
> (it's by Florian P,
> and of course I trust him)

Where there goes the point of failure right there!

Remember there is also the files.db which is ~10x the size. I guess we
should sign that too?

Allan

Moving repos to nymeria
 

On Sun, Sep 16, 2012 at 7:59 AM, Gaetan Bisson <bisson@archlinux.org> wrote:
> Do we really need remote signing for the DB, given that each of us
> already downloads the DB when upgrading, most likely several times a
> day? I do not think downloading it a couple more times when pushing
> packages will change much. Then I see no need to trust the server: I
> download the current DB and its signature, check it (it's by Florian P,
> and of course I trust him), apply my changes, sign and upload back.

I want avoid anything that requires me to upload the DB from my computer.
Reason: http://www.speedtest.net/result/2173792066.png
That would be over 7MB I would have to download and upload for every
operation on the [extra] repo.

Moving repos to nymeria
 

Am 16.09.2012 08:34, schrieb Jan Steffens:
> On Sun, Sep 16, 2012 at 7:59 AM, Gaetan Bisson <bisson@archlinux.org> wrote:
>> Do we really need remote signing for the DB, given that each of us
>> already downloads the DB when upgrading, most likely several times a
>> day? I do not think downloading it a couple more times when pushing
>> packages will change much. Then I see no need to trust the server: I
>> download the current DB and its signature, check it (it's by Florian P,
>> and of course I trust him), apply my changes, sign and upload back.
>
> I want avoid anything that requires me to upload the DB from my computer.
> Reason: http://www.speedtest.net/result/2173792066.png
> That would be over 7MB I would have to download and upload for every
> operation on the [extra] repo.

Exactly, this is not an option. Also remember that we need to lock the
db during that time so nobody else can modify it. Transactions are also
way harder to handle; what if the upload fails etc.. Si imho both,
remote signing and re-uploading the db files are a no go.

Greetings,

Pierre

--
Pierre Schmitz, https://pierre-schmitz.com

Moving repos to nymeria
 

> Am 16.09.2012 08:34, schrieb Jan Steffens:
>> I want avoid anything that requires me to upload the DB from my computer.

[...]

>> That would be over 7MB I would have to download and upload

Would we really need to sign the full 7MB database? Could we not come
up with something more minimal to sign that would still be sufficient?
Alternatively, we need to get Jan a better connection :)

On Sun, Sep 16, 2012 at 9:47 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
> Exactly, this is not an option. Also remember that we need to lock the
> db during that time so nobody else can modify it. Transactions are also
> way harder to handle; what if the upload fails etc...

We don't need to lock the database for the duration of the
download/sign/upload. We could simply:

* check the timestamp of the old database
* download the database
* check the old signature
* update the database and sign the new version
* upload the database
* lock the database on the server
* check if the timestamp has changed
* if yes, release the lock and start from scratch
* if no, overwrite it with your new version and release the lock

This means that you might need to retry once or twice if more than one
person is updating the database, so it does not scale that well.
However, we are not that many people and we don't update the database
that often, so the chance of actually getting a conflict is low (and
the additional cost is not that high either).

-t