Windows architecture

Adobe Reader X on Windows XP

ちゃっぴ (tyappi@wankuma.com) — Sun, 21 Nov 2010 18:53:00 GMT

Windows XP 上での Adobe Reader X はどのように access token を制限しているか実際に確認してみましょう。

Process tree の構造は Windows 7 と変わりませんね。では access token はどうなっているか？まずは親の方。

Administrators に所属する user での結果ですが、全く filter されていません。つまり、この process の実行 account が有する権利が制限なく利用可能です。この process で動く code に脆弱性が存在した場合、死亡決定ですね。

次に子 process。

かなり厳しく filter されていますね。Filter された token がどのように機能するかについては Restricting SID を参照していただくとして、結論としては下表のような token になります。

SIDｓ	Enable
Logon SID (S-1-5-5-0-71174)	Disabled
Everyone	Enabled
Local	Disabled
NT AUTHORITY\Authenticated Users	Disabled
NT AUTHORITY\REMOTE INTERACTIVE LOGON	Disabled
VIRTUALXP-17110\Debugger Users	Disabled
VIRTUALXP-17110\なし	Disabled
BUILTIN\Users	Enabled
NT AUTHORITY\INTERACTIVE	Disabled
BUILTIN\Administrators	Disabled
VIRTUALXP-17110\XPMUser	Disabled

要するに Everyone と BUILTIN\Users のみが有効な SID ということですね。

つまり、対象 rewouces の ACL で Everyone および BUILTIN\Users に対する許可の権利が与えられていないと access できないということです。

Windows XP の既定の ACL で Everyone および BUILTIN\Users が access 可能な resources の概要を下記に示します。

Type	Path	Rights
File/Folder	Drive root C:\ 等	Read & Create New
File/Folder	%SystemRoot%	Read only
File/Folder	%ProgramFiles%	Read only
File/Folder	%UserProfile%	None
File/Folder	All Users Profile Ｃ:\Documents and Settings\All Users\	Read only
File/Folder	All Users Application Data Ｃ:\Documents and Settings\All Users\Application Data	Read & Create new
File/Folder	共有ドキュメントＣ:\Documents and Settings\All Users\Documents	Read & Create new
Registry	HKCR	Read only
Registry	HKLM	Read only
Registry	HKCU	Read only

%UserProfile% への権限は制限されているものの drive root に独自に作成した folder や共有ドキュメントに置いた file 等は保護されないことになります。また、ACL を変更して Everyone や BUILTIN\Users を付け加えるなんてこともよく行われており、当然その resources も保護されません。

これに対し、Windows Vista 以降では Low IL を利用しており、これは resources SACL に Low mandatory level が存在するものしか access できません。

参考) Low integrity level、Integrity level を ACE として folder へ設定可能

Low mandatory level が設定されている場所は %UserProile%\AppData\LocalLow 等の非常に限定的な場所にのみ付与されているため、Windows XP で Adobe Reader が利用している Restricted Token とは格段に制限が厳しいです。

Windows XP でも Restricted Token を利用することにより、かなりの security 向上が見込めますが、Windows Vista 以降では IL のおかげで遥かに高い保護が行えます。どうしようもない理由で Windows XP を使い続けなければならないならともかく、さっさと Windows Vista 以降の OS に乗り換えましょう。それから、UAC は絶対に無効化しない。これ重要。

Restricting SID

ちゃっぴ (tyappi@wankuma.com) — Sun, 21 Nov 2010 17:26:00 GMT

Adobe Reader X に関して NyaRuRu さんから突っ込みをいただいたので、Windows XP 上での Adobe Reader X について書こうと思ったのですが、その前に restrictied token について説明する必要があるため先に説明します。

CreateRestrictedToken 関数で作成する Restricted Token (制限トークン) での SID 制限の方法には deny-only SID (SID の無効化) と restricting SID (制限付き SID) の 2 種類が存在します。

まずは簡単な deny-only SID の方から。Deny-only SID とは、対象の SID を無効化します。無効化なので ACL に該当する SID が存在したとしても、無かったものとして扱われます。例えば、管理者権限を無効化するために BUILTIN\Administrators group SID を消しこむといった用途で使われますね。UAC の medium IL での管理者権限削除はこれを利用することによって実現されています。CreateRestrictedToken 関数では第 3 引数 DisableSidCount、第 4 引数 SidToDisable に対応します。

