sVirt

元々は2008年に以下のアナウンスにて開始され、
https://www.redhat.com/archives/libvir-list/2008-August/msg00255.html
今はlibvirtにマージ済。QEMU/kvm仮想化で使えるようになっている。
以下のドキュメントが最新である。
https://libvirt.org/drvqemu.html
VMのイメージに適切なラベルつけておけば特に何も考えずに使える模様。
NFSからマウントした場合も考慮してある模様。
実際に使って確かめてみたいーー

変更点調査メモ

休んでいる間の、CIL以外の変更点を調べ始め。
以前よりRedhatのドキュメントが充実している気はする。

基本部分

  • systemd対応

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/chap-Security-Enhanced_Linux-Systemd_Access_Control.html

systemdのstart,stopなどのパーミッションを新たに定義、チェックできるようにしている。

ドメイン単位でpermissiveモードに変えられるようになった。
semanage permissive -a <ドメイン>

  • fine name transition

https://access.redhat.com/blogs/766093/posts/1976273

動的に生成されるファイルのラベルをどうするかというもの。
デフォルトでは、ディレクトリと同じラベル。
これまでは、ディレクトリのラベルに応じて別のラベルを付与することができたが、
ファイル名に応じてラベルを付けられるようになったっぽい!
10年ぐらい前にほしかった機能だが、当時はパス名とラベルの論争でそれどころでなかったような記憶があるようなないような。

組込み系

だいぶ組込み系でSELinuxの適用が進んだ模様。

http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/
これがどこまで出来ているかが気になる!

AndroidSELinuxが入っている

FFRIさんのまとめ記事:
http://www.ffri.jp/assets/files/monthly_research/MR201408_SE%20for%20Android%20Overview_JPN.pdf

私が休んでいる間に一体何があったのか気になる!!
https://knowledge.windriver.com/en-us/000_Products/000/010/000/040/020/000_Wind_River_Linux_Security_Profile_User's_Guide,_7.0/060/010

SELinuxの勉強再開

SELinuxの世界に実に7,8年ぶりぐらいに復帰する気が起きたので、リハビリ開始。久しぶりにメモを書いてみる。

CIL

私の最も興味があるセキュリティポリシがどうなってるかだけど、ここ何年かでは、CILが一番大きな変更点の模様。

  • CIL:

https://github.com/SELinuxProject/cil

  • 面さんのリファレンスガイド翻訳

https://oss.sios.com/security/CIL_Reference_Guide_ja.html

どうやら、従来のポリシ記述言語を整理しなおしたもののよう。
refpolicyを置き換えるのではなくて、共存しようとしているように見える。
従来のrefpolicy -- CIL -- カーネルが読めるポリシ言語
のようになっている。

CILのメリット

ポリシ操作効率向上

2015 Linux Security Summitで,
http://kernsec.org/files/lss2015/lss-state_of_selinux-pmoore-082015-r1.pdf
2015- The Year of CIL
"Policy operations can be 50% ~ 75% faster than before"
と大きく語られている。一見するとポリシの記述がそれくらい簡単になるように勘違いしがちだが、そうではない。以下のRedhatの人のブログが恐らくソース。
https://mgrepl.wordpress.com/2015/07/30/cil-part1-faster-selinux-policy-rebuild/
これによると、ポリシモジュールの追加の速度が倍以上早くなるとのデータが出ている。

高級言語の実装が簡単になる

高級言語の例として、例として、lobsterというのが上がっていた
https://github.com/invincealabs/lobster

SEEditの言語もCILの上に書けるようになるんだったら素晴らしいのだけど。

CILが実際にrefpolicyとどう共存しようというのかは、これから調べなくては。。

SELinuxのアクセス制御をアプリに

とあるアプリケーションに対して、SELinuxを使ったアクセス制御を適用できないかと思っており、調べている。
お、まさに↓の人と同じ悩みだ。参考になる。
http://sourceforge.jp/projects/jsosug/lists/archive/users/2008-October/000034.html
↓あたりを読めばなんとなく分かるのだろうか。。

  • How to Write a Userspace Object Manager

http://www.engardelinux.org/modules/index/list_archives.cgi?list=selinux&page=0321.html&month=2008-11
http://www.secureos.jp/index.php?Documents%2FUserspaceObjectManager

  • Userspace AVC

http://manpages.ubuntu.com/manpages/dapper/man3/avc_init.3.html

以上からなんとなく分かったこと

セキュリティポリシファイル内で、アプリ独自のパーミッションを定義、
アプリ側で、オブジェクトにセキュリティコンテキストを付与するように拡張、
そして、アプリ側で
↓のlibselinuxの関数を呼べば、パーミッションチェックができる
int security_compute_av(security_context_t scon,
security_context_t tcon,
security_class_t tclass,
access_vector_t requested, struct av_decision *avd)

security_compute_av(サブジェクトのセキュリティコンテキスト、アプリ内のオブジェクトのセキュリティコンテキスト、アプリ独自のオブジェクトクラス、アプリ独自のパーミッション、結果)
のように呼ぶ。
これで十分じゃんと思ったのだが、
security_compute_avは、直接セキュリティポリシをクエリすると思うので低速なはず

そこで出てくるのがuserspace avc?
カーネル内のSELinuxパーミッションチェックするときは、カーネルがAVCというキャッシュにアクセス制御結果をキャッシュしているため、カーネル内のSELinuxパーミッションチェックは高速。
このAVCをアプリ側で持とうというのがuserspace avcのようだ
avc_initとかいうlibselinux関数を使いuserspace avcを初期化、
avc_has_perms関数でパーミッションチェック。
avc_has_permsのパーミッションチェックではuserspace avcを見に行くので高速。

波地摩

2002年からの種IT開発のまとめとして、
USENIX LISA(AppArmorの論文とか出たところ)に論文出して採択されました。
論文書くのは超大変でした(というかまだ最終版の直し中…)
学術論文っぽい構成の仕方とかあるようで、思考法を変える必要があった。
LISA 09は、波地摩開催です。昔開催されたSELinux Symposiumと同じ場所。
I'm going to LISA '09

新型インフルエンザにだけはかからないようにしたいけど、
前の週ぐらいに絶妙のタイミングでJapan Linux Symposiumがある…
セキュアOSのBoFあるし、その後にレセプションもあるようなので、是非出たいが、
人口密度が危険なことになってそう(汗


なお、種ITの開発が終っているように見えますが、svnでは、微妙に更新しています。
主に組込み向けのバグフィックスです。
相当ゆっくりやってるので、1年後ぐらいにどこかで発表が目標です。
そうこうしているうちにSMACKやらTOMOYOやらが広まりそうな予感はしますが…

組込みとセキュアOS

超久々の更新。
いつの間にやら、色々あった。

xattr support for yaffs2

そして、私もひっそりとパッチを出しました。超適当なxattrの実装。
何件か私信はあったけど、コードの改善につながるものではなかった。
私はもう無理なので誰か〜
http://www.aleph1.co.uk/lurker/message/20090424.003253.a5e3c4ac.ja.html