アカウント名:
パスワード:
NTFS の仕様を公開する (特にオープンソース製品により操作できる) 必要性が分かりません。今回の仕様公開における範囲は「OS や各製品群の仕様書を公開する」物ではないですよね。
もうちょっと突っ込んで言うと「Windows が NTFS を操作するために利用している API の一覧や関連パテント群」は公開されても、実装は公開されない。Windows をオープンソース化して丸裸にする訳ではなく、いわゆる「オープン化」する (プロトコルとなる API の仕様をすべて開示する) だけに過ぎないのではないでしょうか。
なので、今回の事で Windows の機能を利用してアクセスしている訳ではない ntfs-3g 等の実装が良くなる、というのは考えにくい話です。
つーか、操作を想定していない外部から自由に「読み書き」できるのは fs を破壊し、ACLs を無視する操作に繋がるので勘弁してくれって感じなのですが。
良く考えてください。SMB(CIFS) も RDP も「プロトコル」です。NTFS は Windows における fs の「実装」でしかありません。公開されたプロトコルをベースに正しく通信を行う事ができれば十分であり、「実装の出来」でより良い実装が採用される競争が発生するのです。
*NIX であっても、NFS の下で現実に動いている fs が ufs/ext3/jfs/xfs... といったものは問いませんよね。それと何ら違いはありません。
で、それはともかく、「NTFS をオープンソース製品なりでサポートできる」事が、直ちにメリットになるとは言い切れません。現状において「NTFS が信頼す
ポイントがちょっとずれてる気もします。
他の Windows 機に接続してデータを抜き出そうとした場合、それは適切に ACLs の制約を受けた状態でアクセスすることとなります。例えば C:\Users\(ユーザ) フォルダ以下から Administrators の読み出し権限を取り除いておくと Administrators に所属しているユーザでも読み取る事はできません。
ただし Administrator ならアクセス権限の変更が可能 & 組み込み Administrator の GUID は固定であることから、Administrator としてアクセス権限を取得して読み出し可能ですが、これは別の問題です。
こうした HDD を他のマシンへ移す場合においては、BitLocker などのようなソリューションでないと安全性が担保できないのは同意です。
しかし、ACLs や MAC といったアクセス制御機構を利用していてもこれらを全く無視されたらそのままアクセス可能になります。Administrator への昇格等すら全く不要な状態で、他 OS 管理下の fs を操作できることになります。
例えば安全性を高めるために、今後 Windows プラットフォーム下では TPM 必須で自動的に EFS/BitLocker を有効にするように変更、ということがあったとしましょう。しかし、そこは「内部の実装レベル」の話であり、公開情報としてどのようにしたらアクセスできるようになるという情報は出す必要は全くないですよね。
しかし、これを公開した場合、マシンが盗難された時に EFS/BitLocker を使っていても、該当マシンで Knoppix を起動して ntfs-3g 改で TPM (秘密鍵) を利用して適切に暗号化を解除してデータを取り出せます、なんてのはデメリットが大きすぎじゃないでしょうか。
秘密鍵もセットで (マシンごと) 盗まれても、暗号化ロジックまで公開してなければ容易に取り出すことが出来ない方が (少なくともこの場合においては) マシだと考えられると思います。
確かに「アルゴリズムを秘密にしているから安全」理論ですが、わざわざクラッカーにトンネルを用意してあげる必要もないのも事実です。
# 結局「PC 起動パスワード」の設定位しか防衛手段はないとかなりそうです。
ちょっと読み間違えていたようです。
BitLocker のようなソリューションであっても、本気でデータを狙ってる相手に (一太郎の穴を見つけて攻撃してくる人たちとかに) ハードごと取られちゃうと結局防止策になってないんじゃない? というのがあります。この辺りだと BIOS/HDD パスワードですら全力で突破してきそうです。そこらのライトな (?) 泥棒なら十分に効果は得られると思いますが。
まぁ、そこまで言いだすと「どうしようもねーよ」とか「そもそも盗まれるなよ」という話になってしまいますが。
あ、泥棒は盗んだHDDを自分のパソコンに物理的に接続した場合に、制限ユーザーでアクセスしなければならないRFC作ってくれるってことですか?(゚∀゚)
なんという 4/1 RFC。
それはともかく、amd 使ってたら一般ユーザ権限でも ntfs-3g とかで自動的にマウントされてしまい、ユーザとしては一般ユーザのみの利用でアクセスしてませんか? ;)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
NTFS (スコア:2, 興味深い)
Re: (スコア:1, 参考になる)
NTFS の仕様を公開する (特にオープンソース製品により操作できる) 必要性が分かりません。今回の仕様公開における範囲は「OS や各製品群の仕様書を公開する」物ではないですよね。
もうちょっと突っ込んで言うと「Windows が NTFS を操作するために利用している API の一覧や関連パテント群」は公開されても、実装は公開されない。Windows をオープンソース化して丸裸にする訳ではなく、いわゆる「オープン化」する (プロトコルとなる API の仕様をすべて開示する) だけに過ぎないのではないでしょうか。
なので、今回の事で Windows の機能を利用してアクセスしている訳ではない ntfs-3g 等の実装が良くなる、というのは考えにくい話です。
つーか、操作を想定していない外部から自由に「読み書き」できるのは fs を破壊し、ACLs を無視する操作に繋がるので勘弁してくれって感じなのですが。
Re: (スコア:0)
これらをリバースエンジニアリングして作られているところのSambaとかrdesktop
(実際にはSambaは以前にもプロトコル文書を入手できたはずですが)
はプロトコルのドキュメンテーションを得られることで、
「もしかしたら」バグが修正できるかもしれません。
例えば世の中にSambaが無ければホームサーバという市場領域は形成されなかっただろうし、
企業内のWindowsネットワークも非常に制限された機能性しか提供できなかったでしょう。
同じように、NTFSをオープンソース製品なりなんなりでサポートするということは
MSにとってもそれなりの利益が有るはずです。
もっとも、今はNTFSよりもexFATとか別のネットワークテクノロジとかに注目して欲しいんだと思いますが。。
Re: (スコア:1, オフトピック)
良く考えてください。SMB(CIFS) も RDP も「プロトコル」です。NTFS は Windows における fs の「実装」でしかありません。公開されたプロトコルをベースに正しく通信を行う事ができれば十分であり、「実装の出来」でより良い実装が採用される競争が発生するのです。
*NIX であっても、NFS の下で現実に動いている fs が ufs/ext3/jfs/xfs... といったものは問いませんよね。それと何ら違いはありません。
で、それはともかく、「NTFS をオープンソース製品なりでサポートできる」事が、直ちにメリットになるとは言い切れません。現状において「NTFS が信頼す
Re:NTFS (スコア:0)
>逆に、Windows 系列のマシンが盗難に遭い、ACLs を無視して自由に「OS の外から」システムやデータを格納する fs に対し、自由に操作する手段を提供する可能性が上がる方が危険でしょう。
これでは暗号化でいうと「アルゴリズムを秘密にしているから安全」理論です。
実のところ、NTFS ACL を設定してあっても、他の Windows マシンにマウントすれば
読み書きできるはずですのでオープンソース NTFS 実装が出たところで危険性は変わりません。
これに対する根本の対策は、Vista で導入されている BitLocker になります。
(3rd パーティ製暗号化ソリューションでもかまいませんが。)
Re:NTFS (スコア:1, すばらしい洞察)
ポイントがちょっとずれてる気もします。
他の Windows 機に接続してデータを抜き出そうとした場合、それは適切に ACLs の制約を受けた状態でアクセスすることとなります。例えば C:\Users\(ユーザ) フォルダ以下から Administrators の読み出し権限を取り除いておくと Administrators に所属しているユーザでも読み取る事はできません。
ただし Administrator ならアクセス権限の変更が可能 & 組み込み Administrator の GUID は固定であることから、Administrator としてアクセス権限を取得して読み出し可能ですが、これは別の問題です。
こうした HDD を他のマシンへ移す場合においては、BitLocker などのようなソリューションでないと安全性が担保できないのは同意です。
しかし、ACLs や MAC といったアクセス制御機構を利用していてもこれらを全く無視されたらそのままアクセス可能になります。Administrator への昇格等すら全く不要な状態で、他 OS 管理下の fs を操作できることになります。
例えば安全性を高めるために、今後 Windows プラットフォーム下では TPM 必須で自動的に EFS/BitLocker を有効にするように変更、ということがあったとしましょう。しかし、そこは「内部の実装レベル」の話であり、公開情報としてどのようにしたらアクセスできるようになるという情報は出す必要は全くないですよね。
しかし、これを公開した場合、マシンが盗難された時に EFS/BitLocker を使っていても、該当マシンで Knoppix を起動して ntfs-3g 改で TPM (秘密鍵) を利用して適切に暗号化を解除してデータを取り出せます、なんてのはデメリットが大きすぎじゃないでしょうか。
秘密鍵もセットで (マシンごと) 盗まれても、暗号化ロジックまで公開してなければ容易に取り出すことが出来ない方が (少なくともこの場合においては) マシだと考えられると思います。
確かに「アルゴリズムを秘密にしているから安全」理論ですが、わざわざクラッカーにトンネルを用意してあげる必要もないのも事実です。
# 結局「PC 起動パスワード」の設定位しか防衛手段はないとかなりそうです。
Re: (スコア:0)
>なんてのはデメリットが大きすぎじゃないでしょうか。
TPMは(適切に運用されていれば)PINやTPMそのもののパスワードを付与して運用できるので、
別にNTFSが公開されたからと言って問題になる性質の物ではありません。
>確かに「アルゴリズムを秘密にしているから安全」理論ですが、わざわざクラッカーにトンネルを用意してあげる必要もないのも事実です。
この理論の適用には幾つかの問題があります。
- CaptiveNTFSのようなNTFS
Re: (スコア:0)
ACL はセキュリティとして機能しませんという指摘ですから、
ポイントがずれてるとうのは納得がいかないです。
NTFS を設計した人たちもハードウェア自体は保護されている場合を前提としています。
Administrator 権限があれば「不明な ACL」(つまり他のコンピュータで作成された ACL) の削除や
ファイルの所有権の変更が可能なのはStealthさん自信が理解されている通りです。
ですから、物理的な盗難があった時点でどうにでもなるのです。
あ、泥棒は盗んだHDDを自分のパソコンに物理的に接続した場合に、
制限ユーザーでアクセスしなければならないRFC作ってくれるってことですか?(゚∀゚)
Re:NTFS (スコア:1)
ちょっと読み間違えていたようです。
BitLocker のようなソリューションであっても、本気でデータを狙ってる相手に (一太郎の穴を見つけて攻撃してくる人たちとかに) ハードごと取られちゃうと結局防止策になってないんじゃない? というのがあります。この辺りだと BIOS/HDD パスワードですら全力で突破してきそうです。そこらのライトな (?) 泥棒なら十分に効果は得られると思いますが。
まぁ、そこまで言いだすと「どうしようもねーよ」とか「そもそも盗まれるなよ」という話になってしまいますが。
なんという 4/1 RFC。
それはともかく、amd 使ってたら一般ユーザ権限でも ntfs-3g とかで自動的にマウントされてしまい、ユーザとしては一般ユーザのみの利用でアクセスしてませんか? ;)
Re:NTFS (スコア:1)