How do I make sure an Excel session is "secure"?

It's possible that I'm not correctly stating my problem, because I've posted this question in a couple of other forums (fora?) with little success. However, I desperately need a solution to my problem, so here's my question:

How can I prevent a user from opening another workbook in an Excel session "from the outside"?

I'm fairly new to VB. I'm developing (in VB 2003) a simple but SECURE Excel environment which will allow a user to update a hidden Master_Records workbook. I need to keep the user's Excel session secure...for example, I've disabled all Excel Toolbars and Command Buttons, effectively preventing the user from doing anything except filling in some cell values and clicking on a few custom buttons in the worksheet. But how can I prevent the user from opening another workbook into the active session from his desktop and introducing some malicious code into the session via that route?

One respondent in another forum (the only one, in fact) suggested that I look into "instantiating workbook level events" so that I can detect when other workbooks are open. I'm not sure what that means, is there someone here who could give me some guidance into that solution?

Thanks in advance,
Mark

Originally Posted by shg

If you're looking for a secure environment, Excel isn't it.

You can do various things to limit casual users' ability to disturb your workbook, but nothing to stop a malicious attack by a knowledgeable user. If you're writing code that changes peoples' environments, you should already know this. That's a good way to have people come looking for you in the night with pitchforks.

Wow.

Okay, let me clarify a few things.

First, I'm not "changing peoples' environments", at least not in any manner that you may be imagining. The package I'm developing is a small standalone utility intended strictly for internal use in a few departments where I work. The typical user only has limited experience with Excel in any case, and will only need to use the utility perhaps twice a week, and typically only for a few minutes time at each use. I don't really care what a user may have been doing in the moments before he invokes my utility, and I don't care what he does afterwards. But the rules for using my utility are as follows: Before he opens the utility, he must first close any open workbooks in his Excel session (if he has a session open), and he's not allowed to open any other Excel workbooks while he has my utility open. In other words, all other Excel activities he may have been involved with must be "set aside" for the few minutes' duration that he will be spending in my utility.

When he's finished with his work in my utility, he presses a "Done" button and I do a graceful exit, putting everything in the user's session back just like it used to be. Can't get much simpler.

All of the people who will be using the package have been made aware of the above-stated rules, and no one has any problems with those rules. I'm training everyone in the use of the package, and have taken considerable pains to make the user interface simple, straightforward and intiutive. As I said, the typical user of this thing isn't very Excel savvy.

However, there are always a few people who can't be trusted with leaving any supposedly "secure" system alone. It's those people I'm trying to protect the package from their efforts to "break and enter".

When the user invokes the utility, there's code that checks for any other open workbooks, and the package won't continue unless it sees that the session is "clean". That way the user can't have any code lurking in a corner. Like I said earlier, I've disabled all the toolbars and command buttons, so he can't add in any code after he opens my utility. So far, so good.

The only "option" a mal-intent has left, then, is the ability to insert a file into the session by double-clicking on a file from his desktop (which royUK never quite get his head around). That's what I'm trying to prevent. That's what I was asking you guys how to protect against.

If you don't have an answer to my question, I can live with that. But when I asked for help, all I got was a comeback about "people com[ing] looking for you in the night with pitchforks" (which IMO was unwarranted, and which meaning is completely lost on me, but that might be just because I don't think like you do).

If you haven't noticed, I've been trying hard to just put this all behind us and move on, but to answer your points...

Originally Posted by Simon Lloyd

shg was just being jovial & lighthearted, it wasn't an attack on you!

Then where were all the smileys?

Originally Posted by Simon Lloyd

...as for the advice given by both moderators it is sound and was their opinion on you're proposal...

I was already aware of the issues with weak security in Excel, and was trying my best to work around them. That's the job I was given by my boss. I wasn't asking for anyone's opinions on the percieved futility of my assigned task...I was asking for their help, and got none.

Originally Posted by Simon Lloyd

...your perception of emotive text is always read with your particular frame of mind or emotion at the time (i tell my kids that when sending sms or replying to them )

When I read shg's reply, my frame of mind was nowhere except on my work. I'm not normally one to read a fight into any particular situation. But after I made the effort to state my question as clearly and concisely as I could to this sizable and knowledgeable body of experts, with great hopes of reaping the accumulated wisdom of the sages, upon reading shg's remark regarding my alleged attempts to "change peoples' environments", and his chastising me for stuff I "should already know", and his (now-famous) admonishment about folks "com[ing] looking for you in the night with pitchforks", well, I hope you can understand if I was left feeling just a little blindsided. Again...where were the smileys?

Now...all that being said, let me repeat my earlier statement that I'd really like to just forget about all that and get on with what we're all here for, which is the furtherance of knowledge about how to make Excel work for us all.

Originally Posted by Simon Lloyd

If you require your "utility" to be that much safer why not look in to making it an exe file, there are utilities that do this.

That's a good idea, and would probably guarantee that a malicious user would never see the code. However, as I stated in my OP, there is a hidden Master_Records workbook which at some point I open, update, then re-close. I don't want any of the users to ever become aware of the existence of that workbook, let alone learn the name of it! That, as much as anything else, is the reason why I'm trying to prevent anyone from having an opportunity to get any "hook" into the session, and possibly getting wind of filenames that I'm opening behind the scenes. That hidden Master_Records workbook is the book I'm really trying to protect.

I'm aware that I'm probably fighting a losing battle as far as ever being able to absolutely prohibit anyone from surreptitiously getting into the Excel session, but I can present a big "Do not attempt to circumvent the security measures" notice to the user at sign-in, and if he does succeed in breaking in I can at least recognize that he's in (with WorkbookDeactivate), and present a big message on his screen that he's been caught, and get a handle on the filename he used to break in with, and present that info to our IT group. Because if he's gotten that far, he's obviously up to no good, and the IT security folks and corporate lawsters can take it from there.

So in the final analysis, maybe I can't keep a saboteur from getting in, but I can at least catch him in the act!

Kind regards to all,
Mark

Sorry for the late reply, I've not had access to a machine for more than a few minutes at a time for the last couple of days.

Thanks to all for the replies. As I stated in my OP, I'm fairly new to this VB thing, and I wasn't aware that Excel was such an inherently non-secure environment.

I want to particularly thank shg for the multiple items of advice he offered -- I'm incorporating them all! The IgnoreRemoteRequests does indeed force another session to open if the user double-clicks on a workbook (is that what the other forum user meant by "instantiation"?).

The only remaining "chink in the armor" I can discern at this point is the user's ability to drag another workbook into the window. Shg's suggestion regarding the Workbook Deactivate event is useful, but unfortunately it only enables me to detect that another workbook has been opened AFTER that workbook's Workbook_Open or Auto_Open procedures have already executed, so a really malicious user could have concievably already caused some damage. What I'm working on now is a procedure that will automatically and privately notify me of such illicit activity, preferably by email. However, sending an email via a macro from the user's machine through Outlook will open a warning message on his screen, and I don't want that to occur, and it seems there's no way to prevent that. So maybe SMTP or MAPI is the way to go, but that doesn't appear to be too easy, either. We do have IM on all the machines at work, so perhaps that's an option, but I've never used it so I'm clueless about that, too.

Any suggestions, anyone?

Thanks again,
Mark

DonkeyOte, thanks for that link. I'll try that stuff out as soon as I get back to the office, and see if it works there.

Originally Posted by shg

Look at the AutomationSecurity property.

Thanks shg, but I've already tried that, and it's not effective against the Workbook_Open procedure in a workbook that's been dragged-and-dropped into the session.