-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregory,
On 2/12/16 6:46 PM, Dougherty, Gregory T., M.S. wrote: > Chris, > > > On 2/12/16, 5:27 PM, "Christopher Schultz" > <ch...@christopherschultz.net> wrote: > >> Gregory, >> >> On 2/12/16 4:19 PM, Dougherty, Gregory T., M.S. wrote: >>> On 2/12/16, 3:08 PM, "Leo Donahue" <donahu...@gmail.com> >>> wrote: >>> >>> >>>> On Feb 12, 2016 2:58 PM, "Dougherty, Gregory T., M.S." < >>>> dougherty.greg...@mayo.edu> wrote: >>> My definition of ³secure² includes ³there exist no files with >>> an unencrypted copy of the password². >> >> Do you mean "no files at all" or "no files in revision-control"? >> Again, you have to decide whether you trust your administrators. > > No files at all. > > Even if I did trust my administrators, they don’t want the task of > having to update the passwords every six months. > >>> How does the data source know that this web app, unlike every >>> other web app in existence, is allowed to access the data >>> source? >> >> The container allows you to map data sources to web applications. >> Use that facility. And trust your administrators. > > This sounds like something I can use to uniquely identify which app > is running, no? Can my code ask Tomcat for the DataSource the > container assigns to the web app, that instead of returning a > password, simply returns the name of the app? No, it will return a DataSource. What you do with it is up to you. Generally-speaking, a DataSource already knows the password that will be used to access the database. So the application doesn't need to have any passwords at all. >>> For that matter, how do I set up the data source (whose every >>> element is checked into the source code control system that a >>> malicious user may have access to) so that it knows the >>> passwords of interest? >> >> Why would you check the data source configuration into the >> revision-control system? It's not necessary to do that. Do you >> check Tomcat's server.xml into revision control? > > Are you going to have your data source configuration sitting on > only one user’s personal computer? What happens when that person > is on vacation? Sick? Has a hard drive crash? That configuration goes onto the server where you are deployed. If you have any kind of sane configuration-management system, you'll have that configuration locked-away somewhere safe that can be deployed (by admins only) to new deployed nodes whenever necessary. This has nothing to do with individual users. This has to do with configuration management. >> If you free yourself from the idea that everything needs to be in >> one big revision-control system, it makes things easier. >> Everybody does their job: the devs write the software, the admins >> deploy it. The admins have the keys to the kingdom (they always >> do; don't fight it) and the devs have keys to nothing. > > I don’t get a vote on that one. So you are tasked with: (a) Removing all plaintext passwords from configuration files (b) All configuration files must be in revision control (c) Developers manage the passwords to the production dbs (d) Admins must never see devs' passwords (e) The system must actually work Do I have that all correct? >> Of course, the devs are writing the software, so if you are >> truly paranoid, you need to make sure that the devs aren't >> stealing secrets from the admins when the app runs ;) > > I am truly paranoid, that’s why I want an unambiguous way to figure > out what app is running. That way the only data they can “steal” > is their own data. Use separate VMs (or JVMs) for each application. No question whatsoever which application is running. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbB7MsACgkQ9CaO5/Lv0PA1QwCfVtUZbXkR0RRRRYR4dZlVRQhz x4AAn2RPyD95VMsh7qk0RcWh2oCNh8I7 =VPNK -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
