refpolicy

また色々いじってみる。

タイプ宣言

タイプを宣言したとき,今までは
type hoge_t,filetype;
としてきた。
今度は、
type hoge_t;
files_type(hoge_t)
とするらしい。
files_typeで、filetype属性を付与する。
属性付与にまでマクロを使ってほしいようだ。

ネットワーク関連

corenet.ifのインターフェースマクロを使って設定する。
マクロの粒度が細かすぎる…どれを使ったらいいか分からん…
たとえば、apache.teのネットワーク設定は、以下のようになってる。
corenet_tcp_sendrecv_all_if(httpd_t)
corenet_udp_sendrecv_all_if(httpd_t)
corenet_raw_sendrecv_all_if(httpd_t)
corenet_tcp_sendrecv_all_nodes(httpd_t)
corenet_udp_sendrecv_all_nodes(httpd_t)
corenet_raw_sendrecv_all_nodes(httpd_t)
corenet_tcp_sendrecv_all_ports(httpd_t)
corenet_udp_sendrecv_all_ports(httpd_t)
corenet_non_ipsec_sendrecv(httpd_t)
corenet_tcp_bind_all_nodes(httpd_t)
corenet_udp_bind_all_nodes(httpd_t)
corenet_tcp_bind_http_port(httpd_t)
corenet_tcp_bind_http_cache_port(httpd_t)
うーん…これを書けるようになるには相当修練が要りそう。
高水準言語 or audit2allow + マクロ提示が必要だなぁ。

refpolcyの思想

Reference policyの考え方は，
別のファイルで宣言された名前(タイプと属性）にアクセスする場合は、
かならずマクロ（interfaceという）を通すようにするので。
たとえば、属性付与関係のマクロがどれくらいあるんだろう…
http://serefpolicy.sourceforge.net/api-docs/kernel_files.html
すごい数だ…
ネットワーク関連
http://serefpolicy.sourceforge.net/api-docs/kernel_corenetwork.html
orz
dontauditにまでマクロか。

Refpolicyになると、全てinterfaceを通してタイプ、属性にアクセスするので、すさまじい数のマクロが生じることになる。
その結果である。こんなにマクロがあってはとても覚えきれまい。
ドキュメントがあることが免罪符になるとは思えない。
interfaceマクロが存在しない場合は自分で定義して加えることになると思われる。ちなみに、interfaceを通さないポリシも記述できるので、
普通の人はinterfaceを通さないポリシを書いてしまうと思うのだが。

Reference policyのアプローチは成功するのか謎だ。
また大修正が加わるのでは…と思ってしまう。
今後どのようにして解決していくんだろう。
私の予想では、Simplified Policyとは少し違う形の、
高水準言語が作られると思う。m4でやるのは限界。
例えば、m4では文法の強制はできない。なので、refpolicyの思想に反したポリシの追加も容易にできてしまう。また、条件分岐の構文も貧弱。

と愚痴になってしまった。
行動を起こさねばしかたないので、
例のごとく、私は、Simplified Policyワールドで細々頑張ります。