stupid security warning in 2003!

[cafe]

Thanks for the info.

TC

I have gotten past the warning by doing the following;

Open Access and set your security level to low. Answer the
the security warning as "YES" you want to block unsafe
expressions. You will see a msgBox telling you to restart
Access before the new level will take effect.

Close down Access then restart Access. The warning should
be gone and you should be able to open your database.

I can now open all my databases without any warnings at
all. However, I haven't deployed one with this setting
using the Access "Runtime" only to see if it works or not.

Bevnz

 

[Joan Wild]

However, if I includef the selfcert program in my installation process, I
would run it from within that process, and the user would not have to do
anything, right? Or, wrong? Because, if I >could< do that, then, an evil
guy could do the same with evil code?

Precisely TC. You can do this, but it really defeats the purpose.

A self-cert is one that has no Root Certification Authority. What value is
there in a certificate named 'cafe' that is shown as created by 'cafe'?

Anyone can create that certificate, sign a malicious database with it and
send it to your customers. Since it has no RCA they'd get a warning that
the certificate can't be trusted.

So anyone could impersonate you. Get a third party involved, and they
provide the RCA that is 'trusted'. When your customers get a signed mdb
from 'cafe' created by a trusted source, they get no warning, and have
confidence that it really did come from you.

 

[Guest]

i have encounter the same problem, i ve set the security level to low, the option shows up to open the macros or not but even if i said yes to open, all the wizards and reports are disable,
any thoughs there?

 

[TC]

Precisely TC. You can do this, but it really defeats the purpose.

A self-cert is one that has no Root Certification Authority. What value is
there in a certificate named 'cafe' that is shown as created by 'cafe'?

Anyone can create that certificate, sign a malicious database with it and
send it to your customers. Since it has no RCA they'd get a warning that
the certificate can't be trusted.

So anyone could impersonate you. Get a third party involved, and they
provide the RCA that is 'trusted'. When your customers get a signed mdb
from 'cafe' created by a trusted source, they get no warning, and have
confidence that it really did come from you.

