Toshiharu Harada
harad****@nttda*****
2008年 9月 24日 (水) 11:33:30 JST
原田です。こんにちは。 2008年9月24現在の状況について報告します。 AppArmor, TOMOYO Linuxなどパス名ベースのMACを実装する上で 必要なパラメータが利用できない、いわゆる「vfsmount問 題」について 両プロジェクトでは、これまで何度も提案（パッチ）を投稿してき ました。 それらについてはメンテナの承認が得られず、メインライン化を 阻害する要因となっていましたが、ここにきて新しい動きが ありました。 Linux Foundation Japan #8 Symposiumで来日した Andrew Mortonに相談し、彼の仲介によりvfsmountパラメータの 修正を拒んできたfsのメンテナ、Al Viroの反対の理由 を確認し、 それに基づいたパッチを作成したところ、反論、問題の指摘がなく、 そのパッチがAndrew Mortonの管理する-mm treeと呼ばれる 評価実験用のソースツリーの中に取り込まれました。 該当するパッチの本体と説明は、他の-mm treeに採用された パッチと合わせて下記で参照できます。パッチの名前は、 "introduce-new-lsm-hooks-where-vfsmount-is-available.patch" （vfsmountが利用できる箇所に新しいLSMのフックを 追加する）です。 http://userweb.kernel.org/~akpm/mmotm/broken-out/ 上記からパッチの説明の部分を本メール末尾に引用します。 （これらはAndrew Mortonからの要請により提供したものです） Linux Foundation Japan #8 Symposiumで、まさに Andrew Morton自身が語ったようにLinuxの評価実験用の ソースツリーは-mmからlinux-nextに移ることが決まって います。そのためメインラインに関係する場としては、 -mm linux-next mainline の3種ありますが、プロジェクトでは今後以下のように メインライン化に向けて行動します。 ・足場（必要なフック）のできた-mmに対して、 TOMOYOの本体のパッチを提案（投稿）する ・その結果を受けて、引き続きlinux-next, mainlineへ 必要なフックおよびTOMOYO Linux本体を提案する 上記について、一点懸案事項が存在しています。 最近提案され現在-mmとlinux-nextに採用されている credentialというセキュリティ関連のパッチにより TOMOYO Linuxが必要とするフックが失われて しまいました。credentialはmainlineに反映されることが 事実上確定されているので、TOMOYO Linuxの メインライン化に向けた提案ではcredentialへの対応が 不可欠となります。前述のように-mmにもcredentialは 含まれていますから、これから-mmに投稿するTOMOYOの 本体では、「TOMOYOとして必要な」credentialの 影響を回避するための「新たな提案」を組み合わせたものと なります。過去の提案とその反響を振り返ると、 こうした提案はもめることが予想されますが、 指摘に耳を傾けながら一歩一歩着実に進めていきます （本体の提案は日本時間本日中に投稿の予定です）。 ----- What is this patch for? ----- There are security_inode_*() LSM hooks for attribute-based MAC, but they are not suitable for pathname-based MAC because they don't receive "struct vfsmount" information. ----- How this patch was developed? ----- Two pathname-based MACs, AppArmor and TOMOYO Linux, are trying to merge upstream. But because of "struct vfsmount" problem, they have been unable to merge upstream. Here are the list of approaches and the reasons of denial. (1) Not using LSM http://lwn.net/Articles/277833/ This approach was rejected because security modules should use LSM because the whole idea behind LSM was to have a single set of hooks for all security modules; if every module now adds its own set of hooks, that purpose will have been defeated and the kernel will turn into a big mess of security hooks. (2) Retrieving "struct vfsmount" from "struct task_struct". http://lkml.org/lkml/2007/11/5/388 Since "struct task_struct" contains list of "struct vfsmount", "struct vfsmount" which corresponds to "struct dentry" can be retrieved from the list unless "mount --bind" is used. This approach turned out to cause a critical problem that getting namespace_sem lock from security_inode_*() triggers AB-BA deadlock. (3) Adding "struct vfsmount" parameter to VFS helper functions. http://lkml.org/lkml/2008/5/29/207 This approach adds "struct vfsmount" to VFS helper functions (e.g. vfs_mkdir() and vfs_symlink()) and LSM hooks inside VFS helper functions. This approach is helpful for not only AppArmor and TOMOYO Linux 2.x but also SELinux and auditing purpose, for this approach allows existent LSM users to use pathnames in their access control and audit logs. This approach was rejected by Al Viro, the VFS maintainer, because he thinks individual filesystem should remain "struct vfsmount"-unaware and VFS helper functions should not receive "struct vfsmount". Al Viro also suggested to move existing security_inode_*() to out of VFS helper functions so that security_inode_*() can receive "struct vfsmount" without modifying VFS helper functions, but this suggestion was opposed by Stephen Smalley because changing the order of permission checks (i.e. MAC checks before DAC checks) is not acceptable. (4) Passing "struct vfsmount" via "struct task_struct". http://lkml.org/lkml/2007/11/16/157 Since we didn't understand the reason why accessing "struct vfsmount" from LSM hooks inside VFS helper functions is not acceptable, we thought the reason why VFS helper functions don't receive "struct vfsmount" is the amount of modifications needed to do so. Thus, we proposed to pass "struct vfsmount" via "struct task_struct" so that modifications remain minimal. This approach was rejected because this is an abuse of "struct task_struct". (5) Remembering pathname of "struct vfsmount" via "struct task_struct". http://lkml.org/lkml/2008/8/19/16 Since pathname of a "struct dentry" up to the mount point can be calculated without "struct vfsmount", absolute pathname of a "struct dentry" can be calculated if "struct task_struct" can remember absolute pathname of a "struct vfsmount" which corresponds to "struct dentry". As we now understand that Al Viro is opposing to access "struct vfsmount" from LSM hooks inside VFS helper functions, we gave up delivering "struct vfsmount" to LSM hooks inside VFS helper functions. Kernel 2.6.26 introduced read-only bind mount feature, and hooks for that feature (i.e. mnt_want_write() and mnt_drop_write()) were inserted around VFS helper functions call. Since mnt_want_write() receives "struct vfsmount" which corresponds to "struct dentry" that will be passed to subsequent VFS helper functions call, we associated pathname of "struct vfsmount" with "struct task_struct" instead of associating "struct vfsmount" itself. This approach was not explicitly rejected, but there seems to be performance problem. (6) Introducing new LSM hooks. (this patch) We understand that adding new LSM hooks which receive "struct vfsmount" outside VFS helper functions is the most straightforward approach. This approach has less impact to existing LSM module and no impact to VFS helper functions. Signed-off-by: Kentaro Takeda <taked****@nttda*****> Signed-off-by: Tetsuo Handa <pengu****@I-lov*****> Signed-off-by: Toshiharu Harada <harad****@nttda*****> Cc: Al Viro <viro****@zeniv*****> Cc: Christoph Hellwig <hch****@lst*****> Cc: Crispin Cowan <crisp****@crisp*****> Cc: Stephen Smalley <sds****@tycho*****> Cc: Casey Schaufler <casey****@schau*****> Signed-off-by: Andrew Morton <akpm****@linux*****> --- fs/namei.c | 37 ++++++++++ fs/open.c | 5 + include/linux/security.h | 135 +++++++++++++++++++++++++++++++++++++ net/unix/af_unix.c | 4 + security/capability.c | 53 ++++++++++++++ security/security.c | 64 +++++++++++++++++ 6 files changed, 298 insertions(+) -- 原田 季栄 (Toshiharu Harada) harad****@nttda*****
TOMOYO
Fork