2018年5月27日

WindowsのIMEにおけるセキュリティ


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 としてください。

2017年7月5日

PerlのEncode::JIS2KとPython

以前に自分が書いた記事が矢野さんに取り上げられて大変嬉しかったので、引き続きいろいろな処理系でのJIS X 0213の実装状況を調べていたのですが、Pythonと同様な変換を持った実装を見付けました。

Unicode の嫌なところを触ってしまった Python
http://yanok.net/2017/06/unicode-python.html

それがPerlのEncode::JIS2Kモジュールなのですが、

Encode::JIS2K - search.cpan.org
http://search.cpan.org/~dankogai/Encode-JIS2K/JIS2K.pm

こちらもPythonと同様にこのような変換を持っていました。

JIS X 0213Unicode
1面2区54点U+2985LEFT WHITE PARENTHESIS
1面2区55点U+2986RIGHT WHITE PARENTHESIS

もしかすると、PerlのEncode::JIS2Kモジュールを実装された方とPythonのcodecsモジュールを実装された方が、偶々どこかの同じ資料を参照していたのかもしれません。

ちなみに、その他の実装では大抵このような変換になっています。

JIS X 0213Unicode
1面2区54点U+FF5FFULLWIDTH LEFT WHITE PARENTHESIS
1面2区55点U+FF60FULLWIDTH RIGHT WHITE PARENTHESIS

Encode::JIS2Kは、
  • JIS X 0213の2004年改正に未対応
  • Unicodeへの変換結果が結合文字列となる文字に未対応
といった特徴があるので、特段の理由が無ければEncode::JISX0213およびEncode::ShiftJIS2003を使用したほうが良いかもしれません。

Encode::JISX0213 - search.cpan.org
http://search.cpan.org/~nezumi/Encode-JISX0213-0.04/lib/Encode/JISX0213.pm
Encode::ShiftJIS2004 - search.cpan.org
http://search.cpan.org/~nezumi/Encode-JISX0213-0.04/lib/Encode/ShiftJIS2004.pm

2017年2月25日

Certum Opensource Code Signing

2017年2月からコード署名の運用が少し厳しくなったようで、FIPS 140-2の暗号化モジュールが必須になるなどの変更がありました。

Leading Certificate Authorities and Microsoft Introduce New Standards to Protect Consumers Online - CA Security Council
https://casecurity.org/2016/12/08/leading-certificate-authorities-and-microsoft-introduce-new-standards-to-protect-consumers-online/

Certum が販売しているオープンソースプロジェクト向けコードサイニング証明書でも暗号化モジュールが必須になったので、購入に際して嵌った点などをまとめてみました。

Opensource Code Signing - Certum
https://www.certum.eu/certum/cert,offer_en_open_source_cs.xml
https://www.certum.eu/en/cert_offer_en_open_source_cs/


おおまかな手続きの流れ

  1. Certumのアカウントが無い場合はアカウントを作成します。
  2. PKI対応スマートカードを持っている場合は Activation Code、持っていない場合は Code Signing Suite を購入します。Code Signing Suite を購入した場合はSIMサイズのスマートカードと2GBのMicroSDカードを内蔵したUSBトークンがポーランドからDHLなどで郵送されます。(以降、Code Signing Suiteを購入したという前提で記述します。)
  3. USBトークンをPCに差し、後述の USBトークンのドライバと proCertum CardManager をインストールした状態で証明書を申請します。この時点では秘密鍵のみがスマートカードに保存されるようです。
  4. 証明書の承認に必要な書類のコピーとオープンソースプロジェクトのURLをメールで送ります。
  5. 承認されると公開鍵が発行されるので、proCertum CardManager からインポートします。

証明書の申請手続きの詳細は、次のリンクのPDFファイルを参照してください。

How to install the CS certificate - Certum
https://www.certum.eu/certum/cert,expertise_How_to_install_the_CS.xml
https://www.certum.eu/en/cert_expertise_How_to_install_the_CS/


USBトークン

Code Signing Suite を購入すると送られてくるUSBトークンは Advanced Card Systems の ACR101 でした。内蔵のMicroSDカードにもドライバが入っていますが、ACSのサイトのほうが若干新しいバージョンとなっているようです。

