gowrite.net

I use GW 2.1.24 and Vista Ultimate 32b.

As a quick test suggests, GW can be set to the Integrity Level Low if these directories (inherited) are set to Low as well:

<path>\Program Files\GoWrite2
<path>\Program Files\Java
<path>\Program Files\Common Files\Java

As a consequence, GW is like in a sandbox: It may not access any directories or files at level Medium or above, i.e. most of the user's private files!

However, JRE is used also by CGoban and CGoban does not (always) work at level Low because its registry access is to registry keys at level Medium or higher. Therefore using both GW and CGoban can be a problem if one wants to set JRE Low.

I have not tested though whether GW wants improper registry access (to registry keys at a too high level). Does it? If so, GW's registry keys should be put into a Low tree of the registry. There are such for Low software by default (but I don't recall their names now).

Java JRE does not document registry keys it uses in different situations. So as far as I know, only way to know accessed keys is to test it. gowrite code does not specifically address registry (there is no direct java API to do it), but JRE may access keys as part of some generic JRE functionality.

GOWrite.exe reads number of keys, but does not write any keys, so it should not be problem.

regards
Lauri

If GW is set to Low integrity level together with NoReadUp, then it may not read Medium registry keys. To achieve such a setting, I have started some testing; see other threads. I need more information though before I can try Low.

Running GW 2_2_21 at integrity level Low:

The solution is simpler than I feared. At least so far the following works, where \GoWriteDIr is the name of your GW directory and MyUserName is the name of your Windows user, it is a standard user, and you do it for every user with that you use GW:

*********************************************************************************************

Set to Low NoWriteUp:
C:\Users\MyUserName\gowrite.cfg

Set to ObjectInherited ContainedInherited Low NoWriteUp:
C:\Users\MyUserName\.gowrite
C:\Users\MyUserName\AppData\Local\Temp\hsperfdata_MyUserName

Set to ObjectInherited ContainedInherited Low NoWriteUp NoReadUp NoExecuteUp:
C:\Program Files\GoWriteDIr

*********************************************************************************************

Remarks:

- I am not sure if Low for hsperfdata is necessary, but I have the entire \Temp at Low anyway because my internet applications shall have it that way.
- GW and its inherited javaw.exe run as Low processes, although \MyJavaDir still has ObjectInherited ContainedInherited Medium NoWriteUp (notice the Medium level!).
- Working at least with basic tasks is possible with GW running as Low. Unless I will report differently some time, you should expect that it continues to work properly.
- Saving to C:\Users\MyUserName\.gowrite is possible.
- It is still unknown to me if saving to C:\Users\MyUserName\gowrite.cfg is possible. The last time of file change is from the GW's installation day.
- Copy the board or part of the board to the clipboard and paste it to a Medium program is possible. In my opinion, this is a security gap in the integrity level concept of Vista. Here it comes in for useful abuse...
- I have not waited for GW to kill its processes yet.
- Presumably, the same changes for integrity levels should be possible under Windows 7, except that I cannot predict the clipboard behaviour.
- CGoban (still at Medium) and OpenOffice (Medium) continue to work, although they also use Java. However, I never run GW and CGoban at the same time.
- Further information can be found on my webpage:
http://home.snafu.de/jasiek/vista_security_concept.html

Conclusion:

The GW program directory set to L NW NR NX and the temp directory, config files, and directory set to L NW is actually the common procedure for setting a program to Low if the program does not simply store its config files in the program directory and the user may not set a Low path of his own choice for the config files. The greatest part of my problem was to identify that GW does use config files at all and which their paths are... Clearly the current paths are very doubtful. The best would be an option in the preferences that allows the user to set a path for gowrite.cfg and gowrite22.cfg of his choice (and commands for export or import of preferences).

Question:

Oh, I wonder whether GW 2_2_X uses gowrite.cfg at all or whether that is a remainder of my previous GW 2_1_24 usage and was not deleted during its deinstallation? Otherwise, when afterwards does GW write to that file at all?

Your conclusions about working in low-integrity level sound reasonable.

For configuration files: In windows proper solution would be to put these into registry; In Windows architecture registry is intended extract for this kind of information. Moving settings to registry is in todo list, but nowhere near top of it.

C:\Users\MyUserName\gowrite.cfg is old setting file, and used only to initialize settings if new version does not find any recent setting file.

regards
Lauri

Actually, there are two standard ways in Windows to store settings. One is the default path, which depends on the Windows version. The other is the registry. However, the registry is actually something that applications should not use at all; it is nasty; saving settings from there is nasty. For Vista, the default path for INI-style settings is (I am not sure about the variable's speling)


%Users%\<MyUserName>\AppData\Roaming\<MyGowriteDirName>\

For local storage of, say, temporary files, there is also

%Users%\<MyUserName>\AppData\Local\<MyGowriteDirName>\

or (integrity level Low, but I do not recommend this because the user needs to decide whether he wants to run Gowrite as Medium or Low)

%Users%\<MyUserName>\AppData\LocalLow\<MyGowriteDirName>\

plus the default temporary folder for all applications

%Users%\<MyUserName>\AppData\Local\Temp


However, what I actually prefer applications to allow and provide is:
- set preferences directory of the user's choice (I might choose something like D:\INI\Gowrite\)
- export preferences
- import preferences
If all applications did this, then a fresh Windows installation would take only a few hours instead of several days. Also storing all applications' ini files in just one folder not containing anything else makes it very easy and fast to backup all those preference files.
For this to work, a link to the path must be specified in a default location. E.g., a file GowritePath.txt in %Users%\<MyUserName>\AppData\Roaming\<MyGowriteDirName>\ as the only file there with only one line of contents (in my case, D:\INI\Gowrite\) could do this.