ICTSC Tech Blog

部署を統合したが…

ICTSC2020 問題解説

この問題は、SELinuxのmls(multi level security)を使った問題でした。
間違ったカテゴリ・クリアランスのユーザーを修正し、目的のファイルの閲覧ができるようにします。

問題名

部署を統合したが…

概要

部署と権限が複数ある企業内部にて、部署Aを部署Bに統合することになった。
そのため、ファイル側の所属や権限を変更せずに、お互いの部署の人間がお互いの部署のファイルを読めるようにして欲しいとの連絡が来た。
また、同時期に昇格したユーザーも居るとのことである。

問題1. 部署Bの社員が部署Aのファイルを見れないと報告が来ている。
問題2. 部署Aの社員が部署Bのファイルが見れないと報告が来ている。
問題3. ユーザー1は部長に昇格した。しかし昇格したのにも関わらず、部署Bの部長以上が見れるはずのファイルが見れないと報告が来ている。

統合について、社内の書面での手続きは完了したが、システムの修正は完了していないらしいので、合併作業を頑張って完了させてください

前提条件

  • 注意事項
  • セキュリティ機能を無効にしたり、別のツールで代替してはいけない
  • 作業中一時的にセキュリティ機能が無効になるのは良いこととする (永続化はダメ)
  • 権限について
  • 部署に所属しているファイルはその部署に所属している人間しか見れない
  • 特定の職位以上のユーザーしか見れないファイルがある
  • 今回はファイルの権限を変えてはいけない(ユーザー側の権限を変える必要がある)

以上の原則を破ってはいけない

  • ユーザーについて
  • ユーザー1のユーザー名: employee1
  • ユーザー2のユーザー名: employee2
  • ユーザー1は部署Aに所属していた (今回の合併で部署Bに移動する)
  • ユーザー2は部署Bに所属している
  • ユーザー1は課長だった (昇進したため部長になった)
  • ユーザー2は部長である

※一つの部署に部長が複数人居ることになるが問題ない

  • 部署Aがなくなり部署Bに統合された。
  • それにあたって、部署Aのファイルは部署Bへ譲渡された
  • それにあたって、部署Aの社員は部署Bへと移動した
  • ファイルについて
  • ファイル1: /srv/department/A/file1.txt
  • ファイル2: /srv/department/B/file2.txt
  • ファイル3: /srv/department/B/file3.txt
  • ファイル1は部署Aに所属していた (今回の合併で部署Bからも見れるようになる)
  • ファイル2とファイル3は部署Bに所属している
  • ファイル1とファイル3は課長以上のみ読める
  • ファイル2は部長以上のみ読める

初期状態

  • ユーザー1がファイル3を見れない
  • ユーザー1がファイル2を見れない
  • ユーザー2がファイル1を見れない

終了状態

  • ユーザー1がファイル3を見れる
  • ユーザー1がファイル2を見れる
  • ユーザー2がファイル1を見れる

接続情報

VM名 ホスト名 ユーザ パスワード
irn-vm1 192.168.6.1 user ictsc2020
irn-vm1 192.168.6.1 employee1 ictsc2020
irn-vm1 192.168.6.1 employee2 ictsc2020

補足

いくつかのチームから「ユーザー1がファイル1を読めない」「ユーザー2がファイル2,3を読めない」との質問がありました。
初期状態では適切な権限を持っている人でも読むことができません。これは想定状態です。
問題文では、あたかも問題1・問題2・問題3以外のファイルはトラブルなく読めるような書き方をしてしまいました。誤解を招き申し訳ありません。


解説


ユーザーが複数ありますが、staff_uという高い権限を持っているのはuserユーザーのみです。

よって、まずuserユーザーでsshログインをします。


SELinuxの無効化を実行する権限がないので、userユーザーをstaff_rからsysadm_rに昇格させます。


sudo newrole -r sysadm_r


次に、SELinuxの状態を変更するために、SELinuxを無効にします


sudo setenforce 0


ここで、SELinux系の管理コマンドを打とうとすると、ファイルが足りなくてエラーが出るため、修復します。


sudo yum install 'dnf-command(reinstall)'
sudo yum reinstall selinux-policy-mls


または、semoduleでも可能です。


sudo semodule -B


次に、それぞれのファイルのコンテキストを見ると、レベルとカテゴリが、課長はs1、部長がs2、部署Aがc100、部署Bがc200なことがわかります。


sudo ls -laZ /srv/department/A/
s1:c100 file1.txt

sudo ls -laZ /srv/department/B/
s2:c200 file2.txt
s1:c200 file3.txt



そのため、SELinuxのコマンドで、ユーザーがログインしたあとのMLSを変更します。


    

  1. sudo semanage login -m -r s1:c100,c200 employee1
    2. 

  2. sudo semanage login -m -r s2:c100,c200 employee2
    3. 

  3. sudo semanage login -m -r s2:c100,c200 employee1
    4. 



それぞれ対応した問題を解決するコマンドです。ユーザーに適切なカテゴリとレベルを割り当てます。


また、staff_u:object_r:var_tのコンテキストは不正なので、chconにて所属SELinuxユーザーをsystem_uに変更します。


sudo chcon -R -u system_u /srv/department


あとはSELinuxを有効にして終了です


sudo setenforce 1


※ちなみに、SELinuxのラベルの末尾にあるカテゴリ・レベルですが、ハイフンはレベルの幅を示しているのではなく、デフォルトのレベルと、可能なレベルを区切る文字となっています。

そのため、初期状態のs0-s1:c100などでは、完全一致ではないためs1のファイルへの読み書きができません。これが初期状態で既にユーザー1がファイル1を、ユーザー2がファイル2,3を見れない理由です。


採点基準


    

  • 点数: 150点満点
    • 

  • SELinuxが原因だと分かったら10%
    • 

  • 問題が一つ解けるごとに30%
    • 



合計で100%となっています。


総評


去年のSELinux問題とは違い、今年は自分でポリシーを書かせるようなことはせず、コマンドを実行するのみで終了するため、解答の手間自体は簡単になりました。

しかし、MLSの概念を知らなかったり良い解説に辿り着けないと、コマンドに与えるべきカテゴリなどの引数がわかりにくかったかもしれません。

おそらくそれが原因で、どの解答も3つの小問題を全て解決した解答になっていました。1つ解ければ他も解きやすかったのかなと思います。


また、複数のチームから解答が来ましたが、残念ながら最後にファイルのSELinuxユーザーをsystem_uに変更し忘れてアクセスができなかった解答が多かったです。

ファイルのラベルは、ロールはobject_rになるため必然的にドメインであるvar_tやusr_tに気が向いてしまいますが、ファイルにも所持SELinuxユーザーがあります。

また全てのコンテキストには、妥当なSELinuxユーザーがいるため、不適切なSELinuxユーザーと適切なドメインをファイルに与えても、強制的に巻き戻されてしまいます。

ここが気付けるかかがポイントでした。


SELinux自体はそこそこ有名ですが、その殆どはプロセスのアクセス制御を行うMACとRBACしか注力されていません。MLSはプロセスではなく文書としてのファイルに視点を置いたアクセス制御でした。従来のtargetedポリシーでは有効になっていないため、今回mlsを初めて触った方も多いと思います。

mlsが実用的に使われているのは、AndroidのSELinux sandboxやNSAの内部ですが、自分で個人利用する場合も十分に便利な技術です。ぜひ今後のサーバーサイドセキュリティに活かしてくれると作問者として嬉しいです。