Tetsuo Handa
from-****@I-lov*****
2010年 7月 9日 (金) 21:01:48 JST
熊猫です。 Shintaro Fujiwara さんは書きました： > そのツールは、どういう経緯でメインラインに加わったのでしょうね。 今回入ったツールは単機能なアクセス制御機能を組み合わせるという試みのようです。 > TOMOYOと方式はどう違うのでしょうか。 > 又、SELinuxや、SMACとの相違点は何なのでしょうか。 他のＬＳＭモジュールの中から呼び出しても矛盾が生じないような、 ポリシーと呼べるような設定項目の無い単機能モジュールです。 熊猫的には↓だけのためにＬＳＭフックを占有してしまうというのは もったいない感じです。 --- /dev/null +++ b/security/yama/Kconfig @@ -0,0 +1,72 @@ +config SECURITY_YAMA + bool "Yama NAC Support" + depends on SECURITY + select SECURITYFS + select SECURITY_PATH + default n + help + This selects Yama, the NAKed Access Control system which + provides additional global security settings above regular + Linux discretionary access controls. + If you are unsure how to answer this question, answer N. + +config SECURITY_YAMA_SYMLINKS + bool "Yama: protect symlink following in sticky world-writable dirs" + depends on SECURITY_YAMA + default y + help + A long-standing class of security issues is the symlink-based + time-of-check-time-of-use race, most commonly seen in + world-writable directories like /tmp. The common method of + exploitation of this flaw is to cross privilege boundaries + when following a given symlink (i.e. a root process follows + a malicious symlink belonging to another user). + + Enabling this solves the problem by permitting symlinks to only + be followed when outside a sticky world-writable directory, + or when the uid of the symlink and follower match, or when + the directory and symlink owners match. + + If you are unsure how to answer this question, answer Y. + +config SECURITY_YAMA_HARDLINKS + bool "Yama: protect hardlink creation to non-accessible files" + depends on SECURITY_YAMA + default y + help + Normally, hardlinks can be created to files that a given user + does not have access to. This can create security problems + where privileged processes act on files that only they have + access to, but have been put places unexpectedly by an attacker. + + This option limits the creation of hardlinks to files that a + given user would be unable to read and write originally, or are + not otherwise sensitive. + + If you are unsure how to answer this question, answer Y. + +config SECURITY_YAMA_PTRACE + int "Yama: PTRACE_ATTACH default scope" + depends on SECURITY_YAMA + range 0 1 + default 1 + help + This option sets the default scope for PTRACEing of processes. + + One particularly troubling weakness of the Linux process + interfaces is that a single user is able to examine the memory and + running state of any of their processes. For example, if one + application (e.g. Pidgin) was compromised, it would be possible for + an attacker to attach to other running processes (e.g. Firefox, SSH + sessions, GPG agent, etc) to extract additional credentials and + continue to expand the scope of their attack without resorting to + user-assisted phishing. + + This scope is designed to disallow such PTRACE attachment when + the scope is set to non-zero. + + Scopes are: + 0 - classic: CAP_SYS_PTRACE and same uid can ptrace non-setuid. + 1 - restricted: as above, but only children of ptracing process. + + If you are unsure how to answer this question, answer 1. > 複数のLSMを使用すると、どんないいことがあるのでしょうか。 複数のＬＳＭが同時に使えるようになることで、 ユーザの要望に合わせた設定を行いやすくなることを期待しています。 > 実は、職場のサーバをFedora12でSELinuxのenforcingにやっとできたばかりです。 > > でも、プログラムのバイナリのオリジナルのハッシュ(/usr/bin と /sbin と /bin と /usr/sbin > )をとっていて、cronで毎日比べていたら、値が違うんですけど、これってやられてるってことでしょう。 それって /usr/sbin/prelink が cron.daily から実行されているからでは？