次にちょっとわかりにくい restricting SID の方。こちらはなんなのかというと Restrited と mark された SID のみが利用可能であるということです。

上は Windows XP mode でメモ帳 (notepad.exe) を「別のユーザーとして実行」→「許可されていないプログラムの動作からコンピュータとデータを保護する」を有効化して「現在のユーザー」で起動した aceess token です。

BUILTIN\Administrators が Deny されており、ほとんどの SIDs に Restricted flag がついているのが確認できます。それから NT AUTHORITY\RESTRICTED という見慣れない SID が存在しますね。

この状況では下記のように access check が行われます。

ACL に BUILTIN\Administrators が含まれていても deny-only であるため無視される
restricting SIDs 以外の SIDs を確認し、ACL に含まれる SID に対応した許可の ACE が含まれる場合のみ次に進む
NT AUTHORITY\RESTRICTED SID が付与されている Restricted Token であるため、restricting SIDs を照合して restricting SIDs が存在するもののみ access が許可される

How Access Tokens Work

ここで注意してほしいのは、この process の実行 user である VIRTUALXP-17110\XPMUser の restircting SID が含まれていないことです。つまり、VIRTUALXP-17110\XPMUser の権限が無効化されているということになります。

わかり易く整理すると下表のような感じです。

SIDｓ	Enable
Logon SID (S-1-5-5-0-71174)	Enabled
Everyone	Enabled
Local	Enabled
NT AUTHORITY\Authenticated Users	Enabled
NT AUTHORITY\REMOTE INTERACTIVE LOGON	Enabled
VIRTUALXP-17110\Debugger Users	Enabled
VIRTUALXP-17110\なし	Enabled
BUILTIN\Users	Enabled
NT AUTHORITY\INTERACTIVE	Enabled
BUILTIN\Administrators	Disabled
VIRTUALXP-17110\XPMUser	Disabled

実行 user である VIRTUALXP-17110\XPMUser の SID が利用できないのがミソですね。この影響により、この SID で許可されている %UserProfile% や HKCU 配下のすべての権限が消滅します。

なお、restricting SID は CreateRestrictedToken 関数の第 7 引数 RestrictedSidCount、第 8 引数 SidsToRestrict を利用して作成します。

"RunAs" basic (and intermediate) topics
Running restricted -- What does the "protect my computer" option mean?

Windows Event Log の ACL 設定方法

ちゃっぴ (tyappi@wankuma.com) — Fri, 11 Sep 2009 01:23:00 GMT

下記の続き

Windows Event Log の ACL を簡単に取得する方法が判明しました。

Windows Event Log は Windows Vista 以降で追加されたものですが、Windows Vista 以降では Windows Event Log を管理する command utility “Wevtutil.exe” が追加されています。これを利用することで、下記のようにして簡単に ACL を取得することができます。

>wevtutil.exe gl "Application"
name: application
enabled: true
type: Admin
owningPublisher:
isolation: Application
channelAccess: O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU
)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)(A;;0x3;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)
logging:
  logFileName: %SystemRoot%\System32\Winevt\Logs\application.evtx
  retention: false
  autoBackup: false
  maxSize: 20971520
publishing:

"channelAccess" に表示されている SDDL が ACL ですね。

設定は下記のようにして行います。

>wevtutil.exe sl "Application" /ca:"%SDDL%"

"%SDDL%" には設定する ACL を SDDL 形式にて指定してください。

さて、この設定はどこに施されるのでしょう？

確認したところ、application log の場合旧来と同じく下記に設定されることが確認できました。

HKLM\System\CurrentControlSet\Services\Eventlog\Application\CustomSD

Vista 以降で追加された channel に関しては下記ですね。

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\%ChannelName%\ChannelAccess

ということで、旧来から存在する event log に関しては設定個所は同じであることがわかりました。

なお、command line utility は紹介しましたが、API はどうなのかというと存在するようです。

EvtOpenChannelConfig Function で EVT_HANDLE 取得して、EvtGetChannelConfigProperty Function に EVT_CHANNEL_CONFIG_PROPERTY_ID Enumeration の EvtChannelConfigAccess を指定して呼び出せばよさげですね。

