Software Design

JRE の配布について

ちゃっぴ (tyappi@wankuma.com) — Sun, 13 Jun 2010 16:09:00 GMT

dynaTrace AJAX Edition で同時に JRE が install されると書きましたが、これってどうなんだろ。

確かに JRE を同梱することにより JRE を別途 install する必要が無くなるので、便利かもしれない。だけど、JRE の普及率はかなり高く、この blog への閲覧の統計でも 92 % は Java を support しているという現実があります。つまり、JRE を同梱した場合、大多数の user は同一端末内で複数の JRE を管理しなければならず管理負荷が増大します。

もっとも、Eclipse に代表されるように開発で利用するものについては複数 version を使い分けることが必要になる場合があるので、容易に差し替えられるようにすることも考慮に入れなければならないかもしれない。しかし、既定で利用するものは既に install されているものを利用して欲しい。昔は update まで指定して動作保障を限定するなんてことありましたが、さすがに今は無いでしょうから。

なお、ここ一年ばかり猛威を奮っている Gumblar の攻撃方法の内、もっとも攻撃が成功しやすい方法は下記記事によると JRE を狙ったものであるそうだ。

いま一番危ないぜい弱性は何だ？

もっとも、application に同梱した JRE の利用は Web browser から利用されるわけではないため、攻撃を受ける可能性は相当低いと思われますが用心するに越したことないでしょう。

なお、この手の同梱の問題は他にもいろいろあって、array controller の管理用 interface が Tomcat を利用した Web application で作成されているとか。昔はかなり放置気味な気がしていましたが、最近はどうなのだろう？

Application を提供する方はその application のみの保守で設計するのはやめて、全体としての保守運用の最小化まで意識して設計を行っていただきたいです。

VB 6.0 の生産性

ちゃっぴ (tyappi@wankuma.com) — Fri, 27 Feb 2009 23:32:00 GMT

酷評する人が多いと思いますが、VB 6.0 それほど捨てたものではないと思うんですよ。

というのは、.NET Framework ではならの問題点がいくつか存在するからです。

もっとも大きな理由としては COM に対する扱いが厄介なこと。

In process な COM であれば深刻な問題はそれほど生じませんが、.NET Framework で out process な COM server を扱うとなると途端に問題になります。

.NET Framework で out process な COM server を扱うとなるとどうしても COM の解放処理を意識しないといけません。ぶっちゃけた話、.NET Framework で out process な COM server を扱うとなると開発生産性が VB 6.0 に比べて著しく低下すると思っています。

正直な話、out process な COM server を利用するのであればいろいろ制限はありますけど、VB 6.0 が生産性の面において一番効率的だと思っています。

まあ、もっとも VB 6.0 自体開発環境の support が切れていますから、将来性という面に於いて著しく不利なのは言うまでもありませんけれど。

VB 6.0 runtime support

ちゃっぴ (tyappi@wankuma.com) — Fri, 27 Feb 2009 22:53:00 GMT

VB6の呪縛がWindows7でも
 【VB6】VB6のランタイムがWindows 7でもサポートされるようです

正直な話、当然な話というのが感想です。

というのは、VBScript および VBA が現役だからです。VB6.0 の support を切ったからいって、現状では VBScript および VBA が今もって現役ですから VB6.0 をつぶしたところで、現実的に有効な費用対効果を得ることは難しいでしょう。ぶっちゃけた話、VB 6.0 を消したところで、VBScript および VBA を suppprt するのであれば、保守費用それほど変わらないと思いますし。

すべての 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 アプリケーションを記述する方法

Components はどのように分割するべきか？

ちゃっぴ (tyappi@wankuma.com) — Mon, 12 Jan 2009 01:14:00 GMT

大規模な projects だと設計時にどこで components を分割するか検討すると思います。

その多くは大きな機能の括りである sub system 単位で分割すればいいということで終わっていたりしないでしょうか？

個人的にはこれでは不十分だと思います。以下その理由。

Scalability を考慮すると現状でもまだまだ scale out が有効だが、sub system 単位ではその負荷までを考慮しきれていない
Security を考慮すると、security 境界が必要な部分で components を分割することが非常に有効

個人的には、これらのことを総合的に評価して初めて分割を決定するべきだと思います。

なお、前者は負荷が問題となるまで顕在化しませんが、後者は潜在的な問題があるだけで問題ですね。

ということで、個人的な components の分割基準としては、

Security
Performance
機能

という優先順位になると思います。

Administrators group に所属するか否かで判断するのがよろしくない理由

ちゃっぴ (tyappi@wankuma.com) — Mon, 12 Jan 2009 00:42:00 GMT

そういえば、Administrators に所属するか調査する方法で “Administrators” group に所属しているか否かで判断するのはやめるべきだとは書きましたが、明確な理由を書いていなかったので。

その最大の理由は委任ができなくなることです。

Secure OS の基本的な考えですが、管理者が全権を持ってはいけないという考え方があります。

そういう状況を想定してみてください。Application 側で “Administrators” group に所属していることを前提とした coding を行った場合、その処理を “Administrators” group に所属していない user では実行できなくなります。

“Administrators” group に所属させたくないが、特定の機能をある user には実行させたいという要件は、ごく自然に発生します。というのは、本当の全権を与えるということはどんな監査すら意味なくする権限を有するということですから。

