On Wed, Aug 6, 2014 at 4:29 PM, Matt Silverlock <[email protected]> wrote: > > > To understand correctly: if the server doing the backups is compromised, > it can't delete any older backups. My only concern is that it [the > compromised server running WAL-E] could still overwrite both WAL backups > and full backups (by issuing a PUT with a key matching an existing > object?). Can a PUT where a key already exists overwrite the existing data? >
I had the same concerns once and figured out that, unfortunately, the server having only "PUT" permissions can overwrite existing objects if it knows the key/filename. I set the system up before versioning lifecycle rules where introduced to S3, so to have some "compromised server delete safety", I ended up with doing pg_dump's besides wal-e, appending a random string to their filenames, and only giving the PUT permission to the server (no Get or List permissions). So that old backups have potentially unpredictable filename, and if the attacker even wanted to overwrite this file, he wouldn't know the exact filename. Of course this only works if no logging is present, and is probably pointless with the new lifecycle policy. > > > > On Thursday, August 7, 2014 9:01:12 AM UTC+10, Daniel Farina wrote: > >> On Wed, Aug 6, 2014 at 3:43 PM, Matt Silverlock <[email protected]> >> wrote: >> > Hi all, >> > >> > In the process of finishing up an application and as part of the last >> few >> > things prior to launch, I'm looking to firm up my IAM policies. I have >> an >> > unversioned S3 bucket that I'm planning to turn versioning on for and >> set a >> > lifecycle policy to delete old versions after a set period, and >> therefore >> > want to trim my IAM user permissions down to the set necessary for >> pushing >> > backups and deleting versions (only). >> > >> > Right now I have the following permissions for the group on the folder >> that >> > WAL-E pushes to: >> > >> > { >> > "Sid": "Stmt1390013977000", >> > "Effect": "Allow", >> > "Action": [ >> > "s3:GetBucketAcl", >> > "s3:GetBucketLocation", >> > "s3:GetBucketPolicy", >> > "s3:GetBucketRequestPayment", >> > "s3:GetBucketVersioning", >> > "s3:GetObject", >> > "s3:GetObjectAcl", >> > "s3:GetObjectVersion", >> > "s3:GetObjectVersionAcl", >> > "s3:DeleteObject", >> > "s3:DeleteObjectVersion", >> > "s3:AbortMultipartUpload", >> > "s3:ListBucket", >> > "s3:PutObject", >> > "s3:PutObjectAcl" >> > ], >> > "Resource": [ >> > "arn:aws:s3:::appname/backups/*" >> > ] >> > } >> >> I have dealt with IAM quite a bit for Heroku Postgres. >> >> See https://github.com/wal-e/wal-e/blob/8a012cadfd27d25fd53b8b595fc1a7 >> 9c9f149c68/tests/test_aws_sts.py >> (may be useful to use that to iterate on your policy) which calls >> https://github.com/wal-e/wal-e/blob/8a012cadfd27d25fd53b8b595fc1a7 >> 9c9f149c68/tests/s3_integration_help.py#L73-L103 >> >> In Heroku the deletes are processed somewhere else than the computer >> doing the archiving, so the delete privileges are conspicuously >> absent. It may be pragmatic for you to add them. >> >> Note the optional GetLocation: if one uses the non-preferred >> non-virtualhosted calling format (e.g. capitals in a bucket name or >> any other number of things) then this is important to give as a >> privilege so WAL-E can figure out what S3 endpoint to talk to. In >> such a case WAL-E falls back on US-Classic. >> >> > What is the list of policies that I need to trim it down to? I would >> assume >> > removing DeleteObject (and unnecessary stuff like >> GetBucketRequestPayment) >> > would be as far as it goes. >> > In the case where I need to pull an old version, how does WAL-E >> interact >> > with that? i.e. if the current version is deleted manually via wal-e >> delete >> > --confirm - how would I go about running a backup-fetch on older >> versions? >> > (is that even possible?) >> >> WAL-E is not S3 versioning aware in any way, and it seems not very >> useful to support that as the archival format is not reliant on >> overwrites: each key will nominally be written once. Delete is >> designed to be final. >> > -- > You received this message because you are subscribed to the Google Groups > "wal-e" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "wal-e" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
