SSM question about embedding switch in Word converter

Windows XP-SP3, SSM-2.4.0.622
I use Word from Office2003 aka Office 11
Microsoft, long ago, gave us compatibility pack, Office 12, which allows to use files such as .docx where they get converted to .doc.
I suspect something similar will be for Excel so I'd like to understand how to handle this sort of thing in SSM.

Today I got a .docx file and needed to handle it.
With SSM disconnected UI, conversion in Word couldn't start, no surprise - see screenshot, read up.


From the blocked line in the log I made a quickie rule to Allow.
Just svchost is a parent to the converter, not Word, nothing else.
I can get rid of the rule, connect ui and maybe go from there. Not sure which other settings to use though.
I don't think I want any old embedding to be allowed.
Also, is this an example of interprocess activity?

Always learning even when I think it's all stable.
Suggestions?

 

As I see it from you picture you got command line parameter in your allow rule. I checked it out and it is a standard parameter in Office: http://office.microsoft.com/en-us/outlook-help/command-line-switches-HP001003110.aspx. I don't understand what exactly is your problem. If command line is a problem you can edit the rule and delete it. I don't remember how SSM handles executions with command line, it's been ages since I used it. If -embedding parameter is necessary, you will get popup when opening docx file. Of course you'll have to connect UI.

hqsec

 

When UI is connected, the alert would ask if to make a rule for this application and this specific command.
But when UI was disconnected, rule maker from the log had no option for command line check, so less convenient.
My bigger problem, I think, is the idea of embedding. What else would be embeding? Do I want it in general?
I'm mostly trying to understand this sort of thing and how to make workflow reasonably easy.
And I thought Word would trigger the converter and not svchost.

 

Yes creating rules post festum can be more inconvenient than creating it in real time. You can't change the way wordconv.exe is launched, you can only create appropriate SSM rules. If SSM is "switch sensitive" than you will have to make rule that will have this switch in parameters. Otherwise you can remove the parameters from rule. Here is MS' description of this switch:

I don't know f there are any security problems if you enable launch of wordconv.exe with this switch.

hqsec

 

I don't have Office available so I can't address it directly. A question. Does the log entry above display the entire command line parameter? If the command line parameter doesn't change or contain the name of the document, you could make a permanent rule allowing wordconv.exe to be launched only by svchost. Set both the default parent and child permissions to ask for both svchost and wordconv.exe. The check command line parameter option applies to the parent process, svchost in this case.

 

Yes. This is the entire command. No document name.
I did repeat the process with UI connected. It was identical. I allowed for this command to run by svchost and embedding allowed.

You suggest to keep it as "Ask" ?
I was surprised that there is/was no log entry for Word starting this converter or Word starting svchost, so if you have any thoughts to enlighten me with, I'd appreciate it.
Is there anything else, maybe in special permissions, I should do?

Rare events trip me. I keep coming back to SSM every few months for a month or two and still don't trust myself to use it safely

 

I was referring to the default parent and child settings, listed under advanced properties for the specific rules for each process. Setting these to ask will require SSM to prompt you if either tries to launch anything else. The check command line parameter is under special permissions for each rule. Enabling this option allows or blocks the child process when the specific command parameters and/or switches are included. You can allow the child process only when it's launched with a specific parameter, block specific parameters, or any combination of these.

You might also want to check the special permissions and advanced settings for the groups that contain the rules for both processes. If you don't specify differently for each rule, SSM will use the settings from the groups containing those rules. The documentation regarding special permissions leaves a lot to be desired. When changing these to settings that differ from those of the group containing the rule, make sure that the choice displays as red or green, not grey.

Regarding the logging, there are 3 places where the settings affect what gets logged. The first is under the options tab under logging. If I recall right, these are global and have to be enabled before the other settings will apply. Beyond the global settings, there's logging options under special permissions for both the groups and the individual rules in them. If application starting is not checked under options, the setting for the group and individual rules does nothing. If you enable most of the logging features, you might want to keep the time period short or the logs will get huge.