Homebrewを使うにあたって問題があったり、 XtraFinderやTotalFinder等の一部アプリが使えなくなったり、 と影響が結構大きいEl Capitanの新しいSIPというセキュリティシステムですが、 ちょっと色々いじりながら調べたことなどのまとめ。
- System Integrity Protection (SIP)
- 保護されているファイルやディレクトリ
- SIPの無効化
- SIPの無効化に関してNVRAM云々
- /usr/local/binが勝手にroot所有になる
System Integrity Protection (SIP)
System Integrity Protection (SIP)はOS X El Capitanで導入された 新しいセキュリティシステムです。
rootlessと呼ぶこともあります1。
基本的な機能としては、 システムの重要な部分に関して、 root権限ですら変更できないような 領域を作ることによりよりシステムを安全にする、と言ったものです。
また、重要なシステムプロセスの変更も出来ないように保護されます。
上の絵はOS X El Capitanのセキュリティレイヤーの概念図です。
- Gatekeeper
まず、一番外側はGatekeeper 2 によって デベロッパ IDの確認出来ないアプリ等のインストールを弾きます。
- Sandbox
確認されたアプリはサンドボックス化された状態で起動され 3、 Mac内のデータや他のアプリから分離され悪意のあるアクセスを防ぎます。
- POSIX
さらにOS XはUnix的なPOSIXによるアクセス制限を採用していて、 ユーザーごとにアクセス出来るファイルやディレクトリを制限しています。
基本、root権限は全ての領域を読み書きすることが出来ます。
- Keychain
一番内側にはキーチェインがありますが、 キーチェインは特別なデータベースです。 ここにはパスワードなどの情報が入っていますが、 暗号化されて強力に守られています。 root権限からも保護されています。
こんな感じなのですが、Yosemiteまでにあった問題 (というかUnix全般的な問題)として、 POSIXの部分で権限を得られればキーチェイン以外一通り システムを見たり変更したり出来てしまうことがありました 4。
これを解決するため、全権を持つrootユーザーであっても 一部ファイル、ディレクトリは操作出来ないようにする、という機構が 新たに導入されました。 (絵の中でKeychain領域で浮島になってるところがそのイメージ。)
これによって、ユーザーが間違ってアプリに対して色々と許可してしまったとしても 確実に守られる領域が出来ます。
ただし、逆にプロテクトがきつくなり、 今まで使えてたアプリ等が使えなくなる、と言う状況も起きています。
保護されているファイルやディレクトリ
保護されているファイルやディレクトリは
/System/Library/Sandbox/rootless.conf
にリストしてあります。
$ cat /System/Library/Sandbox/rootless.conf
/Applications/App Store.app
/Applications/Automator.app
/Applications/Calculator.app
/Applications/Calendar.app
/Applications/Chess.app
/Applications/Contacts.app
/Applications/Dashboard.app
/Applications/Dictionary.app
/Applications/DVD Player.app
/Applications/FaceTime.app
/Applications/Font Book.app
/Applications/Game Center.app
/Applications/Image Capture.app
/Applications/Launchpad.app
/Applications/Mail.app
/Applications/Maps.app
/Applications/Messages.app
/Applications/Mission Control.app
/Applications/Notes.app
/Applications/Photo Booth.app
/Applications/Photos.app
/Applications/Preview.app
/Applications/QuickTime Player.app
/Applications/Reminders.app
/Applications/Safari.app
/Applications/Stickies.app
/Applications/System Preferences.app
/Applications/TextEdit.app
/Applications/Time Machine.app
/Applications/Utilities/Activity Monitor.app
/Applications/Utilities/AirPort Utility.app
/Applications/Utilities/Audio MIDI Setup.app
/Applications/Utilities/Bluetooth File Exchange.app
/Applications/Utilities/Boot Camp Assistant.app
/Applications/Utilities/ColorSync Utility.app
/Applications/Utilities/Console.app
/Applications/Utilities/Digital Color Meter.app
/Applications/Utilities/Disk Utility.app
/Applications/Utilities/Feedback Assistant.app
/Applications/Utilities/Grab.app
/Applications/Utilities/Grapher.app
/Applications/Utilities/Keychain Access.app
/Applications/Utilities/Migration Assistant.app
/Applications/Utilities/Script Editor.app
/Applications/Utilities/System Information.app
/Applications/Utilities/Terminal.app
/Applications/Utilities/VoiceOver Utility.app
/Library/Preferences/SystemConfiguration/com.apple.Boot.plist
/System
* /System/Library/Caches
booter /System/Library/CoreServices
* /System/Library/CoreServices/Photo Library Migration Utility.app
/System/Library/CoreServices/RawCamera.bundle
* /System/Library/Extensions
/System/Library/Extensions/*
UpdateSettings /System/Library/LaunchDaemons/com.apple.UpdateSettings.plist
* /System/Library/Speech
* /System/Library/User Template
/bin
dyld /private/var/db/dyld
/sbin
/usr
* /usr/libexec/cups
* /usr/local
* /usr/share/man
# symlinks
/etc
/tmp
/var
こんな感じ。 よく言われる/System、/usr、/bin、/sbin等が含まれているのが分かります。
また、元から入ってるアプリケーションも含まれていることが分かります。 (なのでこれらのアプリのアイコンを変更することは出来ません 5。 )
ここで*
で始まる行は、逆にSIPで保護されてるディレクトリ内であっても
管理者権限で変更できるディレクトリの指定になります。
従って、/usr以下はSIPの保護により管理者権限でも変更できませんが、 /usr/local以下であれば変更は可能です。
SIPの無効化
これによりHomebrew等、/usr/local以下を使うものも使えるのですが、 ただ、このディレクトリが最初に無いと(Macデフォルトでは存在しない) /usr以下にディレクトリを作ることは出来ないので 結局/usr/lolcalを作成できません。
また、元から入っているアプリケーションも大体このリストに載っていて、 中身が保護されているのでアイコンの変更すら出来ません。
これらを変更するためには一度SIPを切る必要があります。
方法としては個々にあるように、一度⌘-Rを押しながら 再起動してリカバリーモードで起動し、 リカバリーモード内で SIPを切り、通常再起動して/usr/localを作ったり アイコンを変更する必要があります。
リカバリーモードでの変更方法としては、 起動するとメニューバーにユーティリティという項目があり、 ここからターミナルを立ち上げられるので立ち上げ、 コマンドラインで
-bash-3.2 # csrutil disable
Successfully disabled System Integrity Protection. Please restart the machine for the changes to take effect.
-bash-3.2 #
とすればOK。
これで再起動して普通に立ち上げればSIPは切れています。
確認するには、ターミナル.appを立ち上げcsrutil status
を実行します。
$ csrutil status
System Integrity Protection status: enabled (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: enabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: disabled
NVRAM Protections: disabled
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
$
csrutil
でstatus
サブコマンドだけは通常起動時にも使える様になっています6。
ここで、
System Integrity Protection status: enabled (Custom Configuration).
と、enabled
にはなっていますがカスタムされた状態となっていて、
実際、下のリストは全てdisabled
になっています。
ここで、SIPも実はいくつかのものにわかれている事が分かります。
上のアイコンの変更や/usr/localの作成などはその時だけSIPが無効であれば良いので、 上の様に一度無効化して通常起動して作業を行い、 終わったら再びリカバリーモードに入り、
-bash-3.2 # csrutil enable
Successfully enabled System Integrity Protection. Please restart the machine for the changes to take effect.
-bash-3.2 #
として、再起動します。
これで
$ csrutil status
System Integrity Protection status: enabled.
$
とだけ出る様になっていればSIPは完全に有効になっています。
一方で、SIPが有効だと使えないアプリなども出てきています。 XtraFinderや TotalFinder等のFinderの拡張系アプリなんかは SIPが有効だと全く使えません。
El Capitanへの対応が出来ていない、というわけではなく、 SIPを無効にすれば使えます。
この時、上で見たようにSIPはいくつかの機能にわかれているので、 必要なものだけを無効化し、他を有効にしたままにしてなるべく 保護を強化することも出来ます。
XtraFinder等に関しては、csrutil disable
の代わりに
-bash-3.2 # csrutil enable --without debug
csrutil: requesting an unsupported configuration. This is likely break in the future and leave your machine in an unknown state.
Successfully enabled System Integrity Protection. Please restart the machine for the changes to take effect.
-bash-3.2 #
とコマンドを打ちます。
enable
にしますが、--without debug
という引数を使って
debug
に関するものだけを無効化します
7。
(元々全てがenabled
な状態からでもこのコマンドで一部だけ無効化出来ます。)
これで再起動して通常起動後に調べてみると
$ csrutil status
System Integrity Protection status: enabled (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: enabled
Filesystem Protections: enabled
Debugging Restrictions: disabled
DTrace Restrictions: enabled
NVRAM Protections: enabled
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
$
こんな感じでApple InternalとDebugging Restrictionsだけが 無効で、他のものは有効になったままです。
Filesystem Protectionsが有効なので /usr以下にディレクトリを作ったりすることはroot権限でも出来ません。
この状態でXtraFinderやTotalFinderは使えるので、 どうしてもそれらのアプリを使いたい場合は この様に、最低限切る必要があるものだけを切って 他は有効にしておくのが良さそうです。
また、Homebrewで/usr/localを作るのに一時的でもSIPを切るのは怖い、 と言った場合には
-bash-3.2 # csrutil enable --without fs
で、 Filesystem Protectionsだけを一時的に切って他を有効にしたまま 作業をする、ということも出来ます。
SIPの無効化に関してNVRAM云々
SIPを無効化することに関して、 リカバリーモードに入らず、 再起動前にコマンドで設定を変更しておくだけで次回起動から SIPを無効化出来る、見たいのがあったのですが
これを見ると、
$ sudo nvram boot-args="rootless=0"
をしてから再起動するとSIPが無効化する、ということでしたが、何も変更されませんでした。
また、
$ sudo nvram boot-args="-x"
をすると再起動時にセーフモードに入る、ということですが、 これもダメ。 というか、これをやったら再起動時に通常起動っぽくなった挙句、 パスワード入力後に10分位かかってログイン出来るようなちょっとおかしな状態になりました。 (その後、再起動してみると治った様ですが。。。)
NVRAMは所定の設定情報が記憶されて小容量メモリですが8、
上のSIPのcsrutil status
の結果をもう一度見てみると、NVRAM Protectionsがあるので、
これもSIPで守られていて変更できないようになっていることが分かります。
なのでSIPが有効な状態からではこの方法ではいきなり無効にすることは出来ません。
(-x
が何故おかしな事になったのか分かりませんが、保護されてる物と下手な干渉があったのかもしれません、取り敢えず注意です。。。)
さらに、下のような記事を見つけました。
SIP/Rootless Internal in El Capitan Delta’s Lair: http://www.idelta.info/archives/sip-rootless-internal-in-el-capitan/
csrutil
によって何が変更されるか、について記述されていますが、
変更されるのはNVRAMに含まれる起動プロパティのデータで、
この中にSIPに関する情報が埋まっていてこれを変更している、とのこと。
--without debug
等とすると一部のビットだけを変更したりする、と。
ただ、これによると、"rootless=0"
の様なやり方はEl Capitanでは
排除されていてそもそも使えない、とのこと。
この辺り、El Capitanのベータ版の時には、SIPを GUIからオフに出来るような機能もあったみたいで、 色々と変更されたうえで正式リリースとなっているので 特にシステムに影響が大きい部分なので慎重に何が正しいか情報を見る必要があります。
/usr/local/binが勝手にroot所有になる
Homebrewを使っているので /usr/local/binにコマンドなどをインストールしているのですが、 新しいパッケージをインストールしようとした所、 Permission deinedなエラーが出ました。
調べてみると、/usr/local/binと/usr/local/shareが rootのものになっていました。
$ ls -l /usr/local/
total 80
-rw-r--r-- 1 user admin 3161 May 12 XX:XX CODEOFCONDUCT.md
-rw-r--r-- 1 user admin 1103 Oct 27 XX:XX CONTRIBUTING.md
drwxr-xr-x 118 user admin 4012 Oct 6 XX:XX Cellar
drwxr-xr-x 3 user admin 102 Jul 25 XX:XX Frameworks
-rw-r--r-- 1 user admin 1241 Mar 4 2015 LICENSE.txt
drwxr-xr-x 14 user admin 476 Oct 2 XX:XX Library
-rw-r--r-- 1 user admin 2134 Sep 8 XX:XX README.md
-rw-r--r-- 1 user admin 23801 May 14 XX:XX SUPPORTERS.md
drwxr-xr-x 503 root wheel 17102 Oct 9 XX:XX bin
drwxr-xr-x 23 user admin 782 Oct 5 XX:XX etc
drwxr-xr-x 9 user admin 306 Oct 2 XX:XX gems
drwxr-xr-x 96 user admin 3264 Oct 7 XX:XX include
drwxr-xr-x 408 user admin 13872 Oct 7 XX:XX lib
drwxr-xr-x 118 user admin 4012 Oct 7 XX:XX opt
drwxr-xr-x 55 root wheel 1870 Oct 6 XX:XX share
drwxr-xr-x 5 user admin 170 Aug 2 XX:XX texlive
drwxr-xr-x 5 user admin 170 Aug 8 XX:XX var
$
他のディレクトリに関してはEl Capitanにアップデート後、
$ sudo chown -R $(whoami):admin /usr/local
をしているので全て現在のユーザー(user
)のものになっていますし、
これを実行後、たしかに全てが変更されてたのを確認していますし、
実際にいくつかパッケージをインストールしました。
仕方ないので取り敢えず、
$ sudo chown -R user:admin /usr/local/bin
$ sudo chown -R user:admin /usr/local/share
として自分のものにしなおし、暫く経ってから見てみると、
またroot
のものに変更されていました。
また変更して、今度は暫くの間、何度か確認してみると、
1,2時間の間はそのままだったので大丈夫か、と思いきや、また数時間後にroot
のものになっていました。。。
この時、SIPを上に書いた様にXtraFinderのために一部を無効化していたので、
もしかしたらそのせいかも、と思いSIPを完全有効化してやってみたところ、
やはり数時間でroot
のものに変更されました。。。
この現象を探ってみると、あまりこれに影響されている、と言う人が居ないのですが、
How to Disable System Integrity Protection (rootless) in OS X El Capitan
これのコメント欄を見ると
The permissions on /usr/local/bin and /usr/local/share keep reverting to root:wheel on each reboot, and thus brew upgrades will fail until I change it back to $(whoami):admin.
Are there permanent solutions to this other than disabling SIP or running sudo chown -R $(whoami):admin /usr/local after every reboot?
と言ってる人もいるので、確かに起こる人は居るようです。
ただ、Homebrewを使ってれば必ずぶち当たる問題なので、 それにしては問題だ、と言ってる人が余りに居ないので 何かアプリか特殊な環境でのみ起こることなのかもしれませんが。。。
取り敢えず、どのタイミングで変わるか調べるために、 cron jobで5分に1度、ディレクトリをチェックして変更されてたら 教える様にしておいた所、 大体4時間位経つと変更されてる感じでした。
ただ、決まった時間というわけでも無さそうで、 何か定期的に走るプロセスによって、というわけでも無さそう。
sudo
で変更すると/var/log/system.logにログが残りますが、
この辺りには何も無いので、やはりシステム内部のプロセスが変更してる感じではあるのですが。
これらのディレクトリの所有者が変わってしまうと
Homebrewのインストールが失敗する上、
brew upgrade
でパッケージを更新しようとしても失敗するため、
これを自動で行ってたりすると失敗してしまってホント面倒です。
ですが、色々見ても根本的な解決策が見つからなかったので、取り敢えず
# Update authorities of /usr/local/bin and share, as it seems ownerships of them automatically changed to root.
*/5 * * * * if ls -l /usr/local/|grep root|grep -q root;then (ls -l /usr/local;/usr/sbin/chown -R user:admin /usr/local/bin/;/usr/sbin/chown -R user:admin /usr/local/share;fi
というcron jobをsudo crontab -e
で開いた
rootのcron jobとして登録して走らせておくことにしました。
これだとユーザーroot
としてコマンドを行うので
sudo
は必要ないですがwhoami
はroot
になるのできちんとユーザー名(ここではuser
)を指定してください。
差し当たり5分に1度の割合で監視しています。
ちょっと不格好な感じもしますが、 Homebrewのインストールに関することだけであれば これで十分ですし、 5分に一度みるだけなら負担も全くかからないので しばらくはこれで対処しようと思います。
追記: 2015/10/13
原因はアンチウィルスソフトのSophosでした。 Sophosをアンインストールすればこの現象は消えます。
追記ここまで
System Integrity Protection - Wikipedia, the free encyclopedia ↩
System Integrity Protection – Adding another layer to Apple’s security mode Der Flounder ↩
-
-
他のサブコマンドを通常起動時にやろうとすると、
$ csrutil enable csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
と、リカバリーモードで使いなさい、と言われます。
Update on ‘Rootless’: The Configuration Mechanism has Changed : osx ↩