Card reader ACS ACR 101 SIMicro (CCID) - Certum
https://www.certum.eu/certum/cert,offer_Czytnik_kart_ACS_ACR_101_SIMicro_(CCID)_en.xml
https://www.certum.eu/en/cert_offer_czytnik_kart_acs_acr_101_simicro_ccid_en/

PC-Linked Readers with Mass Storage - ACR101 SIMicro | ACS
https://www.acs.com.hk/en/products/141/acr101i-simicro-ccid/

実機のスマートカードを使わずにTPMによる仮想スマートカードやHyper-Vの仮想TPMによる仮想スマートカードを使う手もあるようですが、ハードウェア要件が厳しいので実機があったほうが手軽かと思います。





proCertum CardManager

スマートカードに保存された証明書を管理するソフトです。内蔵のMicroSDカードにも入っていました。

Software and Libraries - Certum
https://www.certum.eu/certum/cert,offer_software_and_libraries.xml
https://www.certum.eu/en/cert_offer_software_and_libraries/

proCertum CardManager - Certum
https://www.certum.eu/certum/cert,offer_card_manager.xml
https://www.certum.eu/en/cert_offer_card_manager/
(英語版マニュアルのリンクが間違っているようです。正しくは https://www.certum.eu/upload_module/wysiwyg/certum/nowe_certum/instructions/proCertumCardManager-en_3_2_0_146.pdf https://www.certum.pl/pl/upload_module/wysiwyg/certum/nowe_certum/instructions/proCertumCardManager-en_3_2_0_146.pdf です。)

proCertum CardManager – FAQ - Certum
http://certum.eu/certum/cert,offer_proCertum_CardManager_support.xml
https://www.certum.eu/en/support/cert_offer_procertum_cardmanager_support/

オプションで「EV Code Signing」をチェックしてからOSを再起動すると signtool のダイジェストアルゴリズムとしてSHA-256が使用可能になります。

オプションで「EV Code Signing」をチェックしたとき proCertum CardManager に含まれる cryptoCardRegister.exe が起動されるようですが、version 3.2.0.154 では起動に失敗してしまうようなので proCertum CardManager がインストールされたディレクトリに予めパスを通しておくと良いみたいです。

Code Signing Suite に付属するスマードカード限定かもしれませんが、proCertum CardManager から見ると「Secure profile」と「Common profile」の2つのプロファイルが用意されています。Secure profile には Certum が予め PUK を設定しているようなので使用できません。コードサイニング証明書は Common profile のほうにインポートします。

Common profile を初期化する際に PUK と PIN を設定しますが、PIN は signtool を実行する度に入力する必要があるので短か目にしておいたほうが良いかもしれません。当然ですが PUK と PIN を忘れるとそのスマートカードは使用不可になってしまいます。


証明書の承認に必要な書類など

以下の書類などが必要です。
  1. identity document (ID card, passport, residency card, driver's license) - in Latin characters - of the person placing the order. The copy should depict the entire document (both sides)
  2. a utility bill (e.g. water, electric power, natural gas, etc.), bank statement, credit card statement, government‐issued tax document belonging to the Subscriber
  3. internet address of the project

1番はパスポートか国際運転免許証が使用可能だと思います。私はパスポートを使用しました。

2番は公共料金の明細の類なのですが、Certumの担当者の方と何度か遣り取りしたところ大体以下のような要件となっているようです。
  1. ラテン文字 (キリル文字も多分OKかも?)
  2. 住所の記載がある
  3. 手書きではなく印刷されている (おそらく担当者のサインのみ手書きOKだと思われる)
  4. 13ヶ月以内に発行されている
いろいろ探した結果、住所の記載があるゆうちょ銀行の英文残高証明書が使用できました。
小さな郵便局では所定のフォーマットの紙に手書きするところもあるようなので、大きな郵便局が良いかもしれません。20~30分くらいで発行してもらえます。

3番はオープンソースプロジェクトのURLです。おそらくソースが公開されていてOSIに認定されているライセンスであればOKだと思います。


signtool

SignTool.exe - MSDN
https://msdn.microsoft.com/en-us/library/8s9b9yaz(v=vs.110).aspx
https://docs.microsoft.com/en-us/dotnet/framework/tools/signtool-exe

PFXファイルが使えなくなったので /a, /i, /n, /sha1 などのオプションでPCにインポートされた証明書を指定します。



以上です。