設定は EVT_HANDLE 取得した後に EvtSetChannelConfigProperty Function で設定して EvtSaveChannelConfig Function で保存。

最後に忘れちゃいけない後始末ってことで、EvtClose Function 呼んどきましょ。

多分これでいけると思います。時間あるときに検証してみます。

<追記>Sample ありました。
Getting and Setting a Channel's Configuration Properties

アプリケーション開発者向け Microsoft® Windows 7 対応アプリケーションの互換性

ちゃっぴ (tyappi@wankuma.com) — Sat, 27 Jun 2009 22:49:00 GMT

Session 資料の調査をしていたら、こんな資料見つけました。

アプリケーション開発者向け MicrosoftR Windows 7 対応アプリケーションの互換性

開発者必見ですね。

すべての user で初期設定を統一化する方法

ちゃっぴ (tyappi@wankuma.com) — Sun, 15 Mar 2009 17:06:00 GMT

Test でよくやることですが、新しい user を作っては試験しては壊し、作っては試験しては壊しってやりますよね。また、security 確保のため、一人で複数 account を使い分けるというのもありますね。その時、ガリガリ costomize していると、いちいち設定変更するのが面倒くさくてかないません。

というわけで、新しい user profile を作成したときでも costomize された状態にする方法を紹介します。

基本は下記で説明されている手順になります。

カスタマイズしたデフォルトのユーザープロファイルを作成する方法

Windows Vista 以降では default user profile の path が "%USERPROFILE%\Default" に変更になっている以外、大きな違いはありません。

この方法を使ってもいいのですが、user profile を丸ごと copy することになるため、不要な設定がいろいろ入ってしまいます。そこで、直接 default user profile の registry を編集する方法をとります。

Default user profile の hive は既定で読み込まれていないため、まずこれを load する必要があります。

Registry Editor (regedit.exe) を開き、tree から "HKEY_USERS" を選択し、[ファイル] - [ハイブの読み込み] を実行。

[ハイブの読み込み] dialog box にて default user profile hive の path を指定。

これで、default user profile の registry を好き勝手にいじる準備ができました。

後は、好きなように costomize してください。

ただ、忘れていけないのは作業が終わったら必ず hive を unload すること。ちゃんと unload しないといつまでたっても unload されずに警告が上がります。

GUI での操作方法を示しましたが、command からも可能です。Reg.exe に load, unload という option があるので、これを利用して batch file 等で自動化可能ですね。

まあ、そんなところで。

Adobe Reader 9.x の Java Script を無効化する方法

ちゃっぴ (tyappi@wankuma.com) — Sun, 15 Mar 2009 16:19:00 GMT

先週 Adobe Reader 9.1 が release され CVE-2009-0658 の問題が修正されました。ただ、Adobe Reader で発見された過去の脆弱性の中で Acrobat JavaScript に関わるものは結構な数が存在します。ぶっちゃけた話、Adobe Reader を利用している user の中で Acrobat JavaScript を利用している user の割合はごく少数なので、一般的には Acrobat JavaScript を無効にしておくことに越したこと無いと思います。

GUI では [編集] - [環境設定] で表示された「環境設定」画面にて分類「JavaScript」の項目「Acrobat JavaScript を使用」を無効にします。ただ、user 毎の設定となるため user が多く存在すると GUI では適用が面倒です。

そこで、GUI を利用せず適用する方法。「Acrobat JavaScript を使用」は下記 registry entry を変更することで切り替えられます。

HKCU\Software\Adobe\Acrobat Reader\9.0\JSPrefs
REG_DWORD bEnableJS 0:無効、1:有効

Domain 環境であれば custom group policy (拡張子 adm, admx) を作成するのがいいですね。

Adobe 社が group policy template 用意してくれればこんな面倒なことしなくても、管理者楽なのに。。。

Domain 環境でない場合、効率悪いですが logon script で毎回更新するとかありますね。Script はこんなので十分。

reg.exe add "HKCU\Software\Adobe\Acrobat Reader\9.0\JSPrefs" /v "bEnableJS" /t "REG_DWORD" /d 0 /f

他の方法としては default user profile (%USERPROFILE%\Default\NTUser.dat) を直接変更する方法があります。こちらは、user profile の作成時のみ有効ですね。

これらの方法は Adobe Reader に限らず広く有効な方法なので、管理を行う人は覚えておくことに越したことないでしょう。

