SELinux でのロール・ベースのアクセス制御

この管理しやすいセキュリティー管理レイヤーについて学ぶ

RBAC (role-based access control: ロール・ベースのアクセス制御) は、ユーザーにロールを割り当て、そのロールにパーミッションを割り当てることで管理を単純化する一般的なセキュリティー・モデルです。SELinux (Security-Enhanced Linux) における RBAC は、ユーザーと、その下にある TE (type-enforcement: タイプ強制) モデルとの間の抽象化レイヤーとして動作します。TE モデルでは非常に粒度の細かいアクセス制御が可能ですが、このモデルは管理を容易にする目的には適していません。RBAC を行い、また Linux® ユーザーを TE ポリシーに結びつけるために、SELinux のコンテキストにおける 3 つの部分 (ポリシー、カーネル、ユーザー空間) がどのように協調動作するのかを学びましょう。

Serge E. Hallyn (sergeh@us.ibm.com), Software Engineer, IBM 

Serge Hallyn は IBM の Linux Technology Center の一員であり、Linux のカーネルとセキュリティーに関する業務を行っています。彼は College of William and Mary にてコンピューター・サイエンスの博士号を取得しています。彼はセキュリティー・モジュールをいくつか作成し、またいくつかのセキュリティー・モジュールに貢献してきました。現在は、仮想サーバー機能や、アプリケーションのチェックポイントとリスタート、POSIX ファイル機能などのサポートを追加するための業務に集中しています。



2008年 2月 13日

SELinux (Security-Enhanced Linux) に実装されているセキュリティー・ポリシーは、RBAC (role-based access control) レイヤーの下にある TE (type enforcement: タイプ強制) です。(SELinux はまた、TE とはまったく別の MLS (multi-level security) も実装していますが、この記事では MLS については触れないことにします。) TE は細粒度のパーミッションを実行するサーバーであるため、最も目立ち、従って最もよく知られています。予期せぬアクセス拒否によって何かが失敗した場合には、その原因は TE である可能性が最も高いです。TE では、あるプロセスのセキュリティー・ドメイン (そのプロセスがシステムに対して影響を及ぼすドメイン) は、そのタスクの履歴と、現在実行中のプログラムによって決定されます。

RBAC の概念は TE ほど頻繁には説明されておらず、また RBAC が TE と統合されていることから、RBAC の概念は理解しにくくなっています。RBAC は一般的に、あるロールを持つユーザーが受け付けることのできるアクセスを指定するものと考えることができます。しかし SELinux では TE によってロール・ベースのアクセスを規定します。そのため SELinux での RBAC の目的は、権限が与えられたユーザーのロールに基づいて特権を管理できるようにすること、そしてロールと組み合わせて有効なコンテキストとなる TE ドメインを指定することで (ロールが影響を及ぼす) ドメインを制限することです。

この動作を理解するために、SELinux を使ってセキュリティーを保証する、非常に単純なキャッシュ・レジスター用の会計システムを考えてみましょう。ここでは次のように非常に異なる 2 つの環境で、このソリューションについて調べます (この両方のコードが「ダウンロード」のセクションに用意されています)。

  • developerWorks の記事「SELinux from scratch」の中でゼロから作成した SELinux システム。このシステムでは、カーネルとユーザー空間の中のいくつかの部分をどのように組み合わせるのかを説明します。
  • Fedora Core 8 システム。この Fedora Core 8 システム (この記事の執筆時点では新しいものです) では、SELinux と RBAC がどのように緊密に統合されているかを説明します。

ロールを扱う

あるデパートから、レジスターの残高計算をセキュアに行うシステムを依頼されたとしましょう。すべてのキャッシュ・レジスターに対して、レジ係とマネージャーの両方が最終的な金額を計算する必要があります。ここでは最初に、cashier (レジ係) と manager (マネージャー) という 2 つのロールを定義します。そして従業員にロールを割り当て、1 人のレジ係と 1 人のマネージャーの両方が、そのレジ係のシフト時間の終わりにレジスターの金額を計算し、その金額を保証します。

SELinux システムと Fedora Core 8 システムとでは、ポリシー・ファイルは少し異なって見えるかもしれませんが、どちらのシステムでもデータの配置と金額の登録に使われているプログラムは同じです。すべてのデータは /data というディレクトリーの下に保存され、このデータにアクセスできるのは /bin/register.py というプログラムのみです。マネージャーとレジ係の両方が、このプログラム register.py を使って値を保存します。コードを単純にするために、このプログラムの機能は限定されています。レジ係が保存できるキャッシュ・レジスターの値は、そのレジ係がその日に扱った金額のみです。マネージャーは他の従業員のキャッシュ・レジスターの金額値を保存することができ、しかもマネージャーとレジ係の両方がそのレジ係のその日の金額として同じ値を保存した場合には、マネージャーはその値を正式な値として確定することができます。

レジ係 Bob が 2007年12月12日午後9:00 に register.py bob 109.95 を実行して値を保存すると、「bob 09:00 109.95.」という内容を持つファイル /data/cashier_r/bob/12-12-2007 が作成されます。次に、マネージャー Mary が午後9:25 に同じ値を保存すると、「mary 09:25 109.95.」という内容を持つファイル /data/mgr_r/bob/12-12-2007 が作成されます。最後に、Mary が午後9:27 にこの値をコマンド register.py bob commit を使って正式な値として確定すると、「mary 09:27 bob mary 109.95.」という値を持つファイル /data/final/bob/12-12-2007 が作成されます。

Bob の値と Mary の値が一致しない場合には、Mary は Bob の値を正式な値として確定することができません。Mary は Bob と話し合う必要があり、両者は値が一致するまで再計算します。値が一致したら、両者は同じ値を使って上記の /bin/register.py コマンドを再度実行します。後でデパートのオーナーが詳細に調べられるように、新しい値は前の値に追加され、また /bin/register.py bob commit コマンドは /data/cashier_r/bob/12-12-2007 と /data/mgr_r/bob/12-12-2007 の両方の、最後に入力された値を使います。

注意: ここで説明するコード・サンプルでは、すべてのアクセス制御の要求に対して SELinux を使っています。ここで説明している例では単純に、/data の下にあるすべてのファイルとディレクトリーに対して、システム上のすべてのユーザーが完全な書き込みアクセスを行えるようになっています。しかし実際にデプロイする際には、何らかの DAC (Discretionary Access Control: 任意アクセス制御) によるパーミッションも有効にすることで多層防御を実装した方がよいでしょう。どのマネージャーも、どこかの時点で /data/mgr_r/bob/ と /data/final/bob/ の下にファイルを作成したいと思うかもしれませんが、そのためには UNIX® のグループ・パーミッションを詳細に設定する必要があります。しかしここでは単純にするために、SELinux に完全に頼ってアクセス制御を行うことにします。

まず、マネージャーもレジ係も register.py プログラムを使わない限り /data の下にあるどのファイルにもアクセスできないようにします。例えば、Bob は cashier_t タイプで cashier_r ロールにログインします。しかし cashier_t は /data の下を読み取ることができません。/data の下を読み取るためには、Bob は cashier_register_t タイプに入る必要がありますが、それには /bin/register.py を実行しなければなりません。同様に、Mary は mgr_t タイプで mgr_r ロールにログインしますが、/bin/register.py を実行して mgr_register_t に入らないと /data の下にアクセスすることはできません。

実際には、最初のちょっとしたアクセス制御はログイン時に行われ、PAM モジュールが、Bob は cashier_r ロールにログインする必要があると判断します。このアクセス制御は次に、SELinux のカーネルの中にある TE サーバーが、bob_u:cashier_r:cashier_t は cashier_exec_t タイプ (管理者が /bin/register.py のみに割り当てたタイプ) のファイルを実行しない限り bob_u:cashier_r:cashier_register_t に入れないようにしています。

この強制動作はさらに register.py 自体の中でも継続され、register.py はレジ係が値を正式に確定しようとしたり、別のユーザーの値を保存しようとしたりすると拒否します。さらにそれは、SELinux のポリシーによって (そしてそのポリシーをカーネル・コードが実行することで) 強化され、cashier_register_t が /data/mgr_r または /data/final の下にあるファイルにアクセスできないようにします。


キャッシュ・レジスター・システムを実装する

キャッシュ・レジスター用の会計システムの最初の実装は、先ほど触れたように、ゼロの状態から作成した SELinux システム (「ダウンロード」セクションから入手することができます) の上で行います。以下に示すのは、完全にゼロの状態から作成したシステムの上にキャッシュ・レジスター用の会計システムを実装するためのステップです。

次のコマンドを使ってディスク・イメージ (qemu イメージはオフ) をマウントします。

mount -oloop,offset=32256 -t ext2 gentoo.img /mnt

ダウンロード」セクションから code_for_fromscratch.tgz ファイルを入手し、次のコマンドを使ってディスク・イメージの下に解凍します。

tar zxf selinuxregister.tgz -C /mnt
umount /mnt

今度は qemu イメージを起動します。

qemu -hda gentoo.img -m 512 -vnc :3 -kernel bzImage \
      -append "ro root=/dev/hda1 -p"

ログインしたら、新しいポリシーをコンパイルしてインストールし、そして新しい PAM モジュールをインストールします。

cd /usr/src
checkpolicy -c 19 -o policy.bin policy.conf
cp policy.bin /etc/
rc-update add selinuxenforce default
cp /etc/pam.d/system-auth /etc/pam.d/system-auth.orig
cp /etc/pam.d/system-auth.new /etc/pam.d/system-auth

ポリシーの中に SELinux ユーザーが作成されますが、それらのユーザーに対応する Linux ユーザーを作成する必要があります。

adduser mary
passwd mary
  (passwd)
mkdir /home/mary
adduser boss
passwd boss
  (passwd)
mkdir /home/boss
adduser bob
passwd bob
  (passwd)
mkdir /home/bob

次にデータ保存用のディレクトリー構造を作成します。

mkdir /data
mkdir /data/cashier_r
mkdir /data/mgr_r
mkdir /data/final
chmod 777 /data/*

最後にファイルシステムのラベルを変更します。

setfiles /usr/src/filecontexts /
poweroff

これでイメージが用意できました。SELinux のポリシーがロードされるように、-p フラグを付けずにイメージを再起動します。

qemu -hda gentoo.img -m 512 -vnc :3 -kernel bzImage \
      -append "ro root=/dev/hda1"

そして root としてログインし、次のコマンドを実行します。

ls /data

パーミッションが拒否されました。ログアウトし、今度は (レジ係である) bob としてログインして、例えば次のような値を登録します。

register bob 25.22

次に、システムを欺くために次のように入力してみます。

register bob commit

これはうまくいきませんでした。ログアウトし、今度は (マネージャーである) Mary としてログインします。

register bob commit

そうでした。Mary は最初に彼女自身の値を入力する必要があります。

register bob 27
register bob commit

値が一致しませんでした。Bob はどんな値を正式な値として確定したのでしょう。

cat /data/cashier_r/bob/(day)

そうでした。皆さんはその値を見るように許可されていません。Bob のところに行き、彼と話し合う必要があります。おそらく皆さんがレジスターの値を再度計算すると、Bob が正しかったことがわかるはずです。そして次のように入力します。

register bob 25.22
register bob commit

これはうまく行きました。今度は root としてログインし、そして次のように入力します。

cat /data/final/bob/(day)

これによって、これまで入力されたすべての値が表示されます。


TE を詳細に調べる

さまざまなユーザーが、同じ /bin/register プログラムを使用することによって、(このプログラムを使わなければアクセスできない) さまざまなファイルを読み書きすることができます。これが TE の中心的な概念です。つまり、許可されたユーザー・コンテキスト、そして実行されるコードの両方によって、その結果としてのプロセスがシステムに及ぼす「影響のドメイン」(または TE ドメイン) が決まるのです。

図 1 は、ここに挙げたシステムでのドメインとタイプを示しています。

図 1. ドメインとタイプ
ドメインとタイプ

しかし、Bob がマネージャーとしてログインしたり、あるいは Mary がレジ係としてログインしたりすることを、一体何が防いでいるのでしょう。もっと興味深い問題として、Boss (上司) はどのような方法でレジ係とマネージャーの両方としてログインするのでしょう。

最初の質問に関しては、新しい PAM モジュールが行っています。簡単に言えば、PAM (pluggable authentication modules) を使うことで、さまざまな認証ステップで小さなコード片を実行することができ、またどのモジュールをいつ実行するのかを柔軟に指定することができます。ここでは新しい PAM モジュール (pam_ctx.so) を導入しており、このコードは /usr/src/pam_ctx の下にあります。この PAM モジュールは認証されているユーザー名を探すために /usermap.conf ファイルを検索し、またこのユーザーに対するデフォルト・コンテキストを発見します。Bob の場合には、このデフォルト・コンテキストは cashier_u:cashier_r:cashier_t です。Mary の場合には mgr_u:mgr_r:mgr_t であり、Boss の場合には full_u:mgr_r:mgr_t です。すべてのコンテキストが、コロンで区切られる 3 つの部分で構成されていることに注目してください。これらの 3 つの部分のうち、

  • 最後の部分はドメインです。これによって、そのシステム上でのそのユーザーのパーミッションが最終的に決まります。
  • 2 番目の部分はロールです。これによって、ユーザーがアクセスすることのできるドメインを制限します。
  • 最初の部分は「SELinux ユーザー」です。ロールとドメインの場合と同じように、この部分によって、プロセスが入ることのできるロールを制限します。

PAM モジュールはコンテキストを設定するために、そのコンテキストをファイル /proc/$$/attr/exec に書き込み、次に新しいドメインに対する有効なエントリー・タイプであるシェルを実行します。ポリシーのソースを見ると、mgr_r は mgr_t ドメイン、mgr_register_t ドメイン、そして rolechange_t ドメインとしか関連付けできないことがわかります。cashier_r ロールは cashier_t ドメインと cashier_register_t ドメインとしか関連付けできません。同様に、SELinux ユーザー mgr_u は mgr_r ロールとしか関連付けできず、cashier_u は cashier_r としか関連付けできません。full_u というユーザーは mgr_r または cashier_r のいずれかと関連付けすることができます。

図 2 は、これらの各部分が互いにどのように関係しているかを示しています。

図 2. 各部分の相互関係
各部分の相互関係

一番上の行は SELinux ユーザーを表しており、真ん中の行はロールの一覧、一番下の行はドメインの一覧です。有効なセキュリティー・コンテキストは各行から 1 つの項目を選択することで作成できますが、その 3 つの項目は必ず接続されている必要があります。ポリシーでは、以下のユーザー定義によって、ユーザーの 1 つと、そのユーザーとロールとの接続を定義します。

user full_u roles { mgr_r cashier_r };

一方、以下のようなロール定義によって、

role cashier_r types { cashier_t cashier_register_t };

真ん中の行の項目と、一番下の行との接続を定義します。

しかし、なぜ Bob は単純に「full_u:mgr_r:mgr_t」を /proc/$$/attr/exec の中に書き込めないのでしょう。この理由はいくつかあります。1 つの理由は先ほどの TE のためです。図 1 をもう一度見てみると、cashier_t タイプの場合には cashier_write_t に遷移することしかできません。また SELinux のポリシーには、どのロール遷移が許可されるかが指定されており、そこに記されている以下のポリシー行は、

allow mgr_r cashier_r;

mgr_r ロールのプロセスを cashier_r ロールの有効なコンテキストに切り替えてもよいという指定をしています。しかし、以下のような行はポリシーにはありません。

allow cashier_r mgr_r;

そのため Bob は、cashier_r からどのコンテキストにも遷移することができないのです。

また、Mary が cashier_t のドメインに入ることも拒否しています。 図 1 を見ると、実際にはこのドメイン遷移そのものは許可されており、以下のポリシー行でもロールの遷移は許可されています。

allow mgr_r cashier_r;

しかしポリシーでは、最初に /bin/role_change というエントリー・ポイントから rolechange_t に入ることで遷移を行う必要があると規定しています。このプログラムは、そのロールのコンテキストの SELinux ユーザー部分をリライトしません。従って、いったん mgr_u:mgr_r:mgr_t にログインすると、/usermap.conf ファイルで許可された (pam_ctx.so モジュールによって実行される) 有効な full_u ユーザーとして再度ログインしない限り、cashier_r ロールに遷移する方法がありません

ポリシーの中で、禁止しなかったことが 1 つあります。SELinux ユーザーの遷移に対する制御が最初からないことに注意してください。そうした制御はすべて SELinux ユーザーをロールとドメインに結びつけて行う必要があり、ロールとドメインの遷移によって別の SELinux ユーザーの有効なコンテキストに遷移することがないようにします (ただしこれは、そのように遷移することが望ましくない場合の話です)。

ここで、次のような例を試してみましょう。root としてログインし、コンテキストを表示するように /bin/register.py を変更します。新しいファイル addme に何行かを追加し、次にこのファイルを /bin/register.py の先頭近くに挿入します。

echo 0 > /selinux/enforce
cat > /root/addme << EOF
f=open("/proc/self/attr/current", "r")
print f.readlines()
f.close()
EOF
nano /bin/register.py

今度は下向きの矢印を使って、カーソルを import の行の下に移動し、Read File という意味で Control-r を入力し、そして /root/addme と入力します。次にファイルを書き込むために Control-O を入力し、ファイル名を確認して return を押し、そして Control-X を入力して終了します。最後に SELinux を強制モードに戻します。

echo 1 > /selinux/enforce
logout

bob としてログインし、明示的に SELinux にドメイン遷移を要求し、そして register.py を実行します。

echo "full_u:cashier_r:cashier_register_t" > /proc/self/attr/exec
/bin/register.py bob 25

これで、register.py は full_u:cashier_r:cashier_register_t として実行しています。コンテキストを /proc/pid/attr/exec ファイルにエコー出力すると、SELinux は次の exec 実行時にそのコンテキストに遷移しようとします。もちろん、この遷移は遷移が有効でないと起こりません。この場合には遷移は有効でした。これは、ロールを変更しておらず、また cashier_exec_t タイプのファイルを実行する cashier_t は cashier_register_t に遷移することが許可されているためです。次のコマンドを試してみると、

echo "full_u:mgr_r:mgr_register_t" > /proc/self/attr/exec
/bin/register.py bob 25

パーミッションが拒否されることがわかります。最後に、次のコマンドを試してみると、

echo "full_u:mgr_r:cashier_register_t" > /proc/self/attr/exec
/bin/register.py bob 25

今度はパーミッションは拒否されませんでしたが、コンテキストは cashier_u:cashier_r:cashier_register_t とレポートされています。なぜ動作が異なるのでしょう。その理由は、full_u:mgr_r:mgr_register_t は有効なコンテキストであったため次の exec 実行では実際にドメイン遷移が試行され、そして失敗しています。しかし mgr_r は cashier_register_t と関連付けられていない可能性があるため、full_u:mgr_r:cashier_register_t が有効なコンテキストだとはとても言えません。もし、コンテキストを /proc/self/attr/exec の中にエコーした後に戻り値をチェックしていたら、これが失敗していたことがわかったはずです。

echo "full_u:mgr_r:cashier_register_t" > /proc/self/attr/exec
echo $?
    1

したがって、その次に register.py を実行すると register.py は要求されたドメイン遷移を試行せず、単純にデフォルトのドメイン遷移を行い、そして成功しています。

この時点では、ロールや SELinux ユーザーを使わず TE のみを使用すれば目標を達成できたのではないか、と思う人がいるかもしれません。しかしロールとユーザーを使うと今後のシステム管理が容易になるのです。この点は、このシステムを Fedora Core 8 で実装する方法を見るとよくわかるはずです。これを次に説明しましょう。


Fedora Core 8 を使う

Fedora 8 はデフォルトで SELinux が有効になっています。Fedora 8 には新しい SELinux 技術が統合されており、ロード可能ポリシー・モジュールを使って容易にポリシーをカスタマイズすることができ、また semanage を使ってユーザー管理や RBAC 管理を容易に行うことができます。(semanage は、SELinux のポリシーの特定の要素を構成するために使われますが、ポリシーのソースの変更や再コンパイルを必要としません。)

ではまず、あまり面白味のない、ほとんどデフォルトのインストールから始めましょう。最初に Fedora-8-i386-DVD.iso をダウンロードします (下記の「参考文献」にあるリンクを参照してください)。このファイルは f8.img とリネームしておくと便利かもしれません。これを cdrom イメージとして使い、Fedora 8 を qemu の下にインストールします。

dd if=/dev/zero of=f8.img bs=1G seek=10 count=1
qemu -hda f8.img -cdrom f8.iso -boot d -m 1024 -vnc 3

次に VNCviewer を起動します。

vncviewer :3

VNC ウィンドウの中で、完全にデフォルトのインストールを行うための手順に従いますが、1 つだけ例外があります。インストールするパッケージを尋ねられたら、「Office and Productivity」の選択を外し、「Software Development」を選択します。

インストールが完了したら、リブートの後、指示に従ってセットアップの手順を続行し、そして root ではないアカウントを選択して作成します。最後に、イメージの用意ができたら、そのユーザーとしてログインします。

ブラウザー・ウィンドウを開いてこの記事にアクセスし、Fedora 8 用のソースの tarball をダウンロードします (「参考文献」のリンクを参照してください)。この tarball を ~myuser/cash_register_f8.tgz としてホーム・ディレクトリーに保存します。

最上部左側にある「Applications」メニューから System Tools > Terminal を選択します。次に su - と入力し、そして root パスワードを入力して root シェルを開きます。これで、レジスターの残高計算をセキュアに行うシステムのセットアップ準備ができました。

(注意: 耐えられないほどシステムが遅いと思える場合には、ランレベル 3 に入って X ウィンドウを終了します。そのためには /sbin/init 3 と入力します。/sbin/init 5 を使ってランレベル 5 に再度入れば、いつでも X ウィンドウを再起動することができます。ランレベル 3 では端末に root としてログインします。)

まず、バックグラウンドのデーモンを強制的に終了し、手動で yum を実行できるようにします。

killall -9 yum-updatesd

次に、SELinux のポリシー・モジュールの開発パッケージをインストールします。

yum install selinux-policy-devel.noarch

今度はサンプルのポリシー・モジュール・ディレクトリーをコピーし、そのサンプル・ディレクトリーにキャッシュ・レジスターのポリシー・ファイルをコピーして、それらのファイルをコンパイルします。

cd /usr/share/selinux/
cp -r devel cash_register
cd cash_register
rm example.*
tar zxf ~myuser/cash_register_f8.tgz
mv register.py /bin
make

このポリシーが、ファイル cash_register.pp の中にあるバイナリーのポリシー・モジュールの中にコンパイルされるので、次のコマンドを使ってこのポリシーをロードします。

semodule -i cash_register.pp

次に、ユーザー (mary と bob) を作成します。

adduser bob
adduser mary
passwd bob
passwd mary

これでユーザーが存在するようになったので、これらのユーザーが適切なロールにログインできるように RBAC をセットアップします。

semanage user -a -R cashier_r -P cashier bob_u
semanage login -a -s bob_u bob

semanage user -a -R mgr_r -P mgr mary_u
semanage login -a -s mary_u mary

semanage user コマンドによって新しい SELinux ユーザーが作成されます。この SELinux ユーザーは Linux のユーザー名ではなく、プロセスとファイルに付加される SELinux のコンテキスト (id -Z と入力するとコンテキストが返ってきます) の最初の部分です。端末で id -Z と入力すると、system_u または unconfined_u が表示されるかもしれません。Linux のユーザー名と SELinux ユーザー名とを同じにすることはできますが、それだけで両者が関連付けられるわけではありません。しかしログインのプロセスでは、セキュリティー・コンテキストのための SELinux ユーザーを Linux のユーザー名を使って選択します。この前のセクションで説明したとおり、SELinux ユーザーと関連付けられるロールは制限されており、それと同様に、SELinux のロールと関連付けられる SELinux のドメイン (タイプ) も制限されています。

ここでは semanage user を使って 2 人の SELinux ユーザー (mary_u と bob_u) を作成しています。同時に、これらのユーザーと関連付けられるロールも指定しています。ユーザー bob_u は cashier_r ロールしか使用することができず、mary_u は mgr_r しか使用することができません。また、ユーザーのホーム・ディレクトリーのタイプに対する接頭辞を指定する必要があります。Mary の場合には mgr を指定します。これによって Mary のホーム・ディレクトリーは mgr_home_dir_t になり、またその中にあるファイルは mgr_home_t になります。

semanage login コマンドによって Linux のユーザー名と SELinux ユーザーが結びつけられます。ここでは、mary が mary_u としてログインするように、そして bob が bob_u としてログインするように指定します。

この場合もやはり、キャッシュ・レジスターの値のための暫定的なディレクトリー構造を作成する必要があります。

mkdir /data
mkdir /data/final
mkdir /data/cashier_r
mkdir /data/mgr_r
chmod 777 /data/cashier_r
chmod 777 /data/mgr_r
chmod 777 /data/final

最後に、作成され、インストールされたすべてのファイルと、新しいユーザーに対するホーム・ディレクトリーのラベルを変更します。

fixfiles -f relabel /data /bin/register.py /home

今度はポリシーの中で SELinux ユーザーを定義しなかったことに注目してください。そうしなくても semanage コマンドがユーザーを作成し、ユーザーを適切なロールに関連付けてくれたのです。

単に bob が cashier_r としてログインでき、また mary が mgr_r としてログインできるようにしたいだけであれば、このままで何も問題はありません。しかしおそらく皆さんは、charlie というユーザーが mgr_r または cashier_r としてログインできるようにする必要があるはずです。そのためには、もう少し変更が必要です。まず、このユーザーを作成します。

adduser charlie
passwd charlie
semanage user -a -R mgr_r -R cashier_r -P mgr charlie_u
semanage login -a -s charlie_u charlie

今度は charlie がどちらのロールでログインしたいのかを charlie に尋ねるよう PAM に命令します。まず /etc/pam.d/login を開き、

session required pam_selinux.so open

という行を、次の行で置き換えます。

session required pam_selinux.so open select_context

この行は pam_selinux.so モジュールに対して、ユーザーがログイン時にデフォルトのコンテキストを選択できるように指定しています。次にシステムに対して、charlie_r というロールに対して使用するデフォルトのタイプを指定します。Charlie はログインする際に、デフォルト以外のロールを指定することができます (デフォルトのロールは mgr_r です。これは semanage user コマンドの中で mgr_r を最初に記載リストしてあるためです)。選択できるロールは、そのユーザーを作成した際に -R フラグを使って指定した任意のロールです。すると SElinux は、要求されたロールに関連付けられたデフォルトのタイプを使います。そのため、cashier_r に対するデフォルトのタイプを次のように指定する必要があります。

echo "cashier_r:cashier_t" >> \
      /etc/selinux/targeted/contexts/default_type

これで、Charlie がコンソールからログインすると (Ctrl-Alt-F2 を使ってコンソールに切り替えるか、あるいは先ほど説明したようにランレベル 3 に入るかすると)、どちらのロールでログインするのかを尋ねられます。デフォルトは mgr_r ですが、デフォルトの代わりに cashier_r に入ることもできます。cashier_r に入ると、Charlie はレジ係としての自分の値を保存することができますが、先ほど定義したポリシーの結果、彼は自分のホーム・ディレクトリーにあるどのファイルも読むことはできません。

注意点として、register.py は、Charlie がマネージャーとレジ係の両方として自分のキャッシュ・レジスターの金額値を保存し、そしてその値を正式な値として確定するのを防ぐことができません。もちろん、このような変更は簡単に実装できるはずです。


ダウンロード

内容ファイル名サイズ
Sample from-scratch codecode_for_fromscratch.tgz7KB
Sample Fedora Core 8 codecode_for_f8.tgz2KB

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=310376
ArticleTitle=SELinux でのロール・ベースのアクセス制御
publish-date=02132008