アカウント名:
パスワード:
OSのパッケージング管理下に無いものが/usr/binとかに入っていると誤動作の元。
純正バイナリは/usr以下,サードパーティは/usr/local以下に入れるというのは,UNIX(?)における原始的で古典的なパッケージ管理法だと思います
今時のUNIX(?)ならパッケージ管理システムが必ず用意されていて例えば debian 系だったらfind /usr/bin -type f | xargs dpkg -S > /dev/nullredhat系だったらfind /usr/bin -type f | xargs rpm -qf > /dev/nullBSD系だったらportでごにょごにょを実行するだけで,簡単にパッケージング管理下にないファイルの一覧が見れますそして一覧をチェックして,不要なファイルが見つかった場合は, xargs sudo rm で消すだけです
一方,WindowsやOS Xではこのような機能が十分には整備されていません.だからこそ,/usr以下を書き込み禁止にする,という古典的な方法をとるしか術が無いのかも知れません
> 今時のUNIX(?)ならパッケージ管理システムが必ず用意されていて
「?」をつけてるのである程度意識されてるようですが、パッケージシステムで管理されていても、ディレクトリ分けはそれなりに有用ですし、行われてますよ。
Solaris 含む SVR4 系の追加パッケージ: /optFreeBSD で ports で追加したパッケージ: /usr/localNetBSD で pkgsrc で追加したパッケージ: /usr/pkg
といった感じであり、基本システムが使う / や /usr とは別ディレクトリにしてあります。
> パッケージシステムで管理されていても、ディレクトリ分けはそれなりに有用ですし、行われてますよ。元コメが言いたいのは、「有用な古典的なディレクトリ分けが行われていて」「なおかつ、パッケージ管理システムを使って紛れ込んだファイルを発見することも出来る」というコメントだと思いますが。
BSD系だったらportでごにょごにょ
これかな? https://www.freebsd.org/doc/ja/books/handbook/updating-upgrading-freeb... [freebsd.org] でもpackagesの話なら https://www.freebsd.org/cgi/man.cgi?query=pkg-check&sektion=8&... [freebsd.org] でも上のからの話なら https://www.freebsd.org/cgi/man.cgi?query=pkg-wh [freebsd.org]
古典的だけど、決定的でもあるかな書き込み禁止すりゃチェックする必要も無いし
へー、UNIXってすすんでるねー。
で、"find /usr/bin -type f | xargs dpkg -S > /dev/null"なる先進的な呪文は、既存のファイルと同じ名前のバイナリにマルウェアを仕込むという古典的な攻撃をどうやって回避または探知してくれるのでしょうか?
1) あなたの書いたこの先進的なコマンドは新しいバイナリの出現しか探知出来ず、既存のバイナリを改竄する攻撃には無力。よってほぼ無意味。せめてdebsums(1)くらい使いましょう。2) そうやって改善しても、このコマンドはどうや
WindowsのVirtualStoreのパクリやで。
言われりゃそうだな
Virtualstoreは簡単にオフれちゃうからなぁ。。まあ、下手にそういった仕組み作ると居座り続けるのがいるから、アップルはバサッときりすてたと。まあ、/sbinに謎ファイルあったら困るからいいかな?
Unixの/binとか/sbinは、WindowsだとProgramFilesじゃなくてSystemの方に相当する。でも、Windowsの方はいまさらSystemの書き込みを禁止できないもんだから、ドライバやアプリなんかが平気で汚すようになってしまっている。
/binと/sbinと/usr/binと/usr/sbinと/usr/local/binと/usr/local/sbinの使い分けってどのように考えてますか?
これでも読めhttps://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [wikipedia.org]
> https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [wikipedia.org]
これって、事実上 Linux distro 間で決めた標準であって、Linux 以外で使ってるところはないから、注意は必要だけどね。
たとえば NetBSD はhttps://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sekti... [freebsd.org]みたいな感じ。BSD系は全部 hier(7) なので、このページのメニューで OS 変更すれば、参照できる。
Linuxと比べた大きな違いとして、・/usr/lib/アプリ/ みたいなデータファイルはない。/usr/lib/ に置くのはライブラリだけ。・/var/lib/ はそもそも存在しない。・データは /usr/share か /usr/libdata か /var/ の下の適切な場所に置く。・Linuxで/usr/lib/にあるような実行ファイルは、/usr/libexec/ に置く。みたいな点がある。(この辺は *BSD 共通)
元々、/var その他は、ディスクレス構成とかをサポートするために、1980年代の BSD BOF で、商業ベンダーとかも含めて決めたもので、経緯的に BSD が一番きれいな構成になってるんだよね。
Linux が生まれたのはそれより後なんだけど、歴史的経緯を引きずった商業ベンダーの使ってる構成を真似たから、/usr/lib の下とかだいぶ汚いし、/var/lib みたいに変なディレクトリもあったりする。
まあ *BSD でも、Linux で生まれたアプリケーションを動かすために、結局 /var/lib を掘ったりして、ディレクトリ構造が汚くなってガックリとかするわけだけど。
/bin, /sbin, /usr/bin, /usr/sbinは、yumに任せる。自分では触らない。/usr/localは使わない。自分でインストールするものは、/homeか/opt。
OSX でもやろうと思えば昔から同じようなことはできたはず。なんで新しい仕組みを作ったんだろう?
# chflags schg filename
とすれば、そのファイルは root でも変更できなくなる。さらに、
# sysctl kern.securelevel=1
とすれば、schg フラグをはずすこともできなくなる。
このあたりの機能はかなり古い BSD に由来するので、初期の OSX からずっと使えてたはず。使ったことないけど。
それやっちゃうとOSの更新とかまで出来なくなったりしません?
rebootしてnoschgして更新、再度schgしてsecurelevel=1ってのを手でやると間違えがちなのでスクリプト化、ってrebootとか面倒臭いというならそこまでしないし、それで安心なの?ってのもごもっともなのでsnort入れるとか。そこらへんがセキュリティポリシーというやつ。
ディレクトリに対して使えたっけ?
つかえるよー
# mkdir hoge# chflags schg hoge# echo fuga > hoge/hogehoge/hoge: Operation not permitted.
Vista以降のVirtualStoreも知らんのか…
WFP(Windows ファイル保護)は実行ファイル・DLLの保護であってOSのファイル保護じゃないです。似てません。それと、UACはユーザーアカウント制御であってOSのファイル保護じゃないです。こちらは全く別物。
そんなんで「大揉め必至なので厳しいでしょう」とか言われても、何を言っているのですかとしか
> WFP(Windows ファイル保護)は実行ファイル・DLLの保護であってOSのファイル保護じゃないです。似てません。
思いっきり似ててワロタ。
ごめんなさい、あなたが何を言ってるのか理解できないというか無茶苦茶すぎる
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
他のOSにも導入して欲しい (スコア:0)
OSのパッケージング管理下に無いものが/usr/binとかに入っていると誤動作の元。
Re:他のOSにも導入して欲しい (スコア:5, 参考になる)
純正バイナリは/usr以下,サードパーティは/usr/local以下に入れるというのは,
UNIX(?)における原始的で古典的なパッケージ管理法だと思います
今時のUNIX(?)ならパッケージ管理システムが必ず用意されていて
例えば debian 系だったら
find /usr/bin -type f | xargs dpkg -S > /dev/null
redhat系だったら
find /usr/bin -type f | xargs rpm -qf > /dev/null
BSD系だったら
portでごにょごにょ
を実行するだけで,簡単にパッケージング管理下にないファイルの一覧が見れます
そして一覧をチェックして,不要なファイルが見つかった場合は, xargs sudo rm で消すだけです
一方,WindowsやOS Xではこのような機能が十分には整備されていません.
だからこそ,/usr以下を書き込み禁止にする,という古典的な方法をとるしか術が無いのかも知れません
Re:他のOSにも導入して欲しい (スコア:1)
> 今時のUNIX(?)ならパッケージ管理システムが必ず用意されていて
「?」をつけてるのである程度意識されてるようですが、
パッケージシステムで管理されていても、ディレクトリ分けはそれなりに有用ですし、行われてますよ。
Solaris 含む SVR4 系の追加パッケージ: /opt
FreeBSD で ports で追加したパッケージ: /usr/local
NetBSD で pkgsrc で追加したパッケージ: /usr/pkg
といった感じであり、基本システムが使う / や /usr とは別ディレクトリにしてあります。
Re: (スコア:0)
> パッケージシステムで管理されていても、ディレクトリ分けはそれなりに有用ですし、行われてますよ。
元コメが言いたいのは、「有用な古典的なディレクトリ分けが行われていて」
「なおかつ、パッケージ管理システムを使って紛れ込んだファイルを発見することも出来る」
というコメントだと思いますが。
Re: (スコア:0)
BSD系だったら
portでごにょごにょ
これかな?
https://www.freebsd.org/doc/ja/books/handbook/updating-upgrading-freeb... [freebsd.org]
でもpackagesの話なら
https://www.freebsd.org/cgi/man.cgi?query=pkg-check&sektion=8&... [freebsd.org]
でも上のからの話なら
https://www.freebsd.org/cgi/man.cgi?query=pkg-wh [freebsd.org]
Re: (スコア:0)
古典的だけど、決定的でもあるかな
書き込み禁止すりゃチェックする必要も無いし
Re: (スコア:0)
一方,WindowsやOS Xではこのような機能が十分には整備されていません.
だからこそ,/usr以下を書き込み禁止にする,という古典的な方法をとるしか術が無いのかも知れません
へー、UNIXってすすんでるねー。
で、"find /usr/bin -type f | xargs dpkg -S > /dev/null"なる先進的な呪文は、既存のファイルと同じ名前のバイナリにマルウェアを仕込むという古典的な攻撃をどうやって回避または探知してくれるのでしょうか?
1) あなたの書いたこの先進的なコマンドは新しいバイナリの出現しか探知出来ず、既存のバイナリを改竄する攻撃には無力。よってほぼ無意味。せめてdebsums(1)くらい使いましょう。
2) そうやって改善しても、このコマンドはどうや
Re: (スコア:0)
WindowsのVirtualStoreのパクリやで。
Re: (スコア:0)
言われりゃそうだな
Re: (スコア:0)
Virtualstoreは簡単にオフれちゃうからなぁ。。
まあ、下手にそういった仕組み作ると居座り続けるのがいるから、
アップルはバサッときりすてたと。
まあ、/sbinに謎ファイルあったら困るからいいかな?
Re:他のOSにも導入して欲しい (スコア:1)
Unixの/binとか/sbinは、WindowsだとProgramFilesじゃなくてSystemの方に相当する。
でも、Windowsの方はいまさらSystemの書き込みを禁止できないもんだから、ドライバやアプリなんかが平気で汚すようになってしまっている。
Re: (スコア:0)
(%LOCALAPPDATA%\VirtualStore以下に保存される)
つか今時はユーザーもProgram FilesもSystemも昇格が必要なので普通には書けないよ。
hostsも管理者コマンドプロンプトとかからエディタ起動するとか別箇所で編集してコピーする(その時ダイアログでコピー行為を昇格して行う)と
Re: (スコア:0)
Libraryも「/System/Library」「/Library」「$HOME/Library」と用途別に用意されてましたし。
*.appで必要なファイルをひとまとめにできて、せいぜい$HOME/Library/Preferences/に
設定ファイルができる程度でしたから。
自分なんかは、インストーラーが勝手に入れるやつ以外は、$HOME/Applicationsに
入れるようにしてましたし。
今はWindows10使ってますけど、フォントとか、最初から入ってるやつと後から入れたやつの
区別がつかなくて困ってます。実際のフォントファイルがどこに入ってるのかは知りませんけど。
Re: (スコア:0)
/binと/sbinと/usr/binと/usr/sbinと/usr/local/binと/usr/local/sbinの使い分けってどのように考えてますか?
Re:他のOSにも導入して欲しい (スコア:2, 興味深い)
これでも読め
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [wikipedia.org]
Re:他のOSにも導入して欲しい (スコア:1)
> https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [wikipedia.org]
これって、事実上 Linux distro 間で決めた標準であって、
Linux 以外で使ってるところはないから、注意は必要だけどね。
たとえば NetBSD は
https://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sekti... [freebsd.org]
みたいな感じ。
BSD系は全部 hier(7) なので、このページのメニューで OS 変更すれば、参照できる。
Linuxと比べた大きな違いとして、
・/usr/lib/アプリ/ みたいなデータファイルはない。/usr/lib/ に置くのはライブラリだけ。
・/var/lib/ はそもそも存在しない。
・データは /usr/share か /usr/libdata か /var/ の下の適切な場所に置く。
・Linuxで/usr/lib/にあるような実行ファイルは、/usr/libexec/ に置く。
みたいな点がある。(この辺は *BSD 共通)
元々、/var その他は、ディスクレス構成とかをサポートするために、
1980年代の BSD BOF で、商業ベンダーとかも含めて決めたもので、
経緯的に BSD が一番きれいな構成になってるんだよね。
Linux が生まれたのはそれより後なんだけど、歴史的経緯を引きずった
商業ベンダーの使ってる構成を真似たから、/usr/lib の下とかだいぶ汚いし、
/var/lib みたいに変なディレクトリもあったりする。
まあ *BSD でも、Linux で生まれたアプリケーションを動かすために、
結局 /var/lib を掘ったりして、ディレクトリ構造が汚くなってガックリとか
するわけだけど。
Re: (スコア:0)
/bin, /sbin, /usr/bin, /usr/sbinは、yumに任せる。自分では触らない。
/usr/localは使わない。
自分でインストールするものは、/homeか/opt。
Re: (スコア:0)
OSX でもやろうと思えば昔から同じようなことはできたはず。
なんで新しい仕組みを作ったんだろう?
# chflags schg filename
とすれば、そのファイルは root でも変更できなくなる。
さらに、
# sysctl kern.securelevel=1
とすれば、schg フラグをはずすこともできなくなる。
このあたりの機能はかなり古い BSD に由来するので、
初期の OSX からずっと使えてたはず。使ったことないけど。
Re:他のOSにも導入して欲しい (スコア:2)
それやっちゃうとOSの更新とかまで出来なくなったりしません?
Re: (スコア:0)
rebootしてnoschgして更新、再度schgしてsecurelevel=1
ってのを手でやると間違えがちなのでスクリプト化、
ってrebootとか面倒臭いというならそこまでしないし、
それで安心なの?ってのもごもっともなのでsnort入れるとか。
そこらへんがセキュリティポリシーというやつ。
Re: (スコア:0)
ディレクトリに対して使えたっけ?
Re: (スコア:0)
つかえるよー
# mkdir hoge
# chflags schg hoge
# echo fuga > hoge/hoge
hoge/hoge: Operation not permitted.
Re:他のOSにも導入して欲しい (スコア:1)
Vista以降のVirtualStoreも知らんのか…
WFP(Windows ファイル保護)は実行ファイル・DLLの保護であってOSのファイル保護じゃないです。似てません。
それと、UACはユーザーアカウント制御であってOSのファイル保護じゃないです。こちらは全く別物。
そんなんで「大揉め必至なので厳しいでしょう」とか言われても、何を言っているのですかとしか
Re: (スコア:0)
ファイル単位での署名でシステムファイルが変更されないことを保証する枠組みを用意するのが難しい(?)から、MacOS ではフォルダ単位の管理に逃げたと。
Re: (スコア:0)
> WFP(Windows ファイル保護)は実行ファイル・DLLの保護であってOSのファイル保護じゃないです。似てません。
思いっきり似ててワロタ。
Re: (スコア:0)
ごめんなさい、あなたが何を言ってるのか理解できない
というか無茶苦茶すぎる