web-dev-qa-db-ja.com

Linuxファイルのアクセス許可をだますことはできますか?

今日この例に出くわし、Linuxファイルのアクセス許可が情報を非表示にするためにどの程度信頼できるか疑問に思いました

$ mkdir fooledYa
$ mkdir fooledYa/ohReally
$ chmod 0300 fooledYa/
$ cd fooledYa/
$ ls 
>>> ls: cannot open directory .: Permission denied
$ cd ohReally
$ ls -ld .
>>> drwxrwxr-x 2 user user 4096 2012-05-30 17:42 .

現在、私はLinux OSのエキスパートではないので、OSの観点からはこれが完全に論理的であることを誰かが説明してくれることは間違いありません。しかし、私の質問はまだ残っています、OSをハックするのではなく、だまして、想定外のファイル/ inode情報を表示させることは可能ですか?コマンドchmod 0000 fooledYaを発行した場合、経験豊富なプログラマーがfooledYa/ohReally/foo.txtなどのファイルを読み取るためのいくつかの方法を見つけることができますか?

6
puk
$ ls -lhd fooledYa/
d-wx------ #snip

まず最初に、ディレクトリに書き込み(新しいエントリを作成)、ディレクトリに(cd)を実行できます。ただし、ディレクトリを読み取ることができません。つまり、直感的ではありません。

Unixシステムでディレクトリを操作する場合、ディレクトリはポインタエントリとは異なる inodes を指します。ディレクトリツリーをたどって参照を追跡できるかどうかは、eXecuteビットによって制御されます。ツリーの下のディレクトリレベルごとに、オペレーティングシステムは実行ビットをチェックしてから次のレベルに降格します。

一方、Readビットは、iノードの内容へのアクセスを制御します。ファイルシステムで参照できるものはすべてiノードエントリです。ディレクトリまたはファイルは、iノードを指します。

ls -ldi fooledYa/
121100226 d-wx------ #snip

この場合、ディレクトリinodeは121100226です。読み取り許可は、ユーザー空間でそのiノードファイルにアクセスしてその内容を読み取ることができるかどうかを示します。ディレクトリiノードの内容は、他のファイルへの参照です。カーネルは常にそれを読み取ることができます。ユーザーとしてのあなたは、その中のエントリーに関するカーネルの決定によって制御されます。

したがって、lsは内容を読み取って(Readフラグでチェックされるように)何があるかを教えようとするため、拒否されます。ただし、eXecute権限はまだあるため、ファイルの上のディレクトリすべてにeXecuteへのアクセスを許可するかどうかに関係なく、カーネルは指定したファイルに移動できます。私はそれらを読んで何の参照を見ることができます。

したがって、ディレクトリについて要約するには、実行をマスター権限として考えます。これがないと、ディレクトリにアクセスして何もできません。その後、それらを2列のファイルとして考えます。読み取り権限がある場合は、エントリを表示できます。書き込み権限がある場合は、エントリを追加または削除できます。これら2つの権限がなくても実行できる場合は、リスト内のエントリを参照できますが、リストを読み取ることはできません。

これは、inodeの良い例であり、ディスク参照上のディレクトリ参照とファイルブロックを表す方法です http://teaching.idallen.com/dat2330/04f/notes/links_and_inodes.html

13
Jeff Ferland

予想通り、多くの人があなたの例が完全に論理的である方法を説明しました。 「設計どおりに機能します。」

あなたの質問に答えるためにOSをだまして、想定されていないファイル/ inode情報を表示させることができた場合、カーネルのバグとなる可能性があります。ファイルのアクセス権はiノードに関連付けられていますそれ自体があり、実際にファイルを開こうとしたときに適用されます。他の回答から取り上げなかった場合、ディレクトリにはファイルと同様にiノードがあることを指摘します。これは、ディレクトリに適用した場合に、アクセス許可がわずかに(または大幅に)異なることを意味します。

ファイルのアクセス許可は、元のUnixセキュリティメカニズムであり、Unix/Linuxセキュリティの不可欠な部分です。あなたがシステムをだましてしまったように見えるあなたが準備できるどんなシナリオでも、正しい振る舞いが何であるかをあなたが理解していない場合はほぼ確実です。ハッキングにおいても、セキュリティを回避する正当な方法を見つけた場合、それは重大なセキュリティバグと見なされ、パッチ適用の最優先事項の1つになります。

たとえば、読み取ることができないはずのファイルの内容を読み取ることができた場合、すべてのユーザーの(ハッシュされた)パスワードとシステムのプライベートsshキーを盗むことができます。システム上のすべてのユーザーのプライベートssh鍵(できれば暗号化されます)、およびデバイスのiノードを介してシステムメモリの内容全体(およびその他)を読み取ります。想定外のファイル情報を読み取ることができれば危険は少なくなりますが、それでも重大な違反と見なされます。

2
Old Pro

私はあなたをだましている特定のことは、/の下のすべてのディレクトリがそれに少なくとも2つのリンクを持っているということです:親のディレクトリのエントリとそれ自体の中の.(および子ディレクトリからの..リンク)。 ls -ld .と入力すると、現在のディレクトリ(読み取り権限がある)の.リンクが表示されます。親ディレクトリ(読み取り権限がない)から現在のディレクトリへのリンクは表示されません。

+ xの場合、それがディレクトリでどのように機能するかを理解する最も簡単な方法は、ディレクトリに「入る」許可であることがわかりました。 + xがなければ、読み取りおよび書き込みアクセス権があっても、ディレクトリにアクセスすることはできません。ディレクトリへのアクセスが許可されていない場合、+ xが設定されているかどうかに関係なく、サブディレクトリにアクセスすることはできません。したがって、fooledYa/ohReally/foo.txtがあり、fooledYaがchmod 0000である場合、他のACLシステムがファイルモードをオーバーライドしないと想定すると、ルートへのパスがわかっていても、ルートだけがohReally/にアクセスしたりfoo.txtを開いたりできます。ディレクトリの内容をリストする必要があります。

これらの権限の奇妙な点の1つは、ディレクトリが+ xではなく+ rの場合、ディレクトリの内容を読み取る権限があるため、外部から「覗き込み」、ディレクトリ内のファイルのリストを読み取ることができますが、+はありません。 x個々のファイルにアクセス(stat)するためのディレクトリに入ることができなくなります。したがって、このようなディレクトリをls -lしようとすると、ファイル名が取得されますが、ファイルサイズ、モード、所有権などの他のすべてのフィールドは?マークになります。

1
DerfK