Secure Networking with SELinux
Posted by: Joshua Brindle on May 28th, 2007
元記事：http://securityblog.org/brindle/2007/05/28/secure-...
昨年(2006年)はSELinuxのネットワーク関係の機能が大変充実した。SELinuxのコミュニティの尽力に感謝したい。
During the last year quite a bit of effort has gone into improving SELinux’ networking support, thanks to the great SELinux community.
ネットワークに関するSELinuxのサポートは今でも改善されつつあるが、ここらで現状を紹介しておけば、ユーザの役にも立つだろうし、利用者を増やすことにもなるだろう。
While this support is still evolving it will be very beneficial for people to try it out and give feedback so the final result is useful to more users and meets the security needs of a wider audience.
SELinuxのネットワーク関連機能は、どんどん進化していくので（すでにこの記事で取り上げられていない機能などが取り込まれるべきかどうか議論されている）、この記事は適宜更新されていくだろう。そうすれば、読者は常に最新の情報を得られるわけだ。
As the network support in SELinux continues to evolve (there are already other ideas being discussed for possible inclusion) I’ll try to keep this post updated so that people who find it will have the latest information available.
SELinuxがネットワークのセキュリティをサポートするというのは、いろんな意味がある。
Network support in SELinux means many things.
昔は（と言っても、数バージョン前のカーネルでは、ということだが）SELinuxは数多くのオブジェクトクラスを使って、精密なネットワークアクセス制御を実現していた。
In the old days (”old days” is very relative since it was only a few kernel releases back at this point) SELinux had fine grained network access control by way of many object classes.
netif(ネットワークインターフェース), node(ネットワークアドレス）、そしていくつかのsocketオブジェクトクラスである（例えば tcp_socket, udp_socket, rawip_socket等）
These object classes were netif (network interfaces), node (network addresses) and a handful of socket object classes (such as tcp_socket, udp_socket, rawip_socket and so on).
SELinuxのポリシーは、直接ネットワークオブジェクトそのものをラベル付けしていた。たとえば、netifconコマンドでinterfaceを、nodeconコマンドでnodeを、そしてportconコマンドでportのラベル付けができた。
The SELinux policy directly labeled several kinds of network objects including interfaces (using netifcon), internet nodes (using nodecon) and ports (using portcon).
したがって、ポリシーの記述はこんなふうだ。
The policy statements looked something like these:
netifcon eth0 system_u:object_r:external_netif_t system_u:object_r:external_packet_t
nodecon 192.168.1.1 255.255.255.255 system_u:object_r:external_node_t; portcon tcp 21 system_u:object_r:ftp_port_t ;
これらのラベル付けされたネットワークオブジェクトは、普通のSELinuxの構文にしたがってアクセス権を定義されていた。
These labeled objects could then be given access to with normal SELinux rules:
allow ftpd_t external_netif_t : netif {tcp_send tcp_recv };
allow ftpd_t external_node_t : node { tcp_send tcp_recv };
allow ftpd_t ftp_port_t : tcp_socket { send_msg recv_msg name_bind };
上の例では、ftpd_tのドメインのプロセスには21番のFTPのポートを使って、bindできて、tcpのメーッセージをやり取りできて、例えば192.168.1.1のeth0のインターフェースを使って通信できた。
These basically gave ftpd_t the ability to bind to port 21, send and receive tcp messages on port 21 and send and receive tcp messages on eth0 (whose ip was 192.168.1.1).
これでうまく行くわけだが、一つ問題なのは、これらが１つのルールに集約できていないということだ。
These worked fine, the only problem is that they weren’t specified in a single rule so they weren’t coupled.
つまり、もし別のルールがあって、ftpd_tのドメインに（IPアドレスから相手サーバのホスト名を得ようとして）DNSのパケットをlocalのインターフェースとだけやり取りさせようとすると、上記のルールでDNSのパケットをやり取りできるルールがあるため、外部のサーバとも接続できてしまう。
This means if there was another set of rules that let ftpd_t send and receive dns packets (for name resolution) only on the internal interface they could also send and receive dns packets on the external interface by virtue of the rules above.
注意しておきたいのだが、両方の制御をうまくマッチングさせることは不可能ではない。これから説明するcompat_netというSELinuxのオプションをセットすればよい。たとえば echo 1 > /selinux/compat_net とする。
Note that these access controls can still be used en lieu of the ones I’m going to talk about next by setting the compat_net option in SELinux with echo 1 > /selinux/compat_net.
ネットワークオブジェクトについてのラベルの指定は libsemanageコマンドに適宜追加されてきた。そして、ポリシーを変更しなくとも、semanageコマンドを使えば変更できる。
The labeling of these objects was eventually added to libsemanage and could be changed on end systems using the semanage command without modifying policies.
2006年のDeveloper SummitのSELinuxシンポジウムで、ネットワークのラベル付けをもっと簡単にできないだろうか、そして多用されるネットワークのアクセス制限のパターンを簡単に表現できて、さらに大事なことは、interface, address, portの記述をうまくまとめることができないかということを議論した。
During the 2006 SELinux Symposium Developer Summit we discussed ideas on making the network labeling easier to use, more able to support typical network restrictions and most importantly to closely bind the interface, address and port.
ありがたいことに、すでにLinuxのnetfilterコマンドは上記の機能をすべて備えており、さらにコネクションの追跡機能などもあり、FTPのように動的にポートが割り当てられるアプリケーションについてもより厳密なアクセス制御が可能だった。先例はあるのだ。
Fortunately for us netfilter in Linux already supports all these things as well as some additional benefits like connection tracking that can be used to more precisely restrict things that use dynamic ports such as ftp.
この問題を解決する一番簡単な方法は、iptablesにport番号やIPアドレスやインターフェースの他にSELinuxのドメインを指定する機能を付け加えることだと思うかもしれない。そうすれば、ftp_tのドメイン宛てのftpパケットだけを許可する、なんていう記述ができるかもしれない。
One may be thinking that the easiest way to handle this is to add a domain specifier to iptables so that one could write a rule that matched the SELinux domain as well as the ports, network interface and addresses to allow only ftp packets to reach ftpd_t.
しかし、こういう方法ではSELinuxのアクセス管理の機能があっちこっち（システムのカーネル以外にiptablesにも）に散らばってしまいかねない。
This would have decentralized the SELinux policy, however, by moving part of the decision making out of the SELinux security server and into the iptables policy and subsystem.
SELinuxのシンプルで一箇所にまとまったポリシーの管理が困難になるから、原則としてこういうことは避けたい。
This is generally undesirable as we’d like to keep a single, centralized, analyzable SELinux policy.
というわけで、残された道は、netfilterやiptablesにパケットをラベル付けしてもらって、SELinuxはラベル付けに基づいたアクセスの許諾に集中することだった。
That essentially left us with using netfilter and iptables to label packets, which would have SELinux allows rules written to allow or deny access.
では、これがどうやって実現されるか見てみよう。
Lets look at how this might be used:
iptables -A INPUT -t mangle -p tcp --dport 21 -j SECMARK --selctx system_u:object_r:ftp_packet_t
これは、21番のポートに行くパケットを ftp_packet_t とラベル付けしている。
This labels packets destined for port 21 as ftp_ packet_t.
ftpd_tのドメインにftp_packet_tのパケットをやり取りさせるSELinuxのポリシーは以下のように単純だ。
The SELinux rule that allows ftpd_t send and receive packets of this type is simply:
allow ftpd_t ftp_packet_t : packet { send recv };
しかし、これなら既存のネットワークアクセス制御と何もかわらない。もうすこし面白い例を見てみよう。
But this doesn’t do anything more than the old network controls did, lets look at something more interesting:
iptables -A INPUT -t mangle -p tcp --dport 21 -i eth0 -s 192.168.0.1/24 -j SECMARK --selctx system_u:object_r:ftp_packet_t
これは、192.168.0.1/24からeth0のport21番に来たパケットだけに ftp_packet_tというラベルをつけている(SECMARK)。これがnetfilterの機能を利用できる強みだ。
This labels only packets on eth0, coming from 192.168.0.1/24 and on tcp port 21 as ftp_packet_t. So this has the advantage of being able to couple anything that netfilter supports together.
他にこんなiptablesのルールもある。
Another iptables rule such as:
iptables -A INPUT -t mangle -m state --state RELATED,ESTABLISHED -j CONNSECMARK -restore
このルールでは、関係のあるパケットに、ラベルの内容をコピーしている。関係があるとは、例えばftpのクライアントがPASVで通信をするときには動的にランダムなポートに接続するが、そのポートでやりとりするデータも、もともとのftpの接続ポートと同じラベルが付けられるということだ。
will copy the label for related packets so when an ftp client attempts a file transfer the related port (which is dynamically assigned at the time of the transfer) will receive the same label.
これは、netfilterのコネクション追跡機能を利用したもので、ftp接続に関係するパケットだけを受信するようにできた。
This takes advantage of netfilter’s connection tracking features to allow ftp to only receive packets related to its connections.
これには、新たなポリシーを追加することも、ポリシーの変更も必要ない。ラベル付けの手段だけが変わったのだ。
This requires no additional policy rules or policy modifications of any kind since the labels are all we are changing.
netfilterの機能によって、どのドメインがどのパケットをアクセスできるかをより詳細に定義できるようになった。したがって、マシン単位よりも詳しい、プロセス単位でのファイアウォールが構築できるようになった。これは、１つのサーバで複数のサービスを提供していて、それぞれ異なるセキュリティの基準があるような場合にとても役に立つ。
What this brings over netfilter’s existing functionality is the ability to specify precisely which domains can access which packets, so it allows you to bring the firewall functionality all the way to the processes rather than just to the machine, which is significant if you have several services of differing security properties running on the same machine.
例えば、あるサーバの中のあるApache httpdサービスは、社内からのみアクセス可能で会社の機密データにアクセスできて、また別のApache httpdサービスは、社外（インターネット全体）に対して静的な（ダイナミックなコンテンツは危険だからね（笑）コンテンツを提供する、などということが可能になる。
This would, for example, allow you to have an internal Apache instance with access to company confidential data to only be accessible internally and another external Apache instance that serves static web content to the internet.
大抵の人はネットワークのアクセス制限というとファイアウォールしか思い浮かばないと思うが、SELinuxは他にもネットワークに関する機能がある。もう一つの機能というのは、ネットワークのラベル付けだ。
While most people think of network access controls in the terms of firewalls alone this is not the only network support in SELinux. The next kind of SELinux network support is labeled networking.
SELinuxによるネットワークを流れる情報のラベル付けの方法は２つある。１つはNetLabelといって、CIPSOの実装の一つだ。(訳注：CIPSOについてはLWN.netの記事や海外さんのブログ参照）もう一方はIPSecをベースにしたラベル付けだ。
ただしNetLabelについてはここでは述べない。というのは、NetLabelはSELinuxのラベルのうち、MLSの部分しか使っておらず、さらに、古いOS(Trusted HP-UXとかTrusted Solarisとか）と組み合わせて使う用途だからだ。IPSecのSELinuxのラベル付けは、すべての情報を送信するが、双方のシステムがSELinuxで運用されている必要がある。
There are two methods of labeling network traffic in SELinux: NetLabel, which is an implementation of CIPSO, and IPSec based labeling. I’m not going to talk about NetLabel because it only supports the MLS portion of the SELinux context and is primarily useful for making SELinux cooperate with legacy trusted operating systems like Trusted HP-UX and Trusted Solaris. IPSec based labeling sends the entire context but currently only works between SELinux systems.
NetLabelはMLSと古いシステムをサポートするためのものなので、ここでは述べない。代わりにIPSecベースのラベル付けについて見ていこう。
As NetLabel is primarily for supporting MLS and legacy trusted systems I’m not going to talk about it, lets instead move to IPSec based labeling.
IPSecについて、有る程度は知っていることを前提で話を進めていくので、わからない用語などあれば、IPSecのドキュメントに当たって欲しい。特に、SPD（セキュリティポリシーデータベース）やSA（セキュリティアソシエーション）がどういう役割を果たしているかについて知っておく必要がある。
I’m going to assume some knowledge of IPSec here so if you are unfamiliar with some of the terms please consult IPSec documentation. In particular you need to know what SPD’s and SA’s are and what their role in IPSec is.
参照：IPSec解説記事
まず、IPSecをサポートしているカーネルが必要だ。一番簡単なのは（もしRedHat製品を使っているなら）最新のテスト版(rawhide)のカーネルかLSPPのカーネルを利用することだ。LSPPカーネルは http://people.redhat.com/sgrubb/files/lspp/ から入手できる。Redhat以外のベンダーを利用している場合は、linux-2.6.22以降のカーネルを用意すればいい。
The first thing you need is a kernel that supports IPSec labeling. The easiest way (if you are using Red Hat) is to use the current Fedora rawhide kernel or the LSPP kernel. The LSPP kernel is available at http://people.redhat.com/sgrubb/files/lspp/. For the non-Red Hat users in the audience labeled IPSec is also available in the released version of linux-2.6.22.
そして、ラベル付けするためのipsec-toolが必要だ。RedhatのrawhideやLSPP版が使える。すべてをインストールしたら、ラベルつきのIPSecが使えるようになる。最初はシンプルなラベル付けされたSAの例から始めよう。
You’ll also need an ipsec-tools that is capable of labeling, rawhides or the LSPP version will do here as well. Once you have everything you need installed you can start using labeled IPSec. We’ll start with simple labeled SA’s.
まず、私は一組のテスト支援プログラムをもっていて、動作に問題が無いかどうかチェックしている。これは簡単なクライアントサーバで、互いに接続して、getpeercon()関数を使ってネットワークソケットのラベル付けを見ることができる。
First I have a couple programs that will help test and ensure that everything is working. They are simple a simple client and server that connect, use getpeercon() to return what the context of the network socket is.
client.c
server.c
これらのプログラムをlibselinuxとリンクする：
Build these by linking them against libselinux:
gcc -o client client.c -lselinux
gcc -o server server.c -lselinux
最初はIPSec無しで実行してみる。
First lets try running them without IPSec to see what happens:
私のテストマシンのアドレスは192.168.147.132 (scarecrow) と 192.168.147.130 (poisonivy)になっている。以下、お手元のテスト環境のアドレスに読み替えて欲しい。
My test machines are 192.168.147.132 (scarecrow) and 192.168.147.130 (poisonivy), obviously replace with your addresses.
サーバが192.168.147.132に、クライアントが192.168.147.132で実行されているとすると、出力は以下のようになる。
After running server on 192.168.147.132 and running client 192.168.147.132 on the other machine the output should look like this:
[root@poisonivy ~]# ./client 192.168.147.132
getpeercon: Protocol not available Received: Hello, (null) from (null)
[root@scarecrow ~]# ./server
getsockopt: Protocol not available server: got connection from 192.168.147.130, (null)
getpeercon()関数は、「protocol not available」のエラーを返すだろう。というのは、まだラベル付けをしていないからだ。このエラーを使えば、ネットワークがラベル付けされているかどうかが分かる。
getpeercon() returns protocol not available because no labeling was enabled on this connection, you can use the error to determine if you are using a labeled network socket or not.
もし、新たにSAを2台のマシンの間に接続したら、セキュリティコンテクストを設定しない限り、上記のようなエラーが出る。
If we make an SA between these 2 machines without specifying a context we’ll get the same results:
[root@scarecrow ~]# cat dev/ipsec/setkey.scarecrow.test
spdflush;
flush;
spdadd 192.168.147.130 192.168.147.132 any
spdadd 192.168.147.132 192.168.147.130 any
[root@poisonivy ~]# cat dev/ipsec/setkey.poisonivy.test
spdflush;
flush;
spdadd 192.168.147.132 192.168.147.130 any
spdadd 192.168.147.130 192.168.147.132 any
では実行してみよう。
Then run:
[root@poisonivy ~]# setkey -f dev/ipsec/setkey.poisonivy.test
[root@scarecrow ~]# setkey -f dev/ipsec/setkey.scarecrow.test
註：通信開始する際には双方のマシンでracoonを実行していないといけない。
NOTE: both machines will need to be running racoon in order to create SA’s when the connections are attempted.
サーバとクライアントが前のテストと同じ状態ならば、同じ結果が出る。setkey -Dとすれば、新しいSAを見ることができる。この場合、SA自体はラベル付けされていなことに注意。
Running server and client the same as before will give the exact same results. You can use setkey -D to see the newly created SA’s. Notice that the SA’s are not be labeled.
setkeyファイルに以下のように -ctx文を追加してみたらどうなるか：
If we add a -ctx statement to our setkey files such that:
[root@scarecrow ~]# cat dev/ipsec/setkey.scarecrow.test
spdflush;
flush;
spdadd 192.168.147.130 192.168.147.132 any
spdadd 192.168.147.132 192.168.147.130 any
setkey -DPコマンドでマシン上にあるすべてのSDPエントリを探すことができる。これまでの手続きを他のマシンの setkeyファイルについても行う。ここで注意：default_tを使ってはいけない。この例では、実際にどんなことが起こるかをやってみている。これはSAを作成した際につけられるラベルではない。このラベルはどのSPDエントリのドメインがマッチするかを検出するためのものだ。
You can use setkey -DP to see the SPD entries on each machine, note the context field in the entries.
Repeat this with the other machines setkey file. Note that you’d never use default_t in a label, this is an example to show what happens. This is _NOT_ the label that will be used to create SA’s, this label will be used in a ‘polmatch’ rule to see which SPD entries a domain can match to. This will be explained later.
setkey -f を実行するとエラーが出る。
Running setkey -f results in an error now:
[root@scarecrow ~]# setkey -f dev/ipsec/setkey.scarecrow.test
The result of line 8: Permission denied.
The result of line 14: Permission denied.
Looking for the denial:
[root@scarecrow ~]# tail /var/log/audit/audit.log | grep AVC
type=AVC msg=audit(1179150979.762:33): avc: denied { setcontext } for pid=21632 comm="setkey" scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=association type=AVC msg=audit(1179150979.895:34): avc: denied { setcontext } for pid=21632 comm="setkey" scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=association
これで良い。IPSecのSPDにラベル付けしたユーザについては保護ができる。今度は両方のマシンをpermissiveのモードにして、またsetkeyコマンドを実行してみる。今度は成功する。
This is good, it means that we can protect who sets the labels on IPSec SPD’s. For now set permissive mode on both machines and run setkey again, it should now succeed.
何度かクライアント・サーバを実行すると、以下の様な結果が見られる（クライアント側から見た情報）
Run the client and server again and you should see something like this on the client side:
[root@poisonivy ~]# ./client 192.168.147.132
Received: Hello, root:system_r:unconfined_t:SystemLow-SystemHigh from root:system_r:unconfined_t:-SystemHigh
setkey -Dを使って、新しく作られたSAを見ることができ、各エントリーの内容フィールドにnoteが取れる。下の画像を見れば、どのようにSAがラベル付けされるかイメージが湧くかもしれない。註：コネクションの両端にあるSAは都合２つ。一つは入力、もう一つは出力用で、それぞれ適切なラベル付けがされている。出力用のSAはどちらのシステムでもlocalのドメインで、入力用のSAはremoteのドメインと認識される。
You can use setkey -D to see the newly created SA’s and note the context field in each entry.
Hopefully this image conveys how the SA’s are labeled, note that each side of the connection has 2 SA’s, one incoming and one outgoing with the appropriate labels. The outgoing SA for each system is always the local domain, the incoming SA for each system is always the remote domain.
画像はChris Ashworthによるもの。私が作った図よりもシンプルで、ラベル付けされたトンネルのイメージが湧きやすい。
I’d like to thank Chris Ashworth for the graphic, it is much simpler than mine and I think gives a better understanding of the labeled tunnels.
この図で分かることは、サーバ側でgetpeercon()を実行すれば、root:system_r:unconfined_t:SystemLow-SystemHighというラベルが見えて、クライアント側だとroot:system_r:unconfined_t:-SystemHighとなるということだ。違いをもっと特定したい場合には、runconコマンドを使って、もっと別のコンテクストを設定してみるといい。
This demonstrates that the server sees root:system_r:unconfined_t:SystemLow-SystemHigh when it calls getpeercon() and the client sees root:system_r:unconfined_t:-SystemHigh. To show the difference more specifically run the client with a different context using runcon:
[root@poisonivy ~]# runcon -t httpd_t ./client 192.168.147.132
こうすると、以下のように表示される。
Received: Hello, root:system_r:httpd_t:SystemLow-SystemHigh from root:system_r:unconfined_t:-SystemHigh
サーバ側でgetpeercon()を実行すると、httpd_tというラベル付けされているのがわかる。コネクションのもう一方の端で、どのようなラベルが付いているか調べるのも同じようにする。ところで、ラベルに関するポリシーはどうなっているだろうか。
Now you can see the server sees httpd_t when it calls getpeercon(). So now we’ve seen how you can identify the process context on the other side of a connection, but what about the policy?
まず、dmesgをクリアして、setenforce 1とした後、setenforce 0を実行すると、AVCメッセージがクリアされて、プロセスが再起動される。
Lets clear out dmesg and setenforce 1; setenforce 0; to clear the AVC and start the process over.
最初に setkeyを実行して、audit2allow -d のコマンドを実行すると、以下のようになる。
First running setkey and then audit2allow -d should show:
allow unconfined_t default_t:association setcontext;
これは、unconfined_tのドメイン（通常、ユーザの実行するプログラムはこのドメインに属する）で、コンテクストをdefault_tに設定しようとしたことを示す。これは期待どおりである、なぜなら、SPDのエントリにそう書いてあったからだ。さて、dmesg -c コマンドを実行してカーネルのバッファをクリアして、runconを使ってサーバとクライアントを動かそう。
This means that unconfined_t (what your shell normally runs as) tried to set the context of an association to default_t. This is expected since we used default_t in our SPD entry. Run dmesg -c to clear the kernel buffer and try to run the server and client (with runcon):
関係ないルールを削除してしまえば、クライアント側では次のような表示がされる
Removing the irrelevant rules we should see something like this on the client side:
allow httpd_t default_t:association polmatch;
このポリシールールは、クライアント（httpd_tのドメインで実行中）が、SPDエントリに一致するものを探すことを示す。この機能があるので、ドメインが一致するSPDのエントリだけに対応するSELinuxポリシーを使うことができる。例えば、有るドメインに属するユーザでは高品質な暗号化が利用できるようにして、他のユーザには、より高速に処理できるが強度の低い暗号を使わせることができる。
This rule means that the client (running as httpd_t) attempted to match against the SPD entry we added earlier. This is useful because you can use SELinux policy to enforce which SPD entries a domain may match against. For example, if you wanted to have some domains use high quality encryption and let the others use a faster, lower quality encryption you can do that by specifying which SPD types a domain may polmatch against.
allow httpd_t self:association sendto;
これは、httpd_tのドメインのプロセスが httpd_tのラベルが付いたデータパケットを送信するということを示す。これは、ラベルに対応する受け手にパケットを送ることを意味する。注意：現在の制御方法ではどのドメインのラベルで相手にデータを送るかまでは制御できない。
This is httpd_t sending data to an association labeled httpd_t. This basically just means that it is sending to the association created for it. Note that with the current controls you can not control which domains you are sending to on the other side.
allow httpd_t unconfined_t:association recvfrom;
これが一番重要な制御例だ。httpd_tのドメインのプロセスが、unconfined_tとラベルづけされた相手からデータを受け取れるということを示している。サーバがunconfined_tで実行されていたからだ。この記法によって、相手のマシンがどのドメインに属しているかによって、自分のサーバのどのドメインとデータのやりとりができるかを示す。
This is the most significant control; it says that we are allowing httpd_t to receive from an association labeled unconfined_t, which is the result of the server running in unconfined_t. This lets you use policy to determine which domains on another machine can send data to which domains on the local machine.
allow unconfined_t default_t:association polmatch;
そして、これは、相手のドメイン（サーバ）がSPDエントリのうち、入力定義のパターンにマッチするかを調べる。注意：ここでは２つのSPDエントリが追加されて、１つは出力、１つは入力の通信に関して定義している。それぞれのドメインに属するパケットはSPDのエントリのローカルマシンのドメイン（出力側）と相手側のマシン(入力側）に適合する必要がある。
And this is the remote domain (the server) matching against the income SPD entry on this machine. Note that there were 2 SPD entries added, one for outgoing communication and one for incoming communication, both domains have to polmatch the SPD’s on the local machine (for outgoing) and the remote machine (for incoming).
サーバ側でも似たよう名アクセス拒否が起こりうるが、これまでの例を逆にするだけなので、ここでは取り上げない。
There should be similar denials on the server side, only reversed so I won’t go over those.
SELinuxを使えば、かなりのことができることがわかったと思う。サーバとクライアントの両方のポリシーをいじることができれば、双方の間で、どのドメインとどのドメインが通信しているかがわかる。これはIPC(Inter Process Communication)のアクセス制御をネットワーク上まで広げたに過ぎない。
As you can see you can do a significant amount with this technology, assuming that you control both policies (source and destination) you can be very certain which domains are talking to which domains across machines, similar to the SELinux IPC controls but across a network!
１つの応用例としては、内部向けと外部向けのブラウザを、ユーザのワークステーションで使い分けることが挙げられる。内部向けブラウザはあるドメインで実行され、機密の顧客情報を含む社内のwebアプリケーションサーバとだけ通信することができ、一方、外部向けブラウザはインターネットにアクセスできるようにする。こうすれば、外部の悪質なプログラムによって、社内データが流出する危険が減らせる。SELinuxがなければ、このような分離は困難だ。
For example, one possible application of this technology is to have an ‘internal’ and ‘external’ browser on employee workstations. The internal browser would run in a domain that is allowed to access internal company web application servers that contain confidential customer information while the external browser can access the internet. This reduces the risk that rogue internet content can compromise your internal data. This kind of separation would be much more difficult (or impossible) without SELinux’ advanced networking controls.
ラベル付けされたIPSecとnetfilter secmarkによって、SELinuxのネットワークは充実した機能を提供できる。これらの機能はどんどん進化していくだろう。乞うご期待。
Using both labeled IPSec and netfilter secmark you can do some pretty amazing things with SELinux networking, and its only going to get better, stay tuned for more information.
多くの皆さんのご尽力に感謝。
A special thanks goes out to all the people that worked hard on getting this technology where it is now and the same ones trying to push it even further to have the best secure networking infrastructure around. These people include (in no particular order): James Morris, Venkat Yekkirala, Joy Latten, Paul Moore (who implemented NetLabel), and many others.
Posted by: Joshua Brindle on May 28th, 2007
元記事：http://securityblog.org/brindle/2007/05/28/secure-...
昨年(2006年)はSELinuxのネットワーク関係の機能が大変充実した。SELinuxのコミュニティの尽力に感謝したい。
During the last year quite a bit of effort has gone into improving SELinux’ networking support, thanks to the great SELinux community.
ネットワークに関するSELinuxのサポートは今でも改善されつつあるが、ここらで現状を紹介しておけば、ユーザの役にも立つだろうし、利用者を増やすことにもなるだろう。
While this support is still evolving it will be very beneficial for people to try it out and give feedback so the final result is useful to more users and meets the security needs of a wider audience.
SELinuxのネットワーク関連機能は、どんどん進化していくので（すでにこの記事で取り上げられていない機能などが取り込まれるべきかどうか議論されている）、この記事は適宜更新されていくだろう。そうすれば、読者は常に最新の情報を得られるわけだ。
As the network support in SELinux continues to evolve (there are already other ideas being discussed for possible inclusion) I’ll try to keep this post updated so that people who find it will have the latest information available.
SELinuxがネットワークのセキュリティをサポートするというのは、いろんな意味がある。
Network support in SELinux means many things.
昔は（と言っても、数バージョン前のカーネルでは、ということだが）SELinuxは数多くのオブジェクトクラスを使って、精密なネットワークアクセス制御を実現していた。
In the old days (”old days” is very relative since it was only a few kernel releases back at this point) SELinux had fine grained network access control by way of many object classes.
netif(ネットワークインターフェース), node(ネットワークアドレス）、そしていくつかのsocketオブジェクトクラスである（例えば tcp_socket, udp_socket, rawip_socket等）
These object classes were netif (network interfaces), node (network addresses) and a handful of socket object classes (such as tcp_socket, udp_socket, rawip_socket and so on).
SELinuxのポリシーは、直接ネットワークオブジェクトそのものをラベル付けしていた。たとえば、netifconコマンドでinterfaceを、nodeconコマンドでnodeを、そしてportconコマンドでportのラベル付けができた。
The SELinux policy directly labeled several kinds of network objects including interfaces (using netifcon), internet nodes (using nodecon) and ports (using portcon).
したがって、ポリシーの記述はこんなふうだ。
The policy statements looked something like these:
netifcon eth0 system_u:object_r:external_netif_t system_u:object_r:external_packet_t
nodecon 192.168.1.1 255.255.255.255 system_u:object_r:external_node_t; portcon tcp 21 system_u:object_r:ftp_port_t ;
これらのラベル付けされたネットワークオブジェクトは、普通のSELinuxの構文にしたがってアクセス権を定義されていた。
These labeled objects could then be given access to with normal SELinux rules:
allow ftpd_t external_netif_t : netif {tcp_send tcp_recv };
allow ftpd_t external_node_t : node { tcp_send tcp_recv };
allow ftpd_t ftp_port_t : tcp_socket { send_msg recv_msg name_bind };
上の例では、ftpd_tのドメインのプロセスには21番のFTPのポートを使って、bindできて、tcpのメーッセージをやり取りできて、例えば192.168.1.1のeth0のインターフェースを使って通信できた。
These basically gave ftpd_t the ability to bind to port 21, send and receive tcp messages on port 21 and send and receive tcp messages on eth0 (whose ip was 192.168.1.1).
これでうまく行くわけだが、一つ問題なのは、これらが１つのルールに集約できていないということだ。
These worked fine, the only problem is that they weren’t specified in a single rule so they weren’t coupled.
つまり、もし別のルールがあって、ftpd_tのドメインに（IPアドレスから相手サーバのホスト名を得ようとして）DNSのパケットをlocalのインターフェースとだけやり取りさせようとすると、上記のルールでDNSのパケットをやり取りできるルールがあるため、外部のサーバとも接続できてしまう。
This means if there was another set of rules that let ftpd_t send and receive dns packets (for name resolution) only on the internal interface they could also send and receive dns packets on the external interface by virtue of the rules above.
注意しておきたいのだが、両方の制御をうまくマッチングさせることは不可能ではない。これから説明するcompat_netというSELinuxのオプションをセットすればよい。たとえば echo 1 > /selinux/compat_net とする。
Note that these access controls can still be used en lieu of the ones I’m going to talk about next by setting the compat_net option in SELinux with echo 1 > /selinux/compat_net.
ネットワークオブジェクトについてのラベルの指定は libsemanageコマンドに適宜追加されてきた。そして、ポリシーを変更しなくとも、semanageコマンドを使えば変更できる。
The labeling of these objects was eventually added to libsemanage and could be changed on end systems using the semanage command without modifying policies.
2006年のDeveloper SummitのSELinuxシンポジウムで、ネットワークのラベル付けをもっと簡単にできないだろうか、そして多用されるネットワークのアクセス制限のパターンを簡単に表現できて、さらに大事なことは、interface, address, portの記述をうまくまとめることができないかということを議論した。
During the 2006 SELinux Symposium Developer Summit we discussed ideas on making the network labeling easier to use, more able to support typical network restrictions and most importantly to closely bind the interface, address and port.
ありがたいことに、すでにLinuxのnetfilterコマンドは上記の機能をすべて備えており、さらにコネクションの追跡機能などもあり、FTPのように動的にポートが割り当てられるアプリケーションについてもより厳密なアクセス制御が可能だった。先例はあるのだ。
Fortunately for us netfilter in Linux already supports all these things as well as some additional benefits like connection tracking that can be used to more precisely restrict things that use dynamic ports such as ftp.
この問題を解決する一番簡単な方法は、iptablesにport番号やIPアドレスやインターフェースの他にSELinuxのドメインを指定する機能を付け加えることだと思うかもしれない。そうすれば、ftp_tのドメイン宛てのftpパケットだけを許可する、なんていう記述ができるかもしれない。
One may be thinking that the easiest way to handle this is to add a domain specifier to iptables so that one could write a rule that matched the SELinux domain as well as the ports, network interface and addresses to allow only ftp packets to reach ftpd_t.
しかし、こういう方法ではSELinuxのアクセス管理の機能があっちこっち（システムのカーネル以外にiptablesにも）に散らばってしまいかねない。
This would have decentralized the SELinux policy, however, by moving part of the decision making out of the SELinux security server and into the iptables policy and subsystem.
SELinuxのシンプルで一箇所にまとまったポリシーの管理が困難になるから、原則としてこういうことは避けたい。
This is generally undesirable as we’d like to keep a single, centralized, analyzable SELinux policy.
というわけで、残された道は、netfilterやiptablesにパケットをラベル付けしてもらって、SELinuxはラベル付けに基づいたアクセスの許諾に集中することだった。
That essentially left us with using netfilter and iptables to label packets, which would have SELinux allows rules written to allow or deny access.
では、これがどうやって実現されるか見てみよう。
Lets look at how this might be used:
iptables -A INPUT -t mangle -p tcp --dport 21 -j SECMARK --selctx system_u:object_r:ftp_packet_t
これは、21番のポートに行くパケットを ftp_packet_t とラベル付けしている。
This labels packets destined for port 21 as ftp_ packet_t.
ftpd_tのドメインにftp_packet_tのパケットをやり取りさせるSELinuxのポリシーは以下のように単純だ。
The SELinux rule that allows ftpd_t send and receive packets of this type is simply:
allow ftpd_t ftp_packet_t : packet { send recv };
しかし、これなら既存のネットワークアクセス制御と何もかわらない。もうすこし面白い例を見てみよう。
But this doesn’t do anything more than the old network controls did, lets look at something more interesting:
iptables -A INPUT -t mangle -p tcp --dport 21 -i eth0 -s 192.168.0.1/24 -j SECMARK --selctx system_u:object_r:ftp_packet_t
これは、192.168.0.1/24からeth0のport21番に来たパケットだけに ftp_packet_tというラベルをつけている(SECMARK)。これがnetfilterの機能を利用できる強みだ。
This labels only packets on eth0, coming from 192.168.0.1/24 and on tcp port 21 as ftp_packet_t. So this has the advantage of being able to couple anything that netfilter supports together.
他にこんなiptablesのルールもある。
Another iptables rule such as:
iptables -A INPUT -t mangle -m state --state RELATED,ESTABLISHED -j CONNSECMARK -restore
このルールでは、関係のあるパケットに、ラベルの内容をコピーしている。関係があるとは、例えばftpのクライアントがPASVで通信をするときには動的にランダムなポートに接続するが、そのポートでやりとりするデータも、もともとのftpの接続ポートと同じラベルが付けられるということだ。
will copy the label for related packets so when an ftp client attempts a file transfer the related port (which is dynamically assigned at the time of the transfer) will receive the same label.
これは、netfilterのコネクション追跡機能を利用したもので、ftp接続に関係するパケットだけを受信するようにできた。
This takes advantage of netfilter’s connection tracking features to allow ftp to only receive packets related to its connections.
これには、新たなポリシーを追加することも、ポリシーの変更も必要ない。ラベル付けの手段だけが変わったのだ。
This requires no additional policy rules or policy modifications of any kind since the labels are all we are changing.
netfilterの機能によって、どのドメインがどのパケットをアクセスできるかをより詳細に定義できるようになった。したがって、マシン単位よりも詳しい、プロセス単位でのファイアウォールが構築できるようになった。これは、１つのサーバで複数のサービスを提供していて、それぞれ異なるセキュリティの基準があるような場合にとても役に立つ。
What this brings over netfilter’s existing functionality is the ability to specify precisely which domains can access which packets, so it allows you to bring the firewall functionality all the way to the processes rather than just to the machine, which is significant if you have several services of differing security properties running on the same machine.
例えば、あるサーバの中のあるApache httpdサービスは、社内からのみアクセス可能で会社の機密データにアクセスできて、また別のApache httpdサービスは、社外（インターネット全体）に対して静的な（ダイナミックなコンテンツは危険だからね（笑）コンテンツを提供する、などということが可能になる。
This would, for example, allow you to have an internal Apache instance with access to company confidential data to only be accessible internally and another external Apache instance that serves static web content to the internet.
大抵の人はネットワークのアクセス制限というとファイアウォールしか思い浮かばないと思うが、SELinuxは他にもネットワークに関する機能がある。もう一つの機能というのは、ネットワークのラベル付けだ。
While most people think of network access controls in the terms of firewalls alone this is not the only network support in SELinux. The next kind of SELinux network support is labeled networking.
SELinuxによるネットワークを流れる情報のラベル付けの方法は２つある。１つはNetLabelといって、CIPSOの実装の一つだ。(訳注：CIPSOについてはLWN.netの記事や海外さんのブログ参照）もう一方はIPSecをベースにしたラベル付けだ。
ただしNetLabelについてはここでは述べない。というのは、NetLabelはSELinuxのラベルのうち、MLSの部分しか使っておらず、さらに、古いOS(Trusted HP-UXとかTrusted Solarisとか）と組み合わせて使う用途だからだ。IPSecのSELinuxのラベル付けは、すべての情報を送信するが、双方のシステムがSELinuxで運用されている必要がある。
There are two methods of labeling network traffic in SELinux: NetLabel, which is an implementation of CIPSO, and IPSec based labeling. I’m not going to talk about NetLabel because it only supports the MLS portion of the SELinux context and is primarily useful for making SELinux cooperate with legacy trusted operating systems like Trusted HP-UX and Trusted Solaris. IPSec based labeling sends the entire context but currently only works between SELinux systems.
NetLabelはMLSと古いシステムをサポートするためのものなので、ここでは述べない。代わりにIPSecベースのラベル付けについて見ていこう。
As NetLabel is primarily for supporting MLS and legacy trusted systems I’m not going to talk about it, lets instead move to IPSec based labeling.
IPSecについて、有る程度は知っていることを前提で話を進めていくので、わからない用語などあれば、IPSecのドキュメントに当たって欲しい。特に、SPD（セキュリティポリシーデータベース）やSA（セキュリティアソシエーション）がどういう役割を果たしているかについて知っておく必要がある。
I’m going to assume some knowledge of IPSec here so if you are unfamiliar with some of the terms please consult IPSec documentation. In particular you need to know what SPD’s and SA’s are and what their role in IPSec is.
参照：IPSec解説記事
まず、IPSecをサポートしているカーネルが必要だ。一番簡単なのは（もしRedHat製品を使っているなら）最新のテスト版(rawhide)のカーネルかLSPPのカーネルを利用することだ。LSPPカーネルは http://people.redhat.com/sgrubb/files/lspp/ から入手できる。Redhat以外のベンダーを利用している場合は、linux-2.6.22以降のカーネルを用意すればいい。
The first thing you need is a kernel that supports IPSec labeling. The easiest way (if you are using Red Hat) is to use the current Fedora rawhide kernel or the LSPP kernel. The LSPP kernel is available at http://people.redhat.com/sgrubb/files/lspp/. For the non-Red Hat users in the audience labeled IPSec is also available in the released version of linux-2.6.22.
そして、ラベル付けするためのipsec-toolが必要だ。RedhatのrawhideやLSPP版が使える。すべてをインストールしたら、ラベルつきのIPSecが使えるようになる。最初はシンプルなラベル付けされたSAの例から始めよう。
You’ll also need an ipsec-tools that is capable of labeling, rawhides or the LSPP version will do here as well. Once you have everything you need installed you can start using labeled IPSec. We’ll start with simple labeled SA’s.
まず、私は一組のテスト支援プログラムをもっていて、動作に問題が無いかどうかチェックしている。これは簡単なクライアントサーバで、互いに接続して、getpeercon()関数を使ってネットワークソケットのラベル付けを見ることができる。
First I have a couple programs that will help test and ensure that everything is working. They are simple a simple client and server that connect, use getpeercon() to return what the context of the network socket is.
client.c
server.c
これらのプログラムをlibselinuxとリンクする：
Build these by linking them against libselinux:
gcc -o client client.c -lselinux
gcc -o server server.c -lselinux
最初はIPSec無しで実行してみる。
First lets try running them without IPSec to see what happens:
私のテストマシンのアドレスは192.168.147.132 (scarecrow) と 192.168.147.130 (poisonivy)になっている。以下、お手元のテスト環境のアドレスに読み替えて欲しい。
My test machines are 192.168.147.132 (scarecrow) and 192.168.147.130 (poisonivy), obviously replace with your addresses.
サーバが192.168.147.132に、クライアントが192.168.147.132で実行されているとすると、出力は以下のようになる。
After running server on 192.168.147.132 and running client 192.168.147.132 on the other machine the output should look like this:
[root@poisonivy ~]# ./client 192.168.147.132
getpeercon: Protocol not available Received: Hello, (null) from (null)
[root@scarecrow ~]# ./server
getsockopt: Protocol not available server: got connection from 192.168.147.130, (null)
getpeercon()関数は、「protocol not available」のエラーを返すだろう。というのは、まだラベル付けをしていないからだ。このエラーを使えば、ネットワークがラベル付けされているかどうかが分かる。
getpeercon() returns protocol not available because no labeling was enabled on this connection, you can use the error to determine if you are using a labeled network socket or not.
もし、新たにSAを2台のマシンの間に接続したら、セキュリティコンテクストを設定しない限り、上記のようなエラーが出る。
If we make an SA between these 2 machines without specifying a context we’ll get the same results:
[root@scarecrow ~]# cat dev/ipsec/setkey.scarecrow.test
spdflush;
flush;
spdadd 192.168.147.130 192.168.147.132 any
- P in ipsec esp/transport//require;
spdadd 192.168.147.132 192.168.147.130 any
- P out ipsec esp/transport//require;
[root@poisonivy ~]# cat dev/ipsec/setkey.poisonivy.test
spdflush;
flush;
spdadd 192.168.147.132 192.168.147.130 any
- P in ipsec esp/transport//require;
spdadd 192.168.147.130 192.168.147.132 any
- P out ipsec esp/transport//require;
では実行してみよう。
Then run:
[root@poisonivy ~]# setkey -f dev/ipsec/setkey.poisonivy.test
[root@scarecrow ~]# setkey -f dev/ipsec/setkey.scarecrow.test
註：通信開始する際には双方のマシンでracoonを実行していないといけない。
NOTE: both machines will need to be running racoon in order to create SA’s when the connections are attempted.
サーバとクライアントが前のテストと同じ状態ならば、同じ結果が出る。setkey -Dとすれば、新しいSAを見ることができる。この場合、SA自体はラベル付けされていなことに注意。
Running server and client the same as before will give the exact same results. You can use setkey -D to see the newly created SA’s. Notice that the SA’s are not be labeled.
setkeyファイルに以下のように -ctx文を追加してみたらどうなるか：
If we add a -ctx statement to our setkey files such that:
[root@scarecrow ~]# cat dev/ipsec/setkey.scarecrow.test
spdflush;
flush;
spdadd 192.168.147.130 192.168.147.132 any
- ctx 1 1 "system_u:object_r:default_t:s0"
- P in ipsec esp/transport//require;
spdadd 192.168.147.132 192.168.147.130 any
- ctx 1 1 "system_u:object_r:default_t:s0"
- P out ipsec esp/transport//require;
setkey -DPコマンドでマシン上にあるすべてのSDPエントリを探すことができる。これまでの手続きを他のマシンの setkeyファイルについても行う。ここで注意：default_tを使ってはいけない。この例では、実際にどんなことが起こるかをやってみている。これはSAを作成した際につけられるラベルではない。このラベルはどのSPDエントリのドメインがマッチするかを検出するためのものだ。
You can use setkey -DP to see the SPD entries on each machine, note the context field in the entries.
Repeat this with the other machines setkey file. Note that you’d never use default_t in a label, this is an example to show what happens. This is _NOT_ the label that will be used to create SA’s, this label will be used in a ‘polmatch’ rule to see which SPD entries a domain can match to. This will be explained later.
setkey -f を実行するとエラーが出る。
Running setkey -f results in an error now:
[root@scarecrow ~]# setkey -f dev/ipsec/setkey.scarecrow.test
The result of line 8: Permission denied.
The result of line 14: Permission denied.
Looking for the denial:
[root@scarecrow ~]# tail /var/log/audit/audit.log | grep AVC
type=AVC msg=audit(1179150979.762:33): avc: denied { setcontext } for pid=21632 comm="setkey" scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=association type=AVC msg=audit(1179150979.895:34): avc: denied { setcontext } for pid=21632 comm="setkey" scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=association
これで良い。IPSecのSPDにラベル付けしたユーザについては保護ができる。今度は両方のマシンをpermissiveのモードにして、またsetkeyコマンドを実行してみる。今度は成功する。
This is good, it means that we can protect who sets the labels on IPSec SPD’s. For now set permissive mode on both machines and run setkey again, it should now succeed.
何度かクライアント・サーバを実行すると、以下の様な結果が見られる（クライアント側から見た情報）
Run the client and server again and you should see something like this on the client side:
[root@poisonivy ~]# ./client 192.168.147.132
Received: Hello, root:system_r:unconfined_t:SystemLow-SystemHigh from root:system_r:unconfined_t:-SystemHigh
setkey -Dを使って、新しく作られたSAを見ることができ、各エントリーの内容フィールドにnoteが取れる。下の画像を見れば、どのようにSAがラベル付けされるかイメージが湧くかもしれない。註：コネクションの両端にあるSAは都合２つ。一つは入力、もう一つは出力用で、それぞれ適切なラベル付けがされている。出力用のSAはどちらのシステムでもlocalのドメインで、入力用のSAはremoteのドメインと認識される。
You can use setkey -D to see the newly created SA’s and note the context field in each entry.
Hopefully this image conveys how the SA’s are labeled, note that each side of the connection has 2 SA’s, one incoming and one outgoing with the appropriate labels. The outgoing SA for each system is always the local domain, the incoming SA for each system is always the remote domain.
画像はChris Ashworthによるもの。私が作った図よりもシンプルで、ラベル付けされたトンネルのイメージが湧きやすい。
I’d like to thank Chris Ashworth for the graphic, it is much simpler than mine and I think gives a better understanding of the labeled tunnels.
この図で分かることは、サーバ側でgetpeercon()を実行すれば、root:system_r:unconfined_t:SystemLow-SystemHighというラベルが見えて、クライアント側だとroot:system_r:unconfined_t:-SystemHighとなるということだ。違いをもっと特定したい場合には、runconコマンドを使って、もっと別のコンテクストを設定してみるといい。
This demonstrates that the server sees root:system_r:unconfined_t:SystemLow-SystemHigh when it calls getpeercon() and the client sees root:system_r:unconfined_t:-SystemHigh. To show the difference more specifically run the client with a different context using runcon:
[root@poisonivy ~]# runcon -t httpd_t ./client 192.168.147.132
こうすると、以下のように表示される。
Received: Hello, root:system_r:httpd_t:SystemLow-SystemHigh from root:system_r:unconfined_t:-SystemHigh
サーバ側でgetpeercon()を実行すると、httpd_tというラベル付けされているのがわかる。コネクションのもう一方の端で、どのようなラベルが付いているか調べるのも同じようにする。ところで、ラベルに関するポリシーはどうなっているだろうか。
Now you can see the server sees httpd_t when it calls getpeercon(). So now we’ve seen how you can identify the process context on the other side of a connection, but what about the policy?
まず、dmesgをクリアして、setenforce 1とした後、setenforce 0を実行すると、AVCメッセージがクリアされて、プロセスが再起動される。
Lets clear out dmesg and setenforce 1; setenforce 0; to clear the AVC and start the process over.
最初に setkeyを実行して、audit2allow -d のコマンドを実行すると、以下のようになる。
First running setkey and then audit2allow -d should show:
allow unconfined_t default_t:association setcontext;
これは、unconfined_tのドメイン（通常、ユーザの実行するプログラムはこのドメインに属する）で、コンテクストをdefault_tに設定しようとしたことを示す。これは期待どおりである、なぜなら、SPDのエントリにそう書いてあったからだ。さて、dmesg -c コマンドを実行してカーネルのバッファをクリアして、runconを使ってサーバとクライアントを動かそう。
This means that unconfined_t (what your shell normally runs as) tried to set the context of an association to default_t. This is expected since we used default_t in our SPD entry. Run dmesg -c to clear the kernel buffer and try to run the server and client (with runcon):
関係ないルールを削除してしまえば、クライアント側では次のような表示がされる
Removing the irrelevant rules we should see something like this on the client side:
allow httpd_t default_t:association polmatch;
このポリシールールは、クライアント（httpd_tのドメインで実行中）が、SPDエントリに一致するものを探すことを示す。この機能があるので、ドメインが一致するSPDのエントリだけに対応するSELinuxポリシーを使うことができる。例えば、有るドメインに属するユーザでは高品質な暗号化が利用できるようにして、他のユーザには、より高速に処理できるが強度の低い暗号を使わせることができる。
This rule means that the client (running as httpd_t) attempted to match against the SPD entry we added earlier. This is useful because you can use SELinux policy to enforce which SPD entries a domain may match against. For example, if you wanted to have some domains use high quality encryption and let the others use a faster, lower quality encryption you can do that by specifying which SPD types a domain may polmatch against.
allow httpd_t self:association sendto;
これは、httpd_tのドメインのプロセスが httpd_tのラベルが付いたデータパケットを送信するということを示す。これは、ラベルに対応する受け手にパケットを送ることを意味する。注意：現在の制御方法ではどのドメインのラベルで相手にデータを送るかまでは制御できない。
This is httpd_t sending data to an association labeled httpd_t. This basically just means that it is sending to the association created for it. Note that with the current controls you can not control which domains you are sending to on the other side.
allow httpd_t unconfined_t:association recvfrom;
これが一番重要な制御例だ。httpd_tのドメインのプロセスが、unconfined_tとラベルづけされた相手からデータを受け取れるということを示している。サーバがunconfined_tで実行されていたからだ。この記法によって、相手のマシンがどのドメインに属しているかによって、自分のサーバのどのドメインとデータのやりとりができるかを示す。
This is the most significant control; it says that we are allowing httpd_t to receive from an association labeled unconfined_t, which is the result of the server running in unconfined_t. This lets you use policy to determine which domains on another machine can send data to which domains on the local machine.
allow unconfined_t default_t:association polmatch;
そして、これは、相手のドメイン（サーバ）がSPDエントリのうち、入力定義のパターンにマッチするかを調べる。注意：ここでは２つのSPDエントリが追加されて、１つは出力、１つは入力の通信に関して定義している。それぞれのドメインに属するパケットはSPDのエントリのローカルマシンのドメイン（出力側）と相手側のマシン(入力側）に適合する必要がある。
And this is the remote domain (the server) matching against the income SPD entry on this machine. Note that there were 2 SPD entries added, one for outgoing communication and one for incoming communication, both domains have to polmatch the SPD’s on the local machine (for outgoing) and the remote machine (for incoming).
サーバ側でも似たよう名アクセス拒否が起こりうるが、これまでの例を逆にするだけなので、ここでは取り上げない。
There should be similar denials on the server side, only reversed so I won’t go over those.
SELinuxを使えば、かなりのことができることがわかったと思う。サーバとクライアントの両方のポリシーをいじることができれば、双方の間で、どのドメインとどのドメインが通信しているかがわかる。これはIPC(Inter Process Communication)のアクセス制御をネットワーク上まで広げたに過ぎない。
As you can see you can do a significant amount with this technology, assuming that you control both policies (source and destination) you can be very certain which domains are talking to which domains across machines, similar to the SELinux IPC controls but across a network!
１つの応用例としては、内部向けと外部向けのブラウザを、ユーザのワークステーションで使い分けることが挙げられる。内部向けブラウザはあるドメインで実行され、機密の顧客情報を含む社内のwebアプリケーションサーバとだけ通信することができ、一方、外部向けブラウザはインターネットにアクセスできるようにする。こうすれば、外部の悪質なプログラムによって、社内データが流出する危険が減らせる。SELinuxがなければ、このような分離は困難だ。
For example, one possible application of this technology is to have an ‘internal’ and ‘external’ browser on employee workstations. The internal browser would run in a domain that is allowed to access internal company web application servers that contain confidential customer information while the external browser can access the internet. This reduces the risk that rogue internet content can compromise your internal data. This kind of separation would be much more difficult (or impossible) without SELinux’ advanced networking controls.
ラベル付けされたIPSecとnetfilter secmarkによって、SELinuxのネットワークは充実した機能を提供できる。これらの機能はどんどん進化していくだろう。乞うご期待。
Using both labeled IPSec and netfilter secmark you can do some pretty amazing things with SELinux networking, and its only going to get better, stay tuned for more information.
多くの皆さんのご尽力に感謝。
A special thanks goes out to all the people that worked hard on getting this technology where it is now and the same ones trying to push it even further to have the best secure networking infrastructure around. These people include (in no particular order): James Morris, Venkat Yekkirala, Joy Latten, Paul Moore (who implemented NetLabel), and many others.
タグ