Re: Installing PostgreSQL as "postgress" versus "root" Debate! - Mailing list pgsql-admin
From | Uwe C. Schroeder |
---|---|
Subject | Re: Installing PostgreSQL as "postgress" versus "root" Debate! |
Date | |
Msg-id | 200501131313.39366.uwe@oss4u.com Whole thread Raw |
In response to | Re: Installing PostgreSQL as "postgress" versus "root" Debate! ("Goulet, Dick" <DGoulet@vicr.com>) |
Responses |
Re: Installing PostgreSQL as "postgress" versus "root"
Re: Installing PostgreSQL as "postgress" versus "root" Debate! |
List | pgsql-admin |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 13 January 2005 10:52 am, Goulet, Dick wrote: > Doug, > > OK, Assume that the binaries are installed under root, but a > hacker cracks PostGres, what is to stop him/her from trashing all of the > database files in the first place? Their not owned by root. Installing > malware, whether it's actual code or destroying/defacing files causes > similar if not identical problems. At least their restricted to the > postgres user. And in my book the executables are of zero value whereas > the data files, and their contained data, are of infinite value. So > under your scheme we're protecting the least valuable part of the > system at the expense of the most valuable. So where is the difference? If all executables AND the data is under the postgres account - an intruder hacking the postgres account would still be able to destroy your data. BTW: most commercial software needs root access to be installed - and be it just to create the user accounts. It doesn't really matter who owns the executables - if the account owning the files is hacked you're screwed anyways. When it comes to protecting the data which is the most important thing after all, replication and backup are your friends. For my larger customers I'm running replication to two offsite servers (one east-coast, one texas, just to make sure they're fine when the next earthquake hits) and I do backups every 8 hours - which are written to a tape and distributed to another set of offsite servers using rdist. So whatever happens the max they could ever possibly lose is 8 hours, except there is a full blown nuclear attack on the whole US - in which case nobody would care about the data anyways. > > > Dick Goulet > Senior Oracle DBA > Oracle Certified 8i DBA > -----Original Message----- > From: Doug Quale [mailto:quale1@charter.net] > Sent: Thursday, January 13, 2005 11:56 AM > To: PostgreSQL Admin > Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root" > Debate! > > "Goulet, Dick" <DGoulet@vicr.com> writes: > > to Postgres install as well. I as the DBA should be able to install, > > upgrade, etc the software without access to the root account. Simply > > put the fewer people who know the root password the fewer who can > > destroy the system and the fewer who have to be told when the password > > changes. And the fewer people who know anything, the more secure it > > is. > > This analysis is incomplete. Under this scheme, if someone cracks > your account they can install trojaned or malicious executables owned > by you without cracking root. The flaw is in believing that this > scheme requires an intruder to crack two accounts to defeat your > security. In fact, you have doubled the number of targets but left > the amount of work required of the bad guys to compromise your system > the same (crack one account). > > Put all your eggs in one basket, and WATCH THAT BASKET. > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly - -- UC - -- Open Source Solutions 4U, LLC 2570 Fleetwood Drive Phone: +1 650 872 2425 San Bruno, CA 94066 Cell: +1 650 302 2405 United States Fax: +1 650 872 2417 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD4DBQFB5uSDjqGXBvRToM4RArMsAJixOHW5IxkLV2Pj838052uQh3oEAJ4oEeUZ 4v+Vdsvv905fMRhA81yQqg== =P0Py -----END PGP SIGNATURE-----
pgsql-admin by date: