[小ネタ]新機能Session Managerで使うssm-userの権限が気になった話

#AWS

#AWS Systems Manager（SSM）

Shirota

2018.10.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

やったか……!?(秋雨の中震えながら衣替えの決意をしている顔)

▲「窓から雨が入っているイラスト（事故）」らしいのですが、(故意)とかあるんですかね

流石にまた暑さがぶり返したら体も心も軽く折れそうです。上のイラストのような事故が起きても折れますけど。畳の部屋で起こると絶望感が半端ないです。(この話はフィクションです) 秋の始まりからこんにちは、AWS事業本部のしろたです。最近は~~銃の女の子たちと戯れるのが~~忙しくて中々ブログが書けていませんでした。(この話もフィクションです?) 色々落ち着いたらブログに精を出したいなーと思いつつ、初学者の自分が気になった事をどんどこ発信していくスタイルはブレさせずにこれからも参りたいと思いますので温かい目で見守って頂けると幸いです。

AWS Session Managerが楽しくて、秋。

先週あたりの話になりますが、AWS Systems ManagerにSession Managerがリリースされました。「SSH要らず！即ち秘密鍵要らず！ブラウザ上でCLI！もっと早くに出会いたかった！」と、前職時代Linux触りたさに「Linux ブラウザ上」で検索を掛けまくって見つけた Javascriptで作られた変態Linuxエミュレータを弄っていた私にとって、とても心がウキウキして堪らないニュースでした。そして早速、Session Managerを触ってみました。以下の最速記事を参考にしながら。

SSH不要時代がくるか!?AWS Systems Manager セッションマネージャーがリリースされました!

そして上記の記事の中で、以下のような事が記されてました。

コマンドを打って状態を調べてみました｡

ユーザーは ssm-user

cd でカレントディレクトリを変更しても維持される

sudoで昇格が可能(パスワード無し)

日本語入力が可能(echo "ああああ"が動作した)

普段、Amazon Linuxで使用しているec2-userに近いのかなと思い、ちょっと深掘りしてみる事にしました。「ec2-userがユーザID1000だし、多分SSMエージェント導入時にssm-userは作られてユーザIDは1001だろうなー」とか考えつつ、/etc/passwdファイルを覗いてみます。

ec2-user:x:1000:1000:EC2 Default User:/home/ec2-user:/bin/bash
ssm-user:x:1001:1001::/home/ssm-user:/bin/bash
/etc/passwd (END)

予想通りでした。 sudo昇格・パスワード無しとの事で、ここもec2-userと同じです。 ec2-userのsudo許可はどこから出ているのかという事についてですが、Amazon Linux2では /etc/sudoers.d/配下にある90-cloud-init-usersファイルに記述があります。 (Amazon Linuxでは、同一の場所にあるcloud-initファイルに記述があります)

# Created by cloud-init v. 18.2-72.amzn2.0.6 on Thu, 13 Sep 2018 10:04:59 +0000

# User rules for ec2-user
ec2-user ALL=(ALL) NOPASSWD:ALL

ファイルの内容を読むと、「ユーザ「ec2-user」は全てのユーザ・グループとして全てのコマンドを実行できる(ALL=(ALL))、パスワードの確認なしで(NOPASSWD:ALL)」と言った記述がされていました。ただ、ここにssm-userのsudo権限に関する記述は見当たりません。ここで、「グループ側に権限があるのかも？」と思ったのでec2-user・ssm-userが所属しているグループを確認してみる事にしました。

sh-4.2$
sh-4.2$ groups
ssm-user
sh-4.2$ groups ec2-user
ec2-user : ec2-user adm wheel systemd-journal

あれ、これでも無さそうです。

余談:Amazon Linuxでのwheelグループについて

wheelグループの立ち位置は、Wikipediaのページには以下の様に記述されています。

Wheel group Modern Unix systems generally use user groups as a security protocol to control access privileges. The wheel group is a special user group used on some Unix systems to control access to the su[4][5] or sudo command, which allows a user to masquerade as another user (usually the super user).[1][2][6]

と言う訳で、ec2-userがsudo権限を持っているのは、wheelグループに属している事に依るものだと思っていました。(修正前のブログをご覧になった皆様、申し訳ございません) ただ、上でも調べている通り、ec2-userというユーザ自体にもsudo権限が割り振られている事が分かっています。そもそも、これってどちらの設定が適用されているのでしょうか。

