I must point out that in Vista (with UAC enabled), many executables are installed with a "high integrity" flag in their ACL (things installed with Administrator tokens granted to Windows Installer, for example). This means that only things that are running at high integrity (usually installers) are allowed to change them, and all other attempts are denied write access.
It is thus not necessarily true that someone who gains unauthorized access to someone's files (via some code injection attack) is going to have the high-integrity privilege necessary to directly modify the program binary, and thus the 'obviously ignorable' direct modification attack of the certificate database can no longer be ignored. I move that this issue be reevaluated in light of this knowledge. -Kyle H On Feb 8, 2008 3:30 AM, David Stutzman <[EMAIL PROTECTED]> wrote: > D3|\||\|!$ wrote: > > I never said so... Infact, I had wanted to implement something similar > > to the browser's security mechanism and had asked for links providing > > details about the certificate management architecture.... > > I'm a little confused. You keep saying you want the browser's security > but I'm assuming you don't realize the Mozilla browsers all use NSS for > their crypto and key/cert storage and leave (in your words) "the > cert8.db, secmod.db, and key3.db accessible to all & sundry." > > The only protection those files have on most systems, besides the > password to access the key db, is they are in the browser's profile > folder which is typically under a user's homedir and only accessible to > the user and any administrative/root users. > > Dave > > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
