2007年7月21日

[selinux-users:01949] Re: TOMOYO Linux OLS2007 BoF報告

藤原です。

オタワにおけるTOMOYO の奮闘ぶりを楽しく拝見いたしました。

このスティーブンの発言は、とても参考になります。
audit2allow は、やみくもにポリシを作るだけなので、
確かに、インタラクティブなところがあってもいいと思います。
マクロが出るみたいですが、わたしもそういうのを作っていますよ。

invocation history を保持したドメインを選択的に作成、というのは、
難しいでしょうが、できそうですよね。
この点に関しては、TOMOYOが先を行っているといっていいんでしょう。

僕が考えたのは、ほっておくと危ないことが起こりそうなアクセスは、
とりあえず、閉じ込めてドメイン遷移させておく。(ここまでは自動)
そこで、一回再起動させる。
次に、閉じ込めたドメインをどうするかをやりたければやる。
とりあえず一回閉じ込めればいいのかな、と思いますが。

SELinuxは、base policy で重要なものはやってくれていて、その行為自体を
隠蔽しているので、アプリケーションについては、自由度が高い、
と思っています。
だから、自由にできるところで、差別化をし、いい加減なポリシ、
厳密なポリシ、ができると思います。
最終的にポリシをインストールする際、絶対にやってはいけないことは、
libsepolが止めてくれます。

SELinuxには、
SLIDE等を利用し、厳密にポリシを書きたい人はそうできる、
最小限閉じ込めればいいと思う人は、最小限のドメイン遷移で留める、
という、自由度があると思います。

ちなみに、僕のプログラムは、とりあえず閉じ込めて、2回目はどうする?
ぐらいにしたいです。今はただポリシとインタフェースを出すだけなので。
正しいドメインに誘導でき、正しい(と思われる)ポリシを自動生成できたら
うれしいですね。

p.s.

熊猫さんが床にすわって説明している姿が、ほほえましかったです。


http://sourceforge.net/projects/segatex/

07/07/20 に Toshiharu Harada<haradats@xxxxx> さんは書きました:
> 原田です。
>
> 07/07/18 に Toshiharu Harada<haradats@xxxxx> さんは書きました:
> > このWikiには記載していませんが、Stephenから、
> > 「ドメイン遷移履歴の生成/管理?はSELinuxでも
> > 対応しているよ」と言われました。
> >
> > 具体的な内容を聞き損ねたのですが、もし
> > どんな内容かわかる方があれば教えていただけ
> > ませんでしょうか?
> >
> > Toshiharu Harada さんは書きました:
> > > 原田です。こんにちは。
> > >
> > > TOMOYO LinuxのOLS2007のBoFについて、下記のWikiページに
> > > 報告をまとめました。SELinux関連の情報も含まれています。
> > >
> > > http://tomoyo.sourceforge.jp/wiki/?OLS2007-BOF
>
> SELinuxのドメイン生成の部分について、Stephenに質問した
> ところ下記の回答が送られてきました。引用部分が私の質問です。
>
> > Stephen, I have a question for you. I remember you told us
> > SELinux has domain generate/tracking? capabilities like
> > TOMOYO does. I asked Japanese SELinux users but no
> > answer was returned. Would you point me the information
> > resource (papers/url/file anything) on that?
>
> It is simply a matter of configuring domain transitions in SELinux using
> our regular type_transition statements and allow statements (or using
> the domain_auto_trans macros). Each domain transition in SELinux can be
> configured based on the caller's domain and the file's executable type,
> so you can easily express the invocation history in your policy, ala:
> type_transition local_login_t bash_exec_t:process local_shell_t;
> type_transition local_shell_t sudo_exec_t:process local_sudo_t;
> type_transition sshd_t bash_exec_t:process remote_shell_t;
> type_transition remote_shell_t sudo_exec_t:process remote_sudo_t;
>
> Thus, the new domain (local_shell_t vs. remote_shell_t or local_sudo_t
> vs. remote_sudo_t) tells you the security-relevant aspects of the
> invocation history. The SELinux decisions are still based on a single
> domain at a time, but that domain may encode the full (or selective)
> history.
>
> Now, what we don't presently have is a tool that will automatically take
> audit data and generate such a policy; our existing audit2allow doesn't
> automatically create new domains. Rather that would require the policy
> writer (using a tool like SLIDE) to decide where he wants to retain the
> invocation history and writing his domain transitions accordingly. But
> one could possibly create an interactive form of audit2allow that asks
> at each exec whether the user wants to create a new domain and if so,
> whether the user wants to preserve the invocation history by encoding it
> in the type name.
>
> --
> Toshiharu Harada
> haradats@xxxxx
>
>

投稿者 xml-rpc : 2007年7月21日 08:20
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/61918
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。