アカウント名:
パスワード:
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 のようなソリューションであっても、本気でデータを狙ってる相手に (一太郎の穴を見つけて攻撃してくる人たちとかに) ハードごと取られちゃうと結局防止策になってないんじゃない? というのがあります。この辺りだと BIOS/HDD パスワードですら全力で突破してきそうです。そこらのライトな (?) 泥棒なら十分に効果は得られると思いますが。
まぁ、そこまで言いだすと「どうしようもねーよ」とか「そもそも盗まれるなよ」という話になってしまいますが。
あ、泥棒は盗んだHDDを自分のパソコンに物理的に接続した場合に、制限ユーザーでアクセスしなければならないRFC作ってくれるってことですか?(゚∀゚)
なんという 4/1 RFC。
それはともかく、amd 使ってたら一般ユーザ権限でも ntfs-3g とかで自動的にマウントされてしまい、ユーザとしては一般ユーザのみの利用でアクセスしてませんか? ;)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
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: (スコア:0)
>逆に、Windows 系列のマシンが盗難に遭い、ACLs を無視して自由に「OS の外から」システムやデータを格納する fs に対し、自由に操作する手段を提供する可能性が上がる方が危険でしょう。
これでは暗号化でいうと「アルゴリズムを秘密にしているから安全」理論です。
実のところ、NTFS ACL を設定してあっても、他の Windows マシンにマウントすれば
読み書きできるはずですのでオープンソース NTFS 実装が出たところで危険性は変わりません。
これに対する根本の対策は、Vista で導入されている BitLocker になります。
(3rd パーティ製暗号化ソリューションでもかまいませんが。)
Re: (スコア:1, すばらしい洞察)
ポイントがちょっとずれてる気もします。
他の Windows 機に接続してデータを抜き出そうとした場合、それは適切に ACLs の制約を受けた状態でアクセスすることとなります。例えば C:\Users\(ユーザ) フォルダ以下から Administrators の読み出し権限を取り除いておくと Administrators に所属しているユーザでも読み取る事はできません。
ただし Administrator ならアクセス権限の変更が可能 & 組み込み Administrator の GUID は固定であることから、Administrator としてアクセス権限を取得して読み出し可能ですが、これは別の問題です。
こうした HDD を他の
Re:NTFS (スコア:0)
ACL はセキュリティとして機能しませんという指摘ですから、
ポイントがずれてるとうのは納得がいかないです。
NTFS を設計した人たちもハードウェア自体は保護されている場合を前提としています。
Administrator 権限があれば「不明な ACL」(つまり他のコンピュータで作成された ACL) の削除や
ファイルの所有権の変更が可能なのはStealthさん自信が理解されている通りです。
ですから、物理的な盗難があった時点でどうにでもなるのです。
あ、泥棒は盗んだHDDを自分のパソコンに物理的に接続した場合に、
制限ユーザーでアクセスしなければならないRFC作ってくれるってことですか?(゚∀゚)
Re:NTFS (スコア:1)
ちょっと読み間違えていたようです。
BitLocker のようなソリューションであっても、本気でデータを狙ってる相手に (一太郎の穴を見つけて攻撃してくる人たちとかに) ハードごと取られちゃうと結局防止策になってないんじゃない? というのがあります。この辺りだと BIOS/HDD パスワードですら全力で突破してきそうです。そこらのライトな (?) 泥棒なら十分に効果は得られると思いますが。
まぁ、そこまで言いだすと「どうしようもねーよ」とか「そもそも盗まれるなよ」という話になってしまいますが。
なんという 4/1 RFC。
それはともかく、amd 使ってたら一般ユーザ権限でも ntfs-3g とかで自動的にマウントされてしまい、ユーザとしては一般ユーザのみの利用でアクセスしてませんか? ;)