OS X 10.11ではrootでも/usrや/bin以下に書き込みできない 62
ストーリー by hylom
これでrootが奪取されても大丈夫ですね 部門より
これでrootが奪取されても大丈夫ですね 部門より
あるAnonymous Coward 曰く、
10月1日にリリースされるOS Xの最新版「OS X 10.11 El Capitan」では、root権限でも/usrや/binなどのディレクトリにアクセスできないようになっており、これらのディレクトリにシステム関連以外のファイルがインストールされていた場合、アップデート時に別のディレクトリにそれらが移動されるようになっているとのこと（Appleちゃんねる）。
この仕組みは「rootless」と呼ばれているとのこと。Appleの「System Integrity Protection Guide」によると、保護対象となるのは/usrおよび/bin、/sbin、/System、/Applications/Utilities以下のディレクトリで、これらのディレクトリにはAppleのコード署名がされたシステムプロセスからしか書き込みが行えないという。ただし、/usr/local以下については対象外になっているとのこと。また、/Applicationsや/Libraryディレクトリ以下についても対象外。
つまり、今後は独自にビルドしたアプリケーションやライブラリなどは、/Applicationsおよび/Library、/usr/local以下にインストールするよう設定する必要があるということになり、多くのソフトウェアやデバイスドライバで影響が出そうである。
なお、rootlessを無効にするにはリカバリーモードでOSを起動してcsrutilコマンドでの設定を行う必要があるとのこと。
他の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)
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)
ごめんなさい、あなたが何を言ってるのか理解できない
というか無茶苦茶すぎる
念の為 (スコア:0)
Windowsしか知らない無知どもがピンぼけなこと言い出す前に書いておくと、
ほぼすべてのLinuxディストリビューションでは、すべてのパッケージはパッケージ管理システムの管理下に置くのが前提なので、
こういうしちめんどくさいことする必要もない。
自分で造ったシステムワイドなアプリケーションもパッケージ管理に合わせてパッケージ化して使用する。
OSXもそういうシステム用意しようと思えばできたはずなんだが。
何かのアプリケーションの参考書に sudo make install などと書いてあってもまともなユーザーならそんなことしない。
Re:念の為 (スコア:2)
え？ ./configure --prefix=/opt/hoge ; make all; sudo make install じゃないの？
Re:念の為 (スコア:1)
未だにソースから自分でコンパイルして入れるのが常識って人もいるよね。
自分は、どっちもありかと思っているけど
ソースからコンパイルするのが増えると、あとあと面倒が増えそうでw
Re: (スコア:0)
最近はdistributionがいろいろ用意してくれてるから
自分でコンパイルしたものを/optに入れるとかないな。
$HOME/opt/には細かいものがいろいろ入ってるが。
Re: (スコア:0)
自前のパッチがあって上流に取り込んでもらうにはあまりにも私的なものであればソースからコンパイル必須。
つっても一般化して他人にも有用っぽいパッチができたりして上流に取り込んでもらったことは何度かある。
Re: (スコア:0)
それでもバージョンアップ時、自前パッチ当てる手間を少しでも減らすために、パッケージ管理システム使ってローカルなパッケージとして維持してたり。
Re: (スコア:0)
Mac には MacPorts というものがあってのう。
未だにソースからコインパイルというものも少なくないんじゃよ。
え？それは自分でコンパイルとは言わないって？
しかし、./configure とかやってる時点で大して変わらんと思うがのう。
Re: (スコア:0)
普通 make buildworld
Re:念の為 (スコア:1)
その前提は崩壊しつつあるように思うけど。
各処理系(php, ruby, node.js, phtyhon etc)が勝手にパッケージ管理システム作っていて、結局好き勝手にファイルを置いている。
もう、makeなんて使わなくてもネットワークからパッケージ自動導入が当たり前。
それと、コード署名が検査されるのはそれなりにいいのでは。まあAppleだからできるというのはあるのかもしれないが。
新しいなり、Appleなりにかんがえられていて、しちめんどくさいだけではないと思うが。
# Linuxだって変なリポジトリからパッケージ持って来ればxcode騒ぎと変わらない事件が起きないとも限らない。
Re: (スコア:0)
訓練されたパッケージ管理システムは各処理系のパッケージ管理システムにパッチを当て、同期を図る。
よく訓練された各処理系のパッケージ管理システムはシステムのパッケージ管理システムに同化出来る。
Re: (スコア:0)
マジで言ってるのか、ボケてるのか。
Re:念の為 (スコア:1)
マジで呆けてるんだろ。
Re:念の為 (スコア:1)
おじいちゃん、そのソースはさっきコンパイルしたばかりでしょ…
Re: (スコア:0)
やたらと touch したがる爺さんか。
オレもそういうふうにボケたい。
Re: (スコア:0)
Re: (スコア:0)
最近はside by sideでDLL地獄回避とかいうらしいよ。
ホントかしらんけど。
Re: (スコア:0)
>こういうしちめんどくさいことする必要もない。
selinux とか、そういうしちめんどうくさいことのような気もするんだけど。
念の為、が何ら忠告として意味をなさない典型例 (スコア:0)
オプティマイズレベルは自分で書き換えないか？
＞sudo make install などと書いてあってもまともなユーザーならそんなことしない。
オレまともじゃなかったんだｗそういう人をバカにするような言われ方、初めてだぞ。
おまえがまともじゃないだけじゃないのか？
何をインストールするのか自分でチェックできる方法を無視して、お客に納品する人なんだ。すごいな。
それとも、バックアップを取っておいて、失敗したら戻すタイプ？
Re: (スコア:0)
10年前には、まだ見掛けたけど文字通り make install なんて今の時代にはありえないでしょ？
Re: (スコア:0)
いや、やりませんが。＞ローカルパッケージ作って。
Re: (スコア:0)
いや、やりましょうよ。
それともスクリプトで自動化すると手抜きするなって怒るタイプ？
Re: (スコア:0)
いまだに、こんなのいるんだ。
無駄な仕事をして、仕事した気になってるタイプだ。
知識も10年は世間から遅れてるうえに、ルールを守る気もないやつ。
外注で、こんなの来たら即日で切るな。
Re: (スコア:0)
あぁ、ローカルパッケージ作ったくらいで仕事した気になっているヤツいるよな。
Re: (スコア:0)
＞ほぼすべてのLinuxディストリビューションでは、すべてのパッケージはパッケージ管理システムの管理下に置くのが前提なので、
こういうしちめんどくさいことする必要もない。
ユーザの良識を信じてるってだけで、他の選択肢を使えないよう強制するってことじゃないので、
rootlessが対応する問題とはまた別だと思います。
RedHat系だって、「RPMがないソフトウェア」をインストールする場合、
RPMをbuildせず、直接make; make installして使ってる人もいるし。
rm -rf /usr (スコア:0)
よく分からないが、root で rm -rf /usr とかやっても大丈夫ってことかな?
Re: (スコア:0)
システムは大丈夫でも/usr/local以下は保護されてないから無条件に大丈夫とも言えない気がする。