TSF (Text Services Framework) で実装された IME は COM (Component Object Model) の DLL として実装されるので、その IME を有効にするとアプリケーションのプロセスにロードされて動作します。つまり、アプリケーションと同じプロセス空間に存在していることになります。
このため、サンドボックスによるセキュリティ上の制約は、アプリケーションに対してだけでなく IME に対しても同様に適用されます。
IME がファイル、レジストリ、プロセス間通信などを用いて設定内容や辞書を読み書きする際には、こうしたサンドボックスの外側に存在するオブジェクトに対して、許可が得られるような適切なセキュリティの設定がなされる必要があります。
一口にサンドボックスといっても様々な種類がありますが、基本的には Windows が持つセキュリティ機構を使用したものとなっています。@ITの記事が非常に参考になりますのでリンクを貼っておきます。
アクセス制御リストACL - @IT
http://www.atmarkit.co.jp/ait/articles/1407/17/news130.html
Windowsのアクセス制御リストACLとは？ - @IT
http://www.atmarkit.co.jp/ait/articles/0601/21/news011.html
オブジェクトを識別するSIDとは？ - @IT
http://www.atmarkit.co.jp/ait/articles/0306/28/news004.html
(追記)
Windowsのセキュリティ設定を記述するSDDL文字列とは？ - @IT
http://www.atmarkit.co.jp/ait/articles/0603/25/news016.html
Windows における主要なサンドボックス毎に、制限されたプロセス内の IME がアクセスできるようにする方法について述べます。
Mandatory Integrity Control
Windows Vista で導入されたアクセス制御です。必須整合性コントロールと訳されます。
Mandatory Integrity Control
https://msdn.microsoft.com/en-us/library/windows/desktop/bb648648(v=vs.85).aspx
いくつかのレベルが用意され、下位のレベルから上位のレベルへのアクセスを制限する機能を持ちます。また、制限の内容としては、書き込み拒否 / 読み込み拒否 / 実行拒否があります。
以下のようなソフトウェアで利用されています。
- Internet Exploere 7 以降 (詳細設定で保護モードを有効にしたとき)
- Adobe Reader X 以降
- Firefox 4.0 以降で動作する Flash Player 11.3 以降
これらのソフトウェアでは、整合性レベル「低」のプロセスとして動作しており、書き込み拒否の制限となっています。つまり、整合性レベル「低」より高いレベルのオブジェクトには書き込みできない、ということになります。読み込みのみであれば、整合性レベルの設定は不要です。SDDL としては次のような記述で SACL として表現されます。
S:(ML;;NW;;;LW)また、sddl.h では次のように定義されています。
//
// SDDL Ace types
//
#define SDDL_MANDATORY_LABEL TEXT("ML") // Integrity label
//
// SDDL Rights
//
#define SDDL_NO_WRITE_UP TEXT("NW")
#define SDDL_NO_READ_UP TEXT("NR")
#define SDDL_NO_EXECUTE_UP TEXT("NX")
//
// Integrity Labels
//
#define SDDL_ML_LOW TEXT("LW") // Low mandatory level
#define SDDL_ML_MEDIUM TEXT("ME") // Medium mandatory level
#define SDDL_ML_MEDIUM_PLUS TEXT("MP") // Medium Plus mandatory level
#define SDDL_ML_HIGH TEXT("HI") // High mandatory level
#define SDDL_ML_SYSTEM TEXT("SI") // System mandatory level
AppContainer
Windows 8 で導入されたアクセス制御です。
AppContainer Isolation
https://msdn.microsoft.com/en-us/library/windows/desktop/mt595898(v=vs.85).aspx
以下のようなソフトウェアで使用されています。
- Windows ストアアプリ
- ユニバーサル Windows プラットフォームアプリ (UWP アプリ)
- Internet Explorer 10 以降 (詳細設定で「拡張保護モードを有効にする」をチェックしたとき)
- Adobe Acrobat Reader DC 15.023.20053 以降 (環境設定で「AppContainer (ベータ版) で実行」をチェックしたとき)
sddl.h で次のように定義されている SID を SDDL に記述することになります。
//
// SDDL User aliases
//
#define SDDL_ALL_APP_PACKAGES TEXT("AC") // All applications running in an app package
Restricted Token
アクセストークンを制限します。以下のようなソフトウェアで使用されています。
- Adobe Reader X 以降
- Firefox 4.0 以降で動作する Flash Player 11.3 以降
これらのソフトウェアでは、Restricted Token による権限チェックと、前述の整合性レベル、およびジョブオブジェクトから成るサンドボックスとなっています。Acrobat Reader DC では、ベータ版の機能としてですが AppContainer も使用可能となり、何でもありか？という状況になっています。
詳しく知りたい方は、Microsoft および Adobe のサイトを参照してください。
Restricted Token - Windows Dev Center
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379316(v=vs.85).aspx
Job Objects - Windows Dev Center
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684161(v=vs.85).aspx
Inside Adobe Reader Protected Mode – Part 1 – Design
http://blogs.adobe.com/security/2010/10/inside-adobe-reader-protected-mode-part-1-design.html
Inside Adobe Reader Protected Mode – Part 2 – The Sandbox Process
http://blogs.adobe.com/security/2010/10/inside-adobe-reader-protected-mode-part-2-the-sandbox-process.html
Inside Adobe Reader Protected Mode – Part 3 – Broker Process, Policies, and Inter-Process Communication
http://blogs.adobe.com/security/2010/11/inside-adobe-reader-protected-mode-part-3-broker-process-policies-and-inter-process-communication.html
Inside Adobe Reader Protected Mode – Part 4 – The Challenge of Sandboxing
http://blogs.adobe.com/security/2010/11/inside-adobe-reader-protected-mode-part-4-the-challenge-of-sandboxing.html
Flash Player Sandboxing is Coming to Firefox
http://blogs.adobe.com/security/2012/02/flash-player-sandboxing-is-coming-to-firefox.html
15.023.20053 Planned update, January 10, 2017 - Release Notes for Acrobat DC Products
https://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotesDC/continuous/dccontinuousjanuary2017.html
sddl.h で次のように定義されている SID と、Restricted Token によって無効化させたくない SID を SDDL に記述することになります。
#define SDDL_RESTRICTED_CODE TEXT("RC") // Restricted codeジョブオブジェクトについては、現状では前述のソフトウェアにおいてはファイルの読み書きの制約を受けていないので特にすることはありません。
まとめ
では、サンドボックス外の名前付きパイプにアクセス許可を付加する方法について見てみましょう。ビルドする際は、advapi32.lib をリンクしてください。#include <windows.h>
#include <sddl.h>
#include <aclapi.h>
int main() {
PSECURITY_DESCRIPTOR pSecurityDescriptor;
ConvertStringSecurityDescriptorToSecurityDescriptorW(
L"D:(A;;GA;;;AC)(A;;GA;;;RC)(A;;GA;;;SY)(A;;GA;;;BA)(A;;GA;;;BU)S:(ML;;NW;;;LW)",
SDDL_REVISION_1, &pSecurityDescriptor, NULL);
SECURITY_ATTRIBUTES sa = {sizeof(sa), pSecurityDescriptor, FALSE};
HANDLE hPipe = CreateNamedPipeW(
L"\\\\.\\pipe\\SamplePipe",
PIPE_ACCESS_DUPLEX | FILE_FLAG_FIRST_PIPE_INSTANCE,
PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
1, 256, 256, 0, &sa);
LocalFree(pSecurityDescriptor);
// ... Use named pipe.
CloseHandle(hPipe);
return 0;
}
次に、ファイルにアクセス許可を付与する方法を見てみましょう。
#include <windows.h>
#include <sddl.h>
#include <aclapi.h>
int main() {
PSECURITY_DESCRIPTOR pSecurityDescriptor;
ConvertStringSecurityDescriptorToSecurityDescriptorW(
L"D:(A;;FA;;;AC)(A;;FA;;;RC)(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;BU)S:(ML;;NW;;;LW)",
SDDL_REVISION_1, &pSecurityDescriptor, NULL);
BOOL bDaclPresent = FALSE;
PACL pDacl = NULL;
BOOL bDaclDefaulted = FALSE;
GetSecurityDescriptorDacl(
pSecurityDescriptor, &bDaclPresent, &pDacl, &bDaclDefaulted);
SetNamedSecurityInfoW(
L"SampleFile.txt",
SE_FILE_OBJECT, DACL_SECURITY_INFORMATION,
NULL, NULL, pDacl, NULL);
BOOL bSaclPresent = FALSE;
PACL pSacl = NULL;
BOOL bSaclDefaulted = FALSE;
GetSecurityDescriptorSacl(
pSecurityDescriptor,
&bSaclPresent, &pSacl, &bSaclDefaulted);
SetNamedSecurityInfoW(
L"SampleFile.txt",
SE_FILE_OBJECT, LABEL_SECURITY_INFORMATION,
NULL, NULL, NULL, pSacl);
LocalFree(pSecurityDescriptor);
return 0;
}
こうして出力されたファイルのプロパティは次の画像にようになります。Low Mandatory Level で、エントリに "ALL APPLICATION PACKAGES" と "RESTRICTED" があることが分かります。ちなみにこの画像のうち継承されたエントリは無効にしてしまってもOKです。
上記のサンプルコードではフルアクセス可能な設定になっていますが、実際は設計に応じて適切な ACL としてください。