UAC 環境下で制限された file への Zone ID 変更操作は昇格されない

ちゃっぴ (tyappi@wankuma.com) — Thu, 12 Feb 2009 10:44:00 GMT

Windows XP SP2 からの仕様変更で Internet Explorer 等対応した application から download された file には NTFS file stream に zone identifer が保存され、それによって警告が表示されたり、設定によっては問答無用で実行ができなかったりします。

これを file 毎に個別に解除するには、対象 file の property で <ブロックの解除> を実行します。

ところが、UAC 環境下で対象 file への書き込みが制限されている場合には、<ブロックの解除> を実行しても設定変更できないんです。何回やっても何回やっても倒せない。。。

回避策としては、別の書き込み可能な folder に一度移動させてから設定変更し、戻してやるとか。めんどくさー！

同じ property page にある「読み取り専用」とか「隠しファイル」を変更した場合には、このような dialog が表示され問題無く変更できます。

<ブロックの解除> も同様に昇格するように修正するべきではないでしょうか？ちなみに Windows 7 beta でも変更されていないです。

ところで、複数の file をまとめて解除したいという要望は結構存在すると思います。そういうときには Windows Sysinternals の Streams を利用しましょう。

Streams.exe -s -d "%TARGET_FOLDER_PATH%"

上記のような感じです。

<参考>

4GT に対応した applications を作成する方法

ちゃっぴ (tyappi@wankuma.com) — Sun, 08 Feb 2009 23:52:00 GMT

32 bit Windows の boot 設定で applicatrions に対して 2GB を超える memory を割り当てる方法 (4GT) として "/3GB", "/USERVA", "INCREASEUSERVA" なんてものがありますが、これを生かすためには applications 側での対応が必要です。

具体的には PE header に "LARGEADDRESSAWARE" を設定する必要があります。

VC++ では linker option に "/LARGEADDRESSAWARE" を指定すればいいだけですね。

ですが、VB.NET や C# では build した後生成された binary を変更する必要があります。その際利用するのは "editbin.exe" です。

"editbin.exe" /LARGEADDRESSAWARE "%TARGET_PATH%"

”%TARGET_PATH%" には生成された binary の path が入ります。あと、「Visual Studio 2008 コマンドプロンプト」を実行したときに追加される path があらかじめ通っていないと下記のような error が発生するので注意が必要ですね。

毎回 command line 叩いてもいいんですが、面倒なので自動化しましょう。

VB.NET, C# ともに build 終了後に実行する command line を指定することができるのでこれを利用します。

入力するのは下記です。

SET PATH=%PATH%;C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\x86_amd64;C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN;C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools;C:\Windows\Microsoft.NET\Framework\v3.5;C:\Windows\Microsoft.NET\Framework\v2.0.50727;C:\Program Files\Microsoft Visual Studio 9.0\VC\VCPackages
"editbin.exe" /LARGEADDRESSAWARE "$(TargetPath)"

環境変数 "%PATH%" を再定義していますが、追加しているのは下記 file の 25 行目に書かれているものです。

"%PROGRAMFILES%\Microsoft Visual Studio 9.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"

正常に設定されたかを確認するには、"dumpbin.exe" を利用します。「Visual Studio 2008 コマンドプロンプト」から下記を実行しましょう。

"dumpbin.exe" /headers "%TARGET_PATH%"

PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
             14C machine (x86)
               3 number of sections
        498EE40E time date stamp Sun Feb 08 22:54:22 2009
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
             122 characteristics
                   Executable
                   Application can handle large (>2GB) addresses
                   32 bit word machine

上記のように "Application can handle large (>2GB) addresses" と表示されれば成功です。

とりあえず、これで 2 GB を超える memory を扱えることができますが、1 つの process で 4GT で設定した値を超える memory を利用することはできません。4GT で設定した値を超える必要があれば AWE を利用することになります。

まあ、そんなことするくらいなら、ぶっちゃけ 64 bit OS 使いましょう。

Windows Installer で配置する resources の DACL を変更する方法

ちゃっぴ (tyappi@wankuma.com) — Fri, 06 Feb 2009 19:20:00 GMT

すべての user で扱う file の配置場所
 Visual Studio Setup Project で %PROGRAMDATA% へ file を配置する方法の続き

