"Craig R. McClanahan" wrote:
>
> Not a problem ... it's just that I think you're being a little narrowly
> focused on the solution to *your* problem, and ignoring the bigger picture
> :-).
I suppose that's fair to a certain extent. I do see cert protection as a
little more critical than many of the other resources, but I agree that
it's just one man's opinion.
> Protecting your certificates is all well and good, and I have no objection to that.
>It's necessary, but it's not sufficient.
Agreed.
> To flesh out my example, to use features like container-managed security,
> you need to tell Tomcat how to gain access to its "repository" of
> usernames, passwords, and role information. Most users will do this
> either in a database or a directory server, which means that a
> configuration file read by Tomcat must contain the appropriate database
> (or directory server) username and password.
Again, I think my goal lies along the same path as the broader goal.
Authentication is needed, it's just a matter of implementation.
> What I'm saying is that I don't care much about your certificates if I can
> snoop the database connection information and go hack your passwords
> database. So protecting just the certificates is insufficient to solve
> the entire problem you are raising.
True.
> How many challenges for different pieces of sensitive information are you
> willing to impose on the system administrator? And, is that really any
> more secure (in that the sysadmin is now going to have *all* the answers
> to these questions on a little sticky note someplace, instead of
> memorizing the one password needed to start the server as root :-)?
I guess my eventual vision is something along the lines of a master
"Tomcat Config" password. This would be used to protect ALL sensitive
resource information. It could be something as simply as encrypting all
of this information in a single file in "conf" by deriving a symmetric
key from the supplied passphrase. Any admin which turns on this feature
would need to be prompted at startup in order to load any resources,
such as SSL, which are needed at startup. Anything which can be
configured on-the-fly while the server is running could be administered
from the admin context perhaps. The user would be challenged again every
time he/she wanted to access this page, but we're still talking the same
"Master Tomcat" password. And since we probably want to run this page in
SSL, we will need the password at startup anyway :-)
My point is that the prompt code will be necessary anyway, so why not
let me use it to grab the keystore password (if appropriate) until the
more comprehensive solution can be put in place? Again, I consider SSL
the weak link, so that would at least get us some level of protection
right away, and most of the code will be needed eventually anyway?
Again, all of this will be optional so that the non-security-sensitive
environents won't be forced to do any of this.
So does my general idea make sense? And also, does my SSL stopgap sound
reasonable, or am I being a little selfish here (it wouldn't be the
first time ;-)?
- Christopher