Joan, I still don't understand. If running the selfcert program does >not<
remove the warnings, what is the point of running that program? And if
running it >does< remove those warnings, why couldn't my installation
program run it automatically (on the user's PC) when my application is
installed?

TC

 

[Joan Wild]

Joan, I still don't understand. If running the selfcert program does >not<
remove the warnings, what is the point of running that program? And if
running it >does< remove those warnings, why couldn't my installation
program run it automatically (on the user's PC) when my application is
installed?

My understanding is that a self-cert will remove the warnings (I'm not
positive, but I think you get a warning, which you can answer with 'always
trust this source' and then you won't get future warnings. i.e. you know
you created it and it is valid, so you accept it.)

But a client, who receives a database supposedly signed by you, but no Root
CA, that should raise some flags for them. 'This mdb is signed, but not
provided by a trusted source'. How do they know it really came from you?

 

[Joan Wild]

My understanding is that a self-cert will remove the warnings (I'm not
positive, but I think you get a warning, which you can answer with 'always
trust this source' and then you won't get future warnings. i.e. you know
you created it and it is valid, so you accept it.)

Actually, because the self-cert is created on your own computer, that
computer will trust it automatically.

But a client, who receives a database supposedly signed by you, but no Root
CA, that should raise some flags for them. 'This mdb is signed, but not
provided by a trusted source'. How do they know it really came from you?

More information can be found at

http://office.microsoft.com/assistance/preview.aspx?AssetID=HP052495551033&CTT=98

Also there is an Office Macro Security White Paper

http://www.microsoft.com/downloads/...1F-B313-44F4-8900-3399ABB2001D&displaylang=en

 

[Paul Overway]

The only "value" in using selfcert is to circumvent the warning on YOUR PC,
assuming you never intend to distribute the MDB. So, it is primarily
intended for developers. If you DO plan to distribute it, you would need to
buy a certificate to sign with, or you would have to ship uncompiled (no
MDE) and unsigned code....if you wanted to allow the end user to sign the
code themselves. But this not at all desireable for most developers.
Alternatively, if your company runs certificate server and the app is for
internal use only, you could use the company certificate from certificate
server and sign with that. But the certificate would still be untrusted
outside of your company.

Joan is correct you still get a warning with selfcert....the 1st time you
open the app. But after that, if you have indicated you trust the source
(which is you), you won't get the warning again. The warning is less scary
than the warning you get with no cert at all.

Alternatively, you could set macro security level to low via registry when
your app is installed. However, if the user or group policy sets it higher,
your users will get the scary messages again. Microsoft really made a mess
out of Access development with this.

 

[TC]

Thanks for those references, I will read them carefully over the next few
days.

TC

 

[TC]

Paul, Joan Wild has given me some references which I will read in the next
few days. Perhaps the answer to my remaining questions, will be in there.
But let me ask them now, in any case! These last questions should clarify
the issue for me.

Say developer 'A' ships an unsigned MDB to client 'X'. Say client 'X' has
the infrastructure neccesary to run the selfcert program on his own PC.

I think these are true - yes?

(1) If 'X' does not run selfcert on his own PC, he keeps getting nasty
warnings, unless he sets his macro security level to low.

(2) If 'X' does run selfcert on his PC:
- he still gets a warning next time he opens the MDB, but
- he gets an option to suppress those warnings;
- if he takes that option, he gets >no more< warnings (for that MDB),
ever;
- the warning suppression works even on the highest macro security level;
- running selfcert has caused that >one< application to become trusted on
that >one< PC.

These I'm not sure of:

(3) When the developer's installation program installs the MDB on the
client's PC, can that installation program run selfcert >on the client's
PC<, to cause that one MDB to be trusted on that one PC? (& thus, suppress
the warnings on the client's PC)

(4) What (if anything) changes above if the application is MDE instead of
MDB?

Sorry to keep pounding away on this!

TIA,
TC

 

[TC]

Ok, thanks for all that. Here is the point that I missed:

Running selfcert >generates a certificate< that can >then< be used on that
PC for signing code on that PC.

Running selfcert on a PC does not >in & of itself< sign anything.

Thanks again,
TC

 

[Paul Overway]

Answers below

--
Paul Overway
Logico Solutions, LLC
www.logico-solutions.com

Paul, Joan Wild has given me some references which I will read in the next
few days. Perhaps the answer to my remaining questions, will be in there.
But let me ask them now, in any case! These last questions should clarify
the issue for me.

Say developer 'A' ships an unsigned MDB to client 'X'. Say client 'X' has
the infrastructure neccesary to run the selfcert program on his own PC.

I think these are true - yes?

(1) If 'X' does not run selfcert on his own PC, he keeps getting nasty
warnings, unless he sets his macro security level to low.

True

(2) If 'X' does run selfcert on his PC:
- he still gets a warning next time he opens the MDB, but
- he gets an option to suppress those warnings;
- if he takes that option, he gets >no more< warnings (for that MDB),
ever;
- the warning suppression works even on the highest macro security level;
- running selfcert has caused that >one< application to become trusted on
that >one< PC.

These I'm not sure of:

To clarify...If X runs selfcert AND signs code for the MDB
- he still gets a warning next time he opens the MDB, but
- he gets an option to suppress those warnings;
- if he takes that option, he gets >no more< warnings (for ANY CODE
SIGNED WITH HIS SELFCERT GENERATED CERTIFICATE), ever;
- running selfcert AND SIGNING CODE WITH THE CERTIFICATE IT GENERATES has
caused that >one< VENDOR SPECIFIED WITHIN THE CERTIFICATE to become trusted
on that >one< PC.

It isn't the app that is trusted...it is the app vendor specified within the
certificate. The user could use the same certificate to sign code in Word,
Outlook, etc, etc.

(3) When the developer's installation program installs the MDB on the
client's PC, can that installation program run selfcert >on the client's
PC<, to cause that one MDB to be trusted on that one PC? (& thus, suppress
the warnings on the client's PC)

AFAIK...No...although I suggested to Mike Wachal that this was needed. My
build process is mostly automated, but now I'll have to manually sign 12
MDBs

(4) What (if anything) changes above if the application is MDE instead of
MDB?

The user does not have access to the source code, and therefore would not be
able to sign the code with any certificate