無事 "%PROGRAMDATA%" に resources を配置することは出来ましたが、すべての user で変更可能であるという要件はこれだけでは満たせません。

ということで、installer で対象 resources の DACL を変更する必要があるのですが、その一つの方法をば。

Windows Installer database には LockPermissions Table というものがあり、こちらに追加することで任意の resources の DACL を変更することができます。

ただ、Visual Studio 2008 の Setup Project には LockPermissions Table を編集する UI を持っていませんので、MSI の作成後 ORCA や scripts 等で Windows Installer database を編集する必要があります。今回は ORCA を利用した方法を説明します。

ORCA は Visual Studio 2008 とともに install されないため、手動で install する必要があります。私の環境では Microsoft SDK v6.0A の installed folder 配下の "bin" folder に "Orca.Msi" が存在しました。また、Windows Installer 最新 version 4.5 の SDK にも最新の "Orca.Msi" が含まれているので、そちらを利用してもいいでしょう。どちらにしろ、main の application install 後 "Orca.Msi" を手動で実行してやる必要があるので注意が必要です。

"Orca.Msi" の install が完了したら、ORCA を起動し Visual Studio Setup Project で作成した MSI file を開きます。

今回 sample として用意した MSI file は "%PROGRAMDATA%" を "COMMONAPPDATA" として定義した folder 配下に "Test" という sub folder を作成するというものです。これから、この "Test" folder の DACL を変更します。

上記画像は ORCA で spamle の MSI file の Directory Table を表示したものです。3 行目の directory "_009F8BF9D3EC4C278D0F060093FC80E8" が "Test" folder です。今回、問答無用で folder を作成するように設定しましたので、同様の entry が CreateFolder Table にも存在します。

それでは、LockPermissions Table を覗いてみましょう。

何もないですね。列が 5 つ存在します。それぞれの役割は下記。

Column	Description
LockObject	対象 object の primary key を指定
Table	対象 objcet が存在する table name を指定 File, Registry, CreateFolder から選択
Domain	Domain name を指定 (省略可)
User	User name を指定
Permission	許可する access mask (32 bit 符号付き整数) を 10 進表記で指定

さて、それでは実際に試してみましょう。

今回対象 folder に対し下記のような DACL を付与します。

Domain	User	Access Rights
NT Authority	System	フルコントロール
BUILTIN	Administrators	フルコントロール
BUILTIN	Users	変更

この場合、LockPermissions Table には下記 3 行を追加します。

LockObject	Table	Domain	User	Permission
_009F8BF9D3EC4C278D0F060093FC80E8	CreateFolder	NT Authority	System	268435456
_009F8BF9D3EC4C278D0F060093FC80E8	CreateFolder	BUILTIN	Administrators	268435456
_009F8BF9D3EC4C278D0F060093FC80E8	CreateFolder	BUILTIN	Users	-536805376

[Permission] の値がわけわからない？それはごもっとも。

Access mask とは bit flag の集合で下記 3 種類に分類できます。

Generic Access Rights, Standard Access Rights, Specific Access Rights

Generic Access Rights と Standard Access Rights はすべての object で有効ですが、Specific Access Rights はその object 専用の権限が定義されています。今回の場合対象は folder ですので File Security and Access Rights で確認できます。

268435456 は "フルコントロール" = GENERIC_ALL (0x10000000) を 10 進表記したものになります。-536805376 はちょいとめんどくさいですが、下記の計算結果で ”変更" を示しています。

GENERIC_EXECUTE (0x20000000) | GENERIC_WRITE (0x40000000) | GENERIC_READ (0x80000000) | DELETE (0x00010000)

とりあえず対象は file のみですが、よく利用する access rights の対応表を作成してみました。

Friendly Name	Access Rights	Hex	Decimal
フルコントロール	GENERIC_ALL	0x10000000	268435456
変更 (読み取りと実行フォルダの内容一覧表示書き込み含む)	GENERIC_READ \| GENERIC_WRITE \| GENERIC_EXECUTE \| DELETE	0xE0010000	-536805376
読み取りと実行 (フォルダの内容一覧表示含む)	GENERIC_READ \| GENERIC_EXECUTE	0xA0000000	-1610612736
フォルダの内容一覧表示	SYNCHRONIZE \| READ_CONTROL \| FILE_READ_ATTRIBUTES \| FILE_TRAVERSE \| FILE_READ_EA \| FILE_LIST_DIRECTORY	0x1200A9	1179817
読み取り	FILE_READ	0x1	1
書き込み	SYNCHRONIZE \| FILE_WRITE_ATTRIBUTES \| FILE_WRITE_EA \| FILE_APPEND_DATA \| FILE_WRITE_DATA	0x100116	1048854