気になったので/etc/sudoersファイルを見てみました。/etc/sudoersファイルはrootユーザ・rootグループにしか参照権限が無いのでまだ実態が掴めていないけどsudoして参照します。

## Next comes the main part: which users can run what software on
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
##      user    MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL

## Allows members of the 'sys' group to run networking, software,
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

参照したところ、wheelグループの設定が記述されていました。記述内容は「グループ「wheel」は全てのユーザ・グループとして全てのコマンドを実行できる(ALL=(ALL))、ただし使用ユーザのパスワードの確認あり」と言ったところでしょうか。wheelグループに所属していれば、ユーザのパスワードを確認した上でsudo昇格が可能だと言うことが分かります。つまり、この挙動の違いから分かる事は「wheelグループにされている設定でなくユーザec2-userに対する設定が適用されている」という事です。複数の設定がある時の適用基準については、sudoersのマニュアルにこのような記載がありました。

一人のユーザに複数のエントリがマッチするときは、順番に適用される。複数の指定がマッチしている箇所については、最後にマッチしたものが使用される (それが一番明示的なマッチだとはかぎらないが)。

この規則を踏まえて、もう一度sudoersファイルを見てみます。sudoして。

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL

## Allows members of the users group to mount and unmount the
## cdrom as root# %users  ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom

## Allows members of the users group to shutdown this system
# %users  localhost=/sbin/shutdown -h now

## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d

ec2-userのエントリマッチ順としては

%wheel ALL=(ALL) ALL
/etc/sudoers.d配下にあるファイル

となります。#includedir命令(この#はコメントアウトでは無い事は上記にも記載があります)があると、sudoは一旦カレントファイルの処理を停止して、処理の対象をこの行に記載されているファイルへと切り替えます。今回は最終行に記載されていましたが、実際にはそのような挙動を取ります。実際に、#includedir行の位置をwheelグループ行の前に置くと、ec2-userにとって最後にマッチするのはwheelグループ行の設定になり、ec2-userでsudoを使う際に、ec2-userのパスワードを聞かれる事になってしまいます。~~よい子は真似しないでね。~~ こういう時に強くてニューゲームが容易く出来るクラウドは便利です。さて、sudoルールの適用の法則の話が済んだところで本題に戻りましょう。

ssm-userのsudo権限はどこから？

何か既視感のある見出しだけど気にせずに使います。さて、ssm-userがどうしてsudo昇格出来るのか。 ssm-userはそもそも、SSMエージェント導入時に作られているであろうユーザです。基本的に、後付けでsudo関係のカスタマイズをする際は、どこの何をカスタマイズしたのかを明確にする為に/etc/sudoers.d/配下にファイルを置いて変更を加える方が安全です。sudoersファイルを編集した時は、一応確認はされるものの間違えた設定をごり押して保存してしまったら最後、そのユーザではsudoが使えなくなってしまう訳ですし。基本的にはあまり編集したく無いファイルです。それでも編集する際には、保存前にsudoersファイルの文法を確認してくれるvisudoコマンドでの編集が鉄板です。と言う訳で、/etc/sudoers.d/配下にそれらしきファイルが無いかを探してみました。勿論、このディレクトリ自体の権限はrootユーザ・グループにしか無いのでsudoして。

sh-4.2$ sudo ls -la /etc/sudoers.d/
total 20
drwxr-x---  2 root root   56 Sep 20 07:50 .
drwxr-xr-x 80 root root 8192 Sep 20 07:50 ..
-r--r-----  1 root root  139 Sep 13 10:04 90-cloud-init-users
-rw-r--r--  1 root root   58 Sep 20 07:50 ssm-agent-users

お！露骨にありましたね、それっぽいファイルが！早速中身を確認してみましょう。ファイル自体は閲覧権限があるのですが、上の階層のディレクトリがrootユーザ・グループにしか閲覧権限が無いのでsudoします。

# User rules for ssm-user
ssm-user ALL=(ALL) NOPASSWD:ALL

ありました。「ssm-userユーザ(%がついていないので、このssm-userはユーザです)は全てのユーザ・グループとして全てのコマンドを実行できる(ALL=(ALL))、パスワードの確認なしで(NOPASSWD:ALL)」と言った記述内容ですね。つまりssm-userのsudo権限は、SSMエージェント導入時に作られた/etc/sudoers.d/ssm-agent-usersファイルから来ているようです。にしても、調査でメチャクチャ使ったのでついてて良かったsudo。