制限かけるならば、built-in group ではなく、SQL Server のような専用の group を作成し利用するべきでしょう。もしくは、柔軟な制御はできなくなりますが、role-base access control を利用する方法もあります。

管理者のみ実行可能というのは非常にわかりやすいので、思わずそれで制限を掛けてしまいたくなりますが正直この方法はとるべきではないと思います。

Service security identifier

ちゃっぴ (tyappi@wankuma.com) — Sat, 10 Jan 2009 14:21:00 GMT

%Windows% に対し cacls.exe を打ってみるに aetos 氏より comment もらっていたので。

ドメイン部が NT Service になっていますね。
これは、Vista から導入されたサービスアカウントです。
サービスプロセスを実行するユーザーアカウントだと粒度が粗すぎるってんで、サービス単位に ACE を持てるようになりました。
で、TrustedInstaller ってのは、Windows Modules Installer っていうサービスですね。

ご指摘の通り、Windows Vista から導入された service security identifier ですね。ただ、"サービスアカウント" というのはちょっと引っかかるかな。

このことについては「サービスのデータを保護する」で説明されています。

とはいえわかりにくい部分があるので、実際にどんな風になっているか見てみましょう。調査対象は Windows Search (省略名: WSearch, process name: SearchIndexer.exe) です。

起動している user は service の起動 account である "NT AUTHORITY\SYSTEM" です。ただ、group に "NT SERVICE\WSearch" が含まれていますね。これが service security identifier です。

これを利用することにより、同じ service account を利用しても、特定の service のみ許可、もしくは特定の service のみ拒否するといった ACE を記述することが可能です。

以後蛇足。

Privilege をみると結構な数の特権が削除されていることがわかります。これは、restricted token を利用することによって実現されています。必要最小限となる serivce account の選定と restricted token を利用した token の制限は service の security を保つ上で非常に重要です。

Interface, method での access 制御の必要性

ちゃっぴ (tyappi@wankuma.com) — Sat, 10 Jan 2009 00:58:00 GMT

Access を制御しているように見えても強度は異なるの続き

新たなものを導入するためには、現状では不十分である理由を示さなければなりません。

確かに、多層防御が必要というのは一理あるでしょう。理想論としては、多層防御を行えば行うほど security level は高まりますので。

ところで、今回の議題は interface や method での access 制御です。これを行うことによる security の向上はどの程度期待できるでしょうか？

正直、劇的に変わらないんじゃないかと思います。

ぶっちゃけた話、一部の例外を除き interface ましてや method で access 制御を行う必要性が思い浮かばないんですよ。そんなことするくらいなら、process 分けるとかする方が簡潔でかつ確実な access 制御できますから。

Access を制御しているように見えても強度は異なる

ちゃっぴ (tyappi@wankuma.com) — Sat, 10 Jan 2009 00:33:00 GMT

Access を制御するものはどこに置くべき？の続き

インドリ氏の書き込みより

セキュリティ階層についてですが、ボクは多層防御の必要性を感じています。
その辺がちゃぴさんと相容れないのかもしれませんが、より一層の多段防御をするほうが良いのではないでしょうか？

これについては説明すると長くなるので、とりあえず第一弾ということで。

「わんくま同盟東京勉強会 #13」で説明したことですが、Windows では扱う resource (file, registry, process, thread, etc) のほとんどを ACL で管理しています。

この ACL を利用した access 制御ですが、logon 時に生成される access token が process もしくは thread に関連付けられ、その access token と ACL を照合することによって行われます。

この照合作業の多くは kernel level で行われていて、かつ対象となる resource は process 内部の memory 領域には存在せず、kernel を通じてのみ扱えることがミソです。

この場合、access 制御を回避する方法は OS を停止させるような方法を除外すると kernel を攻略しないとお話しになりません。

次にインドリ氏が主張している interface, method level での access 制御ですが、これ扱うのは対象は process 内の memory 空間に保持されているものですね。

既存の概念を壊さないで access 制御を実現させる場合、process memory 空間はいじらず、ただ単に interface や method を呼び出す前に access control させる手法があります。

ただ、これには弱点があります。その application に buffer overflow のような脆弱性が存在した場合、この方法で防御することはできません。

同じ access 制御を実現する 2 つの方法ですが、強度はかなり違ってきます。

Access を制御するものはどこに置くべき？

ちゃっぴ (tyappi@wankuma.com) — Thu, 08 Jan 2009 23:13:00 GMT

ネタ元

~~インドリ~~インドリ氏は coding 時に class, interface 果ては method, property まで利用者での access control できるようにすべきとの意見に見えます。Coding 時に access control を決定すると言うことは、つまり開発側が access control を決定するということになります。

ちょっと待ってください。これ本当にあるべき姿なんでしょうか？

利用される環境が特定されている環境ではそれでもいいでしょう。ただし、特定されない環境ではどうなるでしょう？開発側が示した access control が利用者側の policy を満たさない場合、使いもんにならないものになるでしょう。

また、利用される環境が特定されている場合でも、要件の変更なんてしょっちゅうありますよね。Access を制御するもの (例えば ACL) を code 内に内包した場合、その都度 compile し直して binary 配布する必要があります。

ということで、access を制御するものを code 内に内包するのは得策とは言えません。Binary とは別の編集可能なところに access を制御するものを置くべきでしょう。