from-****@i-lov*****
from-****@i-lov*****
2007年 7月 31日 (火) 13:14:03 JST
> 機能の取捨選択は以下のように考えています。 > > (1)に関しては、以下の機能が候補です > ・ファイル ・ argv[0] > ・ネットワーク（受信系以外） > ・マウント > これらは全て実装して投稿します。 > > (2)に関しては、以下の機能が候補です > ・ネットワーク（受信系） > ・ケイパビリティ > ・シグナル ・ if 節のサポート ・ bind 時のポート番号の制限 ・ /dev/ 用改ざん防止ファイルシステム > この中で、ケイパビリティは次回の投稿からははずすことにします。 > POSIXではなく独自ケイパビリティを使用していることでTOMOYOの本質とは > 別のところで議論が生じてしまうこと、 > 必要となるLSMの拡張が多いことがその理由です。 ファイルについて TOMOYO 2.0 では sysctl() の制御ができませんでしたが、 TOMOYO 2.1 （カーネル 2.6.21 以降でしか使えないですが）では制御できるようになります。 argv[0] について TOMOYO 2.0 では argv[0] のチェックをしていませんでしたが TOMOYO 2.1 ではチェックします。 ネットワークについて 現在の LSM の仕様では accept() と recv() の後に呼ばれる（アクセス制御のために使用可能な） フックが存在しないため、アクセス制御ができません。（ TOMOYO 1.4.2 では制御しています。） また、 read() で受信する場合と recvmsg() で address を NULL にした場合にも アクセス制御ができません。（ TOMOYO 1.4.2 でも制御できません。） これらを修正するためのパッチは既に作成済みであり、 http://lists.openwall.net/netdev/2007/07/20/82 に投稿しました。 しかし、アプリケーションが受信するタイミングでアクセス制御を行う方式は不評のようです。 マウントについて TOMOYO 1.4.2 では特定のオプションを強制的に有効にする／無効にする機能をサポート （例えば /tmp に tmpfs をマウントする場合は自動的に nodev noexec nosuid を有効にする） していましたが、 LSM のフックでは実現できません。 しかし、特定のオプションを強制的に有効／無効にするよりも、（マウントポイント／マウントデバイス／ ファイルシステムタイプの３要素だけでなく）オプションまで完全に一致した場合のみ許可する方が 自然だと思うようになってきたので、 TOMOYO 2.1 では４要素が完全に一致した場合のみ許可するようにします。 （ TOMOYO 1.X 系でも４要素の一致に変更したいと思っていたのですが、開発会議では 1.X のフリーズを 勧告されたので、 TOMOYO 1.5 に取り込めなくなっています、） if 節について TOMOYO 1.4.2 では if task.uid=path1.uid のような形式でアクセス許可に条件をつけることができますが、 TOMOYO 2.0 の作成時に削られてしまいました。 if 節のサポートは「現状のLSMの仕様でできるTOMOYO本体」で実現でき、 AppArmor との違いを出す上で有効だと私は思うのですが、 サイズを小さくするために「現状のLSMの仕様でできるTOMOYO本体」には含めない方針になっています。 http://securityblog.org/brindle/2007/07/15/misunderstanding-unix-security/#comment-15822 の > This is one huge advantage over path based mechanisms, if a sys admin logs in via ssh and > has a key agent running the socket will be sysadm_sshd_tmp_t in /tmp, so it won’t be > accessible by others, even if they have the same UID. However, since the ssh files are > fairly random (/tmp/ssh-XXXXXXX) where the X’s are random numbers/letters path based mechanisms > cannot protect them and instead rely on DAC to do so. に対するある程度の反論（ root が他人の /tmp/ssh-XXXXXXX にアクセスするのを禁止できる）にも使えます。 ついでに、上記エントリへのコメント案です。 You might say "making hardlinks of /etc/shadow in SELinux won't lose shadow_t protection and it is no problem to allow making hardlinks of /etc/shadow". Believing this statement, what will happen with policy that allows making hardlinks of /etc/shadow and creating /.autorelabel ? Let me try the following operations. # ln /etc/shadow ~ # ls -Z /etc/shadow ~/shadow -r-------- root root system_u:object_r:shadow_t /etc/shadow -r-------- root root system_u:object_r:shadow_t /root/shadow # touch /.autorelabel # reboot # ls -Z /etc/shadow ~/shadow -r-------- root root root:object_r:user_home_t /etc/shadow -r-------- root root root:object_r:user_home_t /root/shadow Oh, no! I lost shadow_t protection. Of course, I believed "making hardlinks of /etc/shadow in SELinux won't lose shadow_t protection and it is no problem to allow making hardlinks of /etc/shadow". A solution SELinux can use to avoid above accident is "don't allow making hardlinks of /etc/shadow from the beginning" or "don't allow creating /.autorelabel (or whatever that triggers relabelling)". So pathname based access control does "don't allow making hardlinks of /etc/shadow from the beginning". If you say that "what if hardlinks of /etc/shadow already exists before enabling pathname based access control?", I answer "SELinux can't guarantee /etc/shadow will have shadow_t protection (even if SELinux's policy tells to assign shadow_t to /etc/shadow) if hardlinks of /etc/shadow already exists before relabelling". SELinux's .fc file tells "what label an object which is accessible by resolving specific pathname *should* have", but it doesn't guarantee "what label the object *actually* have at the moment of access decision". Unless you guarantee relabelling event never happen, label-based access control can't tell the truth. Assuming "*should*" == "*actually*" with labels is what I don't like. Anyway, pathname based access control and SELinux have to be careful with hardlinks for both "before introducing access control and after starting access control".
TOMOYO
Fork