長くなりましたが、LockPermissions Table 編集後 MSI file を保存すれば DACL を変更する機能を付与した installer の完成です。

<参考>

すべての user で扱う file の配置場所

ちゃっぴ (tyappi@wankuma.com) — Fri, 06 Feb 2009 04:24:00 GMT

FAQ な質問にすべての user で扱う file はどこに配置すべき？というのがあります。この質問は目にするたび、user がその file を直接指定することがないのであれば、下記に配置するべきだと書いています。

OS	Path
Vista	%PROGRAMDATA%
XP	%ALLUSERPROFILE%\Application Data

Vista 以降限定であれば、環境変数一つで定義されているので環境変数を利用してもよいですが、Vista より以前が対象に含まれる場合にはこれではまずいです。上記の場所は registry に設定されており、それを扱う API が整備されているので必ずそれを利用しましょう。

Library type	Function	Argument	Minimum OS
Win32	SHGetFolderPath ~~SHGetSpecialFolderPath~~	CSIDL_COMMON_APPDATA
Win32	SHGetKnownFolderPath	FOLDERID_ProgramData	Vista
COM	IKnownFolderManager::GetFolder	FOLDERID_ProgramData	Vista
.NET	System.Environment.GetFolderPath	CommonApplicationData
Automation	Shell.Namespace	CSIDL_COMMON_APPDATA (&h23)

なお、対象 folder の ACL は Windows Vista では既定で下記のように構成されています。

Type	Name	Permission	Inheritance
Allow	NT AUTHORITY\System	FILE_ALL_ACCESS	OBJECT_INHERIT_ACE CONTAINER_INHERIT_ACE
Allow	BUILTIN\Administrators	FILE_ALL_ACCESS	OBJECT_INHERIT_ACE CONTAINER_INHERIT_ACE
Allow	CREATOR OWNER	GENERIC_ALL	OBJECT_INHERIT_ACE CONTAINER_INHERIT_ACE INHERIT_ONLY_ACE
Allow	BUILTIN\Users	GENERIC_READ GENERIC_EXECUTE	OBJECT_INHERIT_ACE CONTAINER_INHERIT_ACE
Allow	BUILTIN\Users	FILE_WRITE_DATA FILE_APPEND_DATA FILE_WRITE_EA FILE_WRITE_ATTRIBUTES	CONTAINER_INHERIT_ACE

上記 DACL を簡単に説明すると、制限 user はすべての file を開いたり実行でき、 file を新規作成できるが、自分が作った file じゃないと更新や削除ができないということになります。実によく考えられてますね。

これが嫌なら、DACL を変更することになります。

ただ、安易に複数 user で共有する場所に配置するのは考え物です。その file が本当に複数 user 間で共有する必要があるか今一度考慮すべきでしょう。その file を直接指定することなく、すべての user で共有する必要があり、かつすべての user が更新する必要があるものって相当少ないと思いますよ。

また、対象の file の内容はすべての user が扱う必要があるもののみ格納されているでしょうか？すべての user が扱う必要の無いものが含まれているのであれば、それは分離し個々の user profile に格納するべきでしょう。

なお、user が直接その file を指定することがあるのであれば、"%ALLUSERPROFILE%" ("%PUBLIC%") 配下の "Documents", "Downloads", "Music", "Pictures", "Videos" とかに格納すべきです。それぞれ対応した KNOWNFORDERID (CSIDL) があるので、環境変数など使わずに API で取得しましょう。

ちなみに、こちらは "NT AUTHORITY\INTERACTIVE" に十分な権限が与えられているので更新等で問題が生じることはほぼないでしょう。逆に厳しくしたいという要件が結構あるかも。

<参考>

Visual C++ 2005 または Visual C++ .NET を使用して、ユーザーとアプリケーションのデータを適切な場所に格納する Windows XP アプリケーションを記述する方法