El Capitanの「Rootless」機能について学んだところですが、「rootユーザはいません」、「何も変更することはできません」などのことを聞いています。 /System "そして"私たちが根付くことができないので世界は終わるでしょう "＃：。
技術レベルでのEl Capitanの「Rootless」機能は何ですか？ユーザーエクスペリエンスと開発者エクスペリエンスにとって実際にはどういう意味ですか？意志 sudo -s それでもうまくいく、そしてもしそうなら、どのようにシェルを使うのか root 変化する？
回答:
まず、「rootless」という名前は、まだrootアカウントがあり、まだアクセスできるので誤解を招く可能性があります（正式名の「System Integrity Protection」の方が正確です）。実際にはrootアカウントの権限を制限しているので、rootになってもシステムを完全に制御することはできません。基本的には、マルウェアがrootアクセスを取得するのは非常に簡単であるということです（たとえば、ユーザーに認証ダイアログを表示してユーザーに管理者パスワードを反射的に入力させるなど）。 SIPは別の保護層を追加します。マルウェアが根付いても侵入することはできません。これの悪い部分は、もちろん、それはあなたが意図的にやっていることにも適用されなければならないということです。しかし、それがrootに課す制限はそれほど悪くありません。それらは、ほとんどの「通常の」システムカスタマイズを妨げるものではありません。
これはrootからでさえも制限するものです：
あなたは何も変更することはできません /System、 /bin、 /sbinまたは /usr （を除く /usr/local ;または組み込みのアプリやユーティリティのいずれか。これらの領域を変更できるのは、インストーラとソフトウェアのアップデートだけです。さらには、アップルが署名したパッケージをインストールするときにのみ修正できます。しかし通常のOS Xスタイルのカスタマイズはうまくいくので /Library （または ~/Libraryまたは /Applications ）、およびunixスタイルのカスタマイズ（例：自作）が入ります /usr/local （または時々 /etc または /opt ）これは大したことではないはずです。また、起動ディスクへのブロックレベルの書き込みも防止されるため、この方法では回避できません。
制限されたディレクトリの完全なリスト（および以下のような例外 /usr/local 他にも /System/Library/Sandbox/rootless.conf。もちろん、このファイル自体は制限された場所にあります。
El Capitanにアップグレードすると、「無許可の」ファイルは制限区域から /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/。
デバッグ（あるいはそれらがどの動的ライブラリをロードするか、あるいは他のものを変更する）のようなことのためにシステムプロセス（例えば、それらのシステムロケーションから実行しているもの）にアタッチすることはできません。繰り返しますが、大したことはありません。開発者はまだ自分のプログラムをデバッグできます。
これは、内蔵のAppleアプリ（特にFinder）にコードを挿入するような重要なことをブロックします。それはまたそれを意味します dtrace システム監視用のツール opensnoop ）を監視することはできません多くのシステムプロセスについて報告します。
適切に署名されていない限り（つまり、アップルまたはアップル認定の開発者による）、カーネル拡張機能（kext）をロードすることはできません。これは、kext署名を強制するための古いシステム（およびそれを迂回するための古い方法）に代わるものであることに注意してください。しかし、v10.10.4以降、Appleは サードパーティSSDのトリムサポートを有効にする方法がありました 符号なしのkextを使う第1の理由はなくなりました。
あなたがこれらの制限を望まないのであれば - これが許す範囲を超えてあなたのシステムを修正したいからか、あるいは開発中であるためか。これらの制限の下では実用的ではないkextのようなものをデバッグするには、SIPをオフにすることができます。現在これは回復モードに再起動し、コマンドを実行する必要があります csrutil disable （そしてあなたは同様にそれを再び有効にすることができます csrutil enable ）
しかし、一時的な場合でも、SIPを無効にする前に停止して検討してください。本当に無効にする必要がありますか。それとも、必要な操作を実行するためのより良い（SIP準拠）方法がありますか。あなたは本当に何かを修正する必要がありますか /System/Library または /bin または何でも、またはそれはのようなより良い場所に行くことができます /Library または /usr/local/bin 等？ SIPは慣れていないと制約を「感じる」ことがあり、それを無効にする正当な理由がいくつかありますが、それを強制するものの多くはとにかく本当にベストプラクティスです。
参考文献および詳細情報： 「セキュリティとあなたのアプリ」に関するWWDCのプレゼンテーション 、 quora.comのEldad Eilamによる良い説明 、 El CapitanによるArs Technicaのレビュー 、 と SIPに関するアップルのサポート記事 、そして Rich Troutonによるディープダイビング （誰も投稿した この質問への回答 ）
kext あるいは自分自身でバイナリを作成し、それをコマンドラインで実行して制限のないアクセスに戻ることができるようにするためのものです。
私にとっては、DTraceが機能しなくなったことを意味します。
DTraceはLinuxのptrace / straceに似ています。プロセスがカーネルに何を言っているのかを確認できるという点です。プロセスがファイルを開く、ファイルを書き込む、またはポートを開くなどの必要があるたびに、カーネルに問い合わせる必要があります。 Linuxでは、この監視プロセスは "userland"のカーネルの外側で行われるため、パーミッションはきめ細かく設定されています。ユーザは自分自身のアプリケーションを監視することができます（バグの修正、メモリリークの発見など）が、他のユーザのプロセスを監視するにはrootになる必要があります。
しかし、OSX上のDTraceはカーネルレベルで機能するため、はるかに高性能で強力になります。ただし、プローブをカーネルに追加するためにはrootアクセスが必要であり、したがって何でも実行できます。ユーザーはrootにならないと自分のプロセスを追跡できませんが、rootとして自分のプロセスを監視できるだけでなく、実際にはシステム上のすべてのプロセスを同時に監視できます。たとえば、（iosnoopを使って）ファイルを見て、どのプロセスがそれを読んでいるかを見ることができます。これはマルウェアを検出するためのこれまでで最も便利な機能の1つです。カーネルはネットワークIOも扱いますので、同じことが当てはまります。 Wiresharkは、異常なネットワークアクティビティを検出します。DTraceは、データがカーネル自体としてシステムに埋め込まれている場合でも、データを送信しているプロセスに通知します。
しかしEl Capitanの時点では、Appleは故意にDTraceの動作を妨げてきました。これは、SIPが制限するものとして特にターゲットを絞って選び出したからです。なぜ彼らはこれをするのでしょうか？さて、以前のAppleはカーネルとDTraceを修正して、一部のプロセスがDTraceによる監視をオプトアウトできるようにしました（一部のプロセスはルートとしても限界から外れていたため、当時は多くのセキュリティ研究者を動揺させました）。理論的には誰かがDTraceを使用してプロセスのメモリからDRMが適用されていないデータを取得する可能性があるためです。
しかし、研究者が仕事を続けることを可能にする重要な回避策があり、それはこのオプトアウトフラグを無視するようにカーネルを修正することでした。そのため、これらのプロセスではDTraceを使用できます。これは実際には本当に素晴らしいものでした。なぜなら、プログラムは検出されないようにしようとしているため、このno-DTraceフラグが表示されているからです。 Appleや悪者たちが隠したがっていたものは、今や明白なものになっていた...
しかし、今はうまくいきません。ですから、これはあなたにどのような影響を与えますか？ まあ、それは直接的にも間接的にもあなたに影響を与えます。直接、それはあなたのシステムを監視するあなたの能力を制限するでしょう。多数の低レベルのシステム管理および監視ツール（高レベルのツールの基盤）は機能しなくなります。しかし間接的な影響ははるかに大きくなります - セキュリティの専門家は最悪の種類の脅威を検出するためにシステムへの深いアクセスに頼ります。これ以上できないのです。マルウェアを分析するときには、デバッガやハニーポットで実行されていることがわからないことが重要です。 SIPを無効にすると、悪意のあるユーザーからもAppleからも、このシステムが監視されていることをすべてのソフトウェアに知らせます。これ以上ウォッチャーを見ていません。 SIPがセキュリティに関するものであれば、彼らはrootについてユーザーを教育することができた - 代わりに彼らはそれを削除した。結局、これはAppleがルートパスワードの「万能の問題」のセキュリティバリアを「万能の問題」のSIP保護メカニズムに置き換えたことを意味する。またはあなたのソーシャルエンジニアリングが得意な場合は、再起動したルートパスワード...
これもあります： 
System Integrity Protection（SIP）は、システムファイルやプロセスが第三者によって変更されるのを防ぐことを目的とした総合的なセキュリティポリシーです。これを実現するために、次のような概念があります。
ファイルシステム保護
SIPは、Apple以外の関係者が特定のディレクトリに格納されているディレクトリおよびファイルを追加、削除、または変更することを防ぎます。
/bin
/sbin
/usr
/System
開発者がアクセスできるディレクトリは次のとおりです。
/usr/local
/Applications
/Library
~/Library
内のすべてのディレクトリ /usr を除いて /usr/local SIPによって保護されています。
Apple独自の認証局によって署名されているインストーラパッケージを介して、SIPで保護されたファイルやディレクトリを追加、削除、変更することが可能です。これにより、Appleは既存のSIP保護を変更する必要なしに、OSのSIP保護された部分に変更を加えることができます。
問題の認証局は、アップルが独自に使用するために予約されています。開発者IDで署名されたインストーラパッケージは、SIPで保護されたファイルまたはディレクトリを変更することはできません。
保護するディレクトリを定義するために、Appleは現在ファイルシステム上に2つの設定ファイルを定義しています。主なものは、以下の場所にあります。
/System/Library/Sandbox/rootless.conf
どこで rootless.conf SIPが保護しているすべてのアプリケーションと最上位ディレクトリを一覧表示します。
アプリケーション
SIPは、OS Xがアプリケーションとアプリケーションユーティリティにインストールするコアアプリケーションを保護しています。これは、root権限を使用している場合でもコマンドラインからでも、OS Xがインストールしたアプリケーションを削除できなくなることを意味します。
ディレクトリ
SIPは、外部の多数のディレクトリやシンボリックリンクも保護しています。 /Applications そしてそれらのディレクトリのトップレベルも rootless.conf。
保護に加えて、アップルはrootless.confファイルでSIPの保護に対するいくつかの例外も定義しており、それらの例外はアスタリスクでマークされています。 SIPの保護からのこれらの免除は、それらの場所内のファイルとディレクトリを追加、削除、または変更することが可能であることを意味します。
これらの例外には、次のものがあります。
/System/Library/User Template - OS Xがテンプレートを保存する場所
新しいアカウント用のホームフォルダを作成するときに使用するディレクトリ。 /usr/libexec/cups - OS Xがプリンタ設定を保存する場所
情報 Appleはこのファイルを自分のものとみなし、第三者によるこのファイルへの変更はAppleによって上書きされると考えています。
どのファイルがSIPによって保護されているかを確認するには、 ls コマンド ターミナルのダッシュの首都Oを使って：
ls -O
SIPで保護されたファイルには 制限された 。
知っておくべき重要なことの1つは、シンボリックリンクがSIPによって保護されている場合でも、リンク先のディレクトリがSIPによって保護されていることを必ずしも意味するわけではないことです。 OS X El Capitanブートドライブのルートレベルには、次の名前のルートレベルディレクトリ内に格納されているディレクトリを指す、SIPで保護されたシンボリックリンクがいくつかあります。 private。
ただし、その内容が private ディレクトリが調べられ、それらのシンボリックリンクが指すディレクトリはSIPによって保護されず、それらとその内容の両方はroot権限を使用するプロセスによって移動、編集または変更されることができます。
Appleが設定したSIP例外のリストに加えて rootless.conf、SIP例外の2番目のリストがあります。この一覧には、サードパーティ製品のディレクトリとアプリケーション名が多数含まれています。に似ている rootless.conf、この除外リストはAppleのものであり、それに対するいかなる第三者の変更もAppleによって上書きされるでしょう。
/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths
ランタイム保護
SIPの保護は、ファイルシステムの変更からシステムを保護することだけにとどまりません。機能が制限されているシステムコールもあります。
ただし、SIPは、開発中の開発者による独自のアプリケーションの検査をブロックしません。 Xcodeのツールにより、開発プロセス中にアプリの検査とデバッグが可能になります。
この詳細については、私は見てみることをお勧めします SIPに関するアップルの開発者向けドキュメント 。
カーネル拡張保護
SIPは、未署名のカーネル拡張のインストールをブロックします。 SIPが有効になっているOS X El Capitanにカーネルエクステンションをインストールするには、カーネルエクステンションは次の条件を満たす必要があります。
無署名のカーネル拡張をインストールする場合は、最初にSIPを無効にする必要があります。
SIP管理の詳細については、以下のリンクをご覧ください。
sudoそしてパスワードの入力要求は通常通り/以前/予想通りに機能しました。ですから、おそらく答えは「ほとんど気づかないでしょう。気がつくと、きっと気づくでしょう」