blog

システム操作|sudoの新機能

最近のバージョンの sudo には、以前は隠されていた問題を観察したり制御したりできる新機能が追加されています。...

Oct 24, 2025 · 8 min. read
シェア

sudoの最近のバージョンには、以前は隠されていた問題を観察し、制御できるようにする新しい機能が追加されています。

sudo を使うのは、あるユーザに管理者権限を与えつつ、そのユーザがシステム上で行っていることを制御したりチェックしたりしたい場合です。しかし、sudo' にも制御できない部分がかなりあります。最近のバージョンの sudo には、このような問題を確認したり、制御したりするための機能が追加されています。例えば、より詳細で扱いやすいロギング情報を有効にしたり、シェルセッションで実行されたすべてのコマンドを記録したりできます。

これらの機能のいくつかは真新しいものです。1.9.0やそれ以前に登場した機能もあります。例えば、sudoはバージョン1.8でもターミナル上で起こるすべてのことをログに記録できます。バージョン1.9.0ではセッションログの一元的な収集が追加され、ログがローカルユーザーによって削除されないようになりました。

sudoの基本的なことしか知らない人、バージョン1.8しか使ったことがない人は、前回の 記事読むことをお勧めします。

ログはJSON形式です。

最初に紹介する新機能は、JSON形式でのロギングです。私はロギングマニアで、この機能はここに投稿してから初めて導入したものです。有効にすると、sudo はより多くの情報をログに記録し、解析しやすい方法で記録します。

従来のsyslogメッセージは短く、必要最小限の情報しか含んでいません。これは、古いsyslog実装の制限によるものです。1k以上のメッセージは破棄されるか、切り捨てられました。

  1. Jan :27 localhost.localdomain sudo: czanik : TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash

syslog-ngはデフォルトで64kサイズのログメッセージを受け入れます。

同じイベントがJSON形式でログに記録される場合、より多くの情報が含まれます。JSON形式の情報は、多くのログ管理ソフトウェアアプリケーションで解析しやすくなります。以下に例を示します:

  1. Jan :20 localhost.localdomain sudo: @cee:{"sudo":{"accept":{"uuid":"616bc9efcf-bd-60ee-deb5af8ce6","server_time":{"seconds":,"nanoseconds":,"iso8601":"5820Z","localtime":"Jan :20"},"submit_time":{"seconds":,"nanoseconds":,"iso8601":"5820Z","localtime":"Jan :20"},"submituser":"czanik","command":"/bin/bash","runuser":"root","runcwd":"/home/czanik","ttyname":"/dev/pts/0","submithost":"localhost.localdomain","submitcwd":"/home/czanik","runuid":0,"columns":118,"lines":60,"runargv":["/bin/bash"],"runenv":["LANG=en_US.UTF-8","HOSTNAME=localhost.localdomain","SHELL=/bin/bash","TERM=xterm-256color","PATH=/home/czanik/.local/bin:/home/czanik/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin","MAIL=/var/mail/root","LOGNAME=root","USER=root","HOME=/root","SUDO_COMMAND=/bin/bash","SUDO_USER=czanik","SUDO_UID=1000","SUDO_GID=1000"]}}}

ファイルでJSON形式のログメッセージを有効にできます:

  1. Defaults log_format=json

ログはsudo_logsrvdを使って一元的に収集されます。

1.9.4 のログ関連のもう一つの特徴は、sudo_logsrvd を使ってすべての sudo ログメッセージを収集することです。以前は、sudo_logsrvd が実際にロギングを行ったときのみ、システムは成功したセッションのログを記録していました。最後に、ロギングはデフォルトでは syslog 経由で行われます。

なぜこれが重要なのでしょうか?第一に、Sudoに関連するあらゆるものを一箇所に集めることができます。セッションログであれ、対応するすべてのログメッセージであれ。第二に、sudo_logsrvd にアクセスできないと sudo がコマンドの実行を拒否する可能性があるため、 sudo に関連するすべてのイベントが正しくログに記録されるようにします。

sudoersファイルでは、以下の設定で sudo_logsrvd ロギングを有効にすることができます:

  1. Defaults log_servers=7.051

JSON形式のログメッセージが必要な場合は、 sudo_logsrvd コンフィギュレーションの[eventlog]セクションで以下を設定する必要があります:

  1. log_format = json

そうでなければ、sudo_logsrvd 伝統的なsudoログの書式に簡単な修正を加えたものを使います。また、ログの発信元ホストに関する情報も含まれます:

  1. Nov :16 centos8splunk.localdomain sudo:   czanik : 3 incorrect password attempts ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
  2. Nov :23 centos8splunk.localdomain sudo:   czanik : HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; TSID=00000A ; COMMAND=/bin/bash
  3. Nov :30 centos8splunk.localdomain sudo:   czanik : command rejected by I/O plugin ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash

リレー

sudo_logsrvd が最初に集中型セッションログ収集のために導入されたとき、 クライアントはログを直接送信することしかできませんでした。バージョン 1.9.7 ではリレーの概念が導入されました。リレーを使うと、ログを直接送る代わりに、 ネットワークを構成する複数のレベルの中間ホストにログを送ることができます。

なぜこれが重要なのでしょうか?まず、中継することで、集中ホストがネットワークの問題やメンテナンスで利用できない場合でもセッションログを収集できるようになります。デフォルトでは、sudo はログを送信できないときは実行を拒否するので、中継することで 24 時間 365 日 sudo を使うことができます。

第二に、ネットワークをより厳密に制御できるようになります。すべてのホストに対して中央の sudo_logsrvd へのファイアウォールを開く代わりに、リレーだけを許可すればよいのです。

最後に、ゲートウェイホストにリレーモードで sudo_logsrvd をインストールすることで、AWS プライベートネットワークのような、インターネットに直接アクセスできないネットワークからセッションログを収集することができます。

リレーを使用する場合、sudo クライアントとセンター sudo_logsrvd の設定は変わりません。リレーホスト上で、 sudo_logsrvd.conf. sudo_logsrvd の [relay] セクションに以下の行を追加します:

  1. relay_host = 7.161

セントラルサーバーへのネットワーク接続に問題があることが分かっている場合は、転送ログにそれを保存するようにリレーを設定できます:

  1. store_first = true

記録サブコマンド

sudoで起動したシェルセッションで何が起こっているのか、不思議に思ったことはありませんか?確かにセッションログは存在しますが、いくつかのコマンドがどのように実行されたかを確認するためだけに何時間もログを見るのは退屈で、時間の大きな無駄です。幸いなことに、バージョン1.9.8ではサブコマンドのロギングが導入されました。これで、定期的にログメッセージをチェックし、不審なことが起こったときだけログを見ることができます。

シェルにアクセスするためのエディタにアクセスするだけで、シェルへのアクセスを許可するルールすら必要ありません。ほとんどのエディタは外部コマンドを実行できます。私のお気に入りのエディターはJOEで、sudo経由で起動するとこのように表示されます:

  1. Aug :00 czplaptop sudo:   czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joe

驚くなかれ、1つのエディタでシェルを生成し、そのシェルからいくつかのファイルとパーティションを削除しただけです。サブコマンドのロギングを有効にするとどうなるか見てみましょう:

  1. Aug :14 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joe
  2. Aug :37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/sh -c /bin/bash
  3. Aug :37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
  4. Aug :37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/readlink /proc/10889/exe
  5. Aug :37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/sed -r s@/*:|([^\\\\]):@\1 @g;H;x;s@/ @ @
  6. Aug :37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/tty
  7. Aug :42 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/id
  8. Aug :56 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/ls -A -N --color=none -T 0 /usr/share/syslog-ng/include/scl/

スペースを節約するために数十行省略しましたが、それでもシェルを起動したことはわかりますし、bash_profile コマンドはログで見ることができます。

サブコマンドのロギングは、 sudoers ファイルの以下の設定で有効にできます:

  1. `Defaults log_subcmds`

従来のsudoログでは、sudoプロセスIDから同じsudoセッションのログであることがわかります。先に示したように JSON 形式でログを開くと、sudo はより多くの情報をログに記録し、分析しやすくなります。

インターセプト・サブコマンド

loggingサブコマンドは、sudoの落とし穴のほとんどを取り除きますが、何が起こっているかを監視したいだけでなく、イベントの流れを制御したい状況もあります。例えば、ユーザーにシェル権限を与える必要があるけれども、 特定のコマンドを実行させないようにしたい場合などです。この場合、intercept が理想的です。もちろん、シェルの組み込みコマンドを制限することができないなど、いくつかの制限があります。

  1. Defaults intercept
  2. czanik ALL = (ALL) ALL, !/usr/bin/who

sudoでrootシェル・セッションを立ち上げ、whoを実行しようとすると、次のようになります:

  1. $ sudo -s
  2. Sorry, user czanik is not allowed to execute '/usr/bin/who' as root on czplaptop.
  3. bash: /usr/bin/who: Permission denied

実行中のシェルを完全に無効にすることも簡単にできます:

  1. Defaults intercept
  2. Cmnd_Alias SHELLS=/usr/bin/bash, /usr/bin/sh, /usr/bin/csh
  3. czanik ALL = (ALL) ALL, !SHELLS

つまり、sudo経由でシェルセッションを開始することはできません。それだけでなく、エディターから外部コマンドを実行することもできません。これはviからlsコマンドを起動しようとしたときに起こります:

  1. $ sudo vi /etc/issue
  2. Sorry, user czanik is not allowed to execute '/bin/bash -c /bin/ls' as root on czplaptop.
  3. Cannot execute shell /bin/bash
  4. Press ENTER or type command to continue

次は?

この記事は新しい可能性の概要を説明するものです。これらの機能についてもっと知りたい方は、マニュアルページや ご覧ください。

Read next

システム運用|fail2banとFirewallDのブラックリストでシステムを守る

公開SSHアクセスでサーバを運用している場合、おそらく悪意のあるログインの試みに遭遇したことがあるでしょう。この記事では、侵入者のシステム侵入を防ぐために2つのユーティリティを使う方法を説明します。

Oct 23, 2025 · 10 min read