追記:2020-06-05
このエントリの背景が雑だったので以下に補足記事を書きました。先にこちらに目を通していただいた方が良いかもしれません。
https://hb.matsumoto-r.jp/entry/2020/06/05/110709
speakerdeck.com
今tcprivというソフトウェアを開発しているのだが、細かい内容については上記のスライドを見てもらうとして、やりたいことは、TCPセッションを確立するプロセスのオーナ情報を接続先のプロセスで透過的に検証するという処理である。
github.com
以下ではその実装の概要を紹介しつつ、今検討していることについてお話したい。
接続元プロセスは一般ユーザを想定しており、脆弱性などによって悪意のあるユーザにのっとられることもありうるし、とあるプロセスが利用する認証情報も漏れることがあることを想定している。
しかし、情報が漏れたとしても、適切なオーナからとそのオーナに紐付いた認証情報を利用しないと、リモート先のプロセスで認証を拒否出来るようなしくみを考えている。
いわゆる多要素認証のサーバ間通信版と考えてもよいのかもしれない。
例えば、とあるマルチテナントシステム間連携において、とあるプロセスが利用しているDBのID/PASS、あるいは、トークンが漏れた時に、それらの認証情報を使って、同システム内の別のオーナのプロセスがDBに接続を試みた場合、オーナが違うのでID/PASSやトークンが一致していても認証を通さない。
マルチテナント型のマネージドシステム内で、プロセスレベルで隔離はされているがOS上に共存しているプロセスや、同じIPアドレスが割り当てられているコンテナなどを接続元として想像すると良いかもしれない。
あとはレンタルサーバの例えばWordPress的なWebアプリケーションとか。
オーナや権限で分離されている沢山のWordPressにおいて、たとえはとあるWordPressのDB接続のためのID/PASSが漏れたとしても、そのID/PASSを使うべきプロセスオーナからのみしかそのID/PASSの認証を接続先のDBで認証しない、というようなケースである。
また、接続時にオーナの情報を詐称できないように、その一連のオーナに関する情報をカーネル側で透過的に実現している。
すなわち、認証情報がもれた当該プロセスからのみのアクセスや脆弱性で乗ったられたプロセスからのみしか、認証情報を利用して接続できなくなるので、被害範囲を局所化できる。
オーナ情報の付与を透過的にカーネルで実現するために、カーネル内のNetfilterのフックポイントを利用して、カーネルモジュールによりカーネルのTCPスタック前後でTCPオプションヘッダにオーナ情報を書き込む領域を定義し、書き込んでいる。
static int __init tcpriv_init(void)
{
printk(KERN_INFO TCPRIV_INFO "open\n");
printk(KERN_INFO TCPRIV_INFO "An Access Control Architecture Separating Privilege Transparently via TCP Connection "
"Based on Process Information\n");
nfho_in.hook = hook_local_in_func;
nfho_in.hooknum = NF_INET_LOCAL_IN;
nfho_in.pf = PF_INET;
nfho_in.priority = NF_IP_PRI_FIRST;
nf_register_net_hook(&init_net, &nfho_in);
nfho_out.hook = hook_local_out_func;
nfho_out.hooknum = NF_INET_LOCAL_OUT;
nfho_out.pf = PF_INET;
nfho_out.priority = NF_IP_PRI_FIRST;
nf_register_net_hook(&init_net, &nfho_out);
return 0;
}
こんな感じで、ローカルに入ってきたパケットと出ていくパケットをフックしている。
出ていくフェーズ、すなわち、リモートサーバにTCPで接続しにいくような状況では、synパケット送出時にオプションのチェックとtcprivオプションのセット(tcpriv_tcp_syn_options)、さらに、定義した実験的TCPオプションフィールドにオーナ情報を書き込んでいる(tcpriv_tcp_options_write)。
static unsigned int hook_local_out_func(void *priv, struct sk_buff *skb, const struct nf_hook_state *state)
{
struct iphdr *iphdr = ip_hdr(skb);
struct tcphdr *tcphdr = tcp_hdr(skb);
if (iphdr->version == 4) {
if (iphdr->protocol == IPPROTO_TCP && tcphdr->syn) {
struct tcp_out_options opts;
struct sock *sk;
struct tcp_md5sig_key *md5;
printk(KERN_INFO TCPRIV_INFO "found local out TCP syn packet from %pI4.\n", &iphdr->saddr);
sk = state->sk;
memset(&opts, 0, sizeof(opts));
tcpriv_tcp_syn_options(sk, skb, &opts, &md5);
tcpriv_tcp_options_write((__be32 *)(tcphdr + 1), NULL, &opts);
}
}
return NF_ACCEPT;
}
現在、IANAが規定しているTCPオプションヘッダは複数存在し，同時に，HOST_IDやLinuxカーネルバージョン5系で実装されているShared Memory communications over RMDA protocol(以降SMC-R)*1といった実験的なTCPオプションも存在する。
例えばTCP Fast Open Coolieは2014年に標準化され、IANAから正式なTCPオプションとしてkindナンバーを付与されている。
一方で、比較的新しいTCPオプションであるため、依然としてLinuxカーネルのバージョンによっては、実験的なkindナンバーを共有して他の実験的なTCPオプションと利用する実装になっている*2。
そのため、実装においては、TCP Fast Open Cookieが固有のkindナンバーを保つ場合と共有の実験的なkindナンバーを持つ場合を想定して実装を行っている。
また、Linuxカーネルバージョン5系においては、共有の実験的なkindナンバーにSMC-Rを利用しているため、IANAからSMC-Rに割り当てられているTCP Experimental Option Experiment Identifiers(以降TCP ExIDs)*3とは別のTCP ExIDsを暫定で割り振って区別する。
特にパケットのTCPヘッダオプションフィールドの解析を行う際に、既存のTCPオプションはそのままに、提案手法用の実験的オプションの共有kindナンバー、データレングス、TCP ExIDs、キー情報を書き込む。
実験的オプションの仕様を忘れていると、ExIDsの定義を忘れちゃうので注意。
書き込み処理は以下のような感じ。
static void tcpriv_options_write(__be32 *ptr, u16 *options)
{
if (unlikely(OPTION_TCPRIV & *options)) {
kuid_t uid = current_uid();
kgid_t gid = current_gid();
*ptr++ = htonl((TCPOPT_NOP << 24) | (TCPOPT_NOP << 16) | (TCPOPT_EXP << 8) | (TCPOLEN_EXP_TCPRIV_BASE));
*ptr++ = htonl(TCPOPT_TCPRIV_MAGIC);
TODO
*ptr++ = htonl(uid.val);
*ptr++ = htonl(gid.val);
}
}
static void tcpriv_tcp_options_write(__be32 *ptr, struct tcp_sock *tp, struct tcp_out_options *opts)
{
u16 options = opts->options;
if (unlikely(OPTION_MD5 & options)) {
*ptr++;
ptr += 4;
}
if (unlikely(opts->mss)) {
*ptr++;
}
if (likely(OPTION_TS & options)) {
if (unlikely(OPTION_SACK_ADVERTISE & options)) {
*ptr++;
options &= ~OPTION_SACK_ADVERTISE;
} else {
*ptr++;
}
*ptr++;
*ptr++;
}
if (unlikely(OPTION_SACK_ADVERTISE & options)) {
*ptr++;
}
if (unlikely(OPTION_WSCALE & options)) {
*ptr++;
}
if (unlikely(opts->num_sack_blocks)) {
int this_sack;
*ptr++;
for (this_sack = 0; this_sack < opts->num_sack_blocks; ++this_sack) {
*ptr++;
*ptr++;
}
}
if (unlikely(OPTION_FAST_OPEN_COOKIE & options)) {
struct tcp_fastopen_cookie *foc = opts->fastopen_cookie;
u8 *p = (u8 *)ptr;
u32 len;
if (foc->exp) {
len = TCPOLEN_EXP_FASTOPEN_BASE + foc->len;
p += TCPOLEN_EXP_FASTOPEN_BASE;
} else {
len = TCPOLEN_FASTOPEN_BASE + foc->len;
*p++;
*p++ = len;
}
ptr += (len + 3) >> 2;
}
tcpriv_options_write(ptr, &options);
}
続いて、入ってくるフェーズでは、syncパケット受信時にTCPオプションヘッダフィールドをparseし、オプションが定義されていれば当該フィールドからオーナ情報（uid32bit+gid32bit）を取得するようにしている(tcpriv_tcp_parse_options)。
static unsigned int hook_local_in_func(void *priv, struct sk_buff *skb, const struct nf_hook_state *state)
{
struct iphdr *iphdr = ip_hdr(skb);
struct tcphdr *tcphdr = tcp_hdr(skb);
struct tcp_options_received tmp_opt;
if (iphdr->version == 4) {
if (iphdr->protocol == IPPROTO_TCP && tcphdr->syn) {
printk(KERN_INFO TCPRIV_INFO "found local in TCP syn packet from %pI4.\n", &iphdr->saddr);
memset(&tmp_opt, 0, sizeof(tmp_opt));
tcpriv_tcp_clear_options(&tmp_opt);
tcpriv_tcp_parse_options(&init_net, skb, &tmp_opt, 0, NULL);
}
}
return NF_ACCEPT;
}
parseについては、カーネルのコードを存分に参考にしながら、ひとつずつオプションフィールドのフラグとレングスのチェックを行って、tcprivオプションがああればその情報を取得するようにしている。
static void tcpriv_parse_options(const struct tcphdr *th, struct tcp_options_received *opt_rx, const unsigned char *ptr,
int opsize)
{
if (th->syn && !(opsize & 1) && opsize >= TCPOLEN_EXP_TCPRIV_BASE && get_unaligned_be32(ptr) == TCPOPT_TCPRIV_MAGIC) {
TODO
u32 uid, gid;
uid = get_unaligned_be32(ptr + 4);
gid = get_unaligned_be32(ptr + 8);
printk(KERN_INFO TCPRIV_INFO "found client process info: uid=%u gid=%u\n", uid, gid);
}
}
void tcpriv_tcp_parse_options(const struct net *net, const struct sk_buff *skb, struct tcp_options_received *opt_rx,
int estab, struct tcp_fastopen_cookie *foc)
{
const unsigned char *ptr;
const struct tcphdr *th = tcp_hdr(skb);
int length = (th->doff * 4) - sizeof(struct tcphdr);
ptr = (const unsigned char *)(th + 1);
opt_rx->saw_tstamp = 0;
while (length > 0) {
int opcode = *ptr++;
int opsize;
switch (opcode) {
case TCPOPT_EOL:
return;
case TCPOPT_NOP:
length--;
continue;
default:
if (length < 2)
return;
opsize = *ptr++;
if (opsize < 2)
return;
if (opsize > length)
return;
switch (opcode) {
case TCPOPT_EXP:
if (opsize >= TCPOLEN_EXP_FASTOPEN_BASE && get_unaligned_be16(ptr) == TCPOPT_FASTOPEN_MAGIC) {
} else if (th->syn && !(opsize & 1) && opsize >= TCPOLEN_EXP_SMC_BASE &&
get_unaligned_be16(ptr) == TCPOPT_SMC_MAGIC) {
} else {
tcpriv_parse_options(th, opt_rx, ptr, opsize);
}
break;
}
ptr += opsize - 2;
length -= opsize;
}
}
}
これでめでたしめでたし、リモート先のプロセス側で接続元プロセスのオーナ情報を取得できるわけであるが、さてここからユーザランドで動作するミドルウェア等でこのデータをどのように取得するかを考える必要がある。
現状では、以下の図にあるように、socket APIを使うあるいは同様のAPIを実装することによって、tcprivオプションが有効化どうかをチェックする関数を用意する。
それを用いて、ミドルウェア、あるいは、その前端においたミドルウェア対応のプロキシで、セッションを確立する際にその関数でtcprivオプションをチェックする。
その上で、tcprivオプションがenabledであれば/procファイルシステムの指定の場所に、tcpriv/ipaddress+src-portみたいなファイルを見ると、接続元のオーナ情報が取得できるようにしておき、それを行える関数を用意する。
そのためにも、tcprivを実装しているカーネルモジュールの中で、オーナ情報をparseした後に、その情報を/proc以下に書き込むようにしておく。
すると、TCPセッション確立時に接続元プロセスのオーナ情報を取得できるので、その段階、あるいはミドルウェアとしての認証を行う段階で、そのオーナ情報を従来のID/PASSやトークンを突き合わせることで認証行う。
とまあ、ここまでが頭の中で大体できそうだと考えている設計なのだが、もっとシンプルにオーナ情報をユーザランドでセッション確立時に取得できる方法はないかと最近考えている。
scoket APIを作ったり拡張したりすることはできるが、もう少し、うまく/procにtcprivに関する情報を配置するだけで、セッション確立時にあわよくば関数を使わなくてもreadとかだけで扱えるような設計はないか検討している。
もしアイデアがありましたら、ご教示いただけると幸いでございます。
