Top
このブログは情報分野の森の中を彷徨い歩く勉強記録です．プログラミング演習だけでなく，ネットワークやセキュリティ，クラウドコンピューティングにニューラルネットワークを用いた人工知能まで，あらゆるテーマで勉強してみたその記録を，つらつらと書き連ねていきます．
下のリンク先から，各リンク集に飛ぶことができます．好きなように「エンリュの迷い森」の中を散策してみてください．
ごあいさつ
このブログの趣旨について説明しています．はじめましての方は是非一度お立ち寄りください．
Index
取り組んだテーマについて，系統立ててまとめたページです．お探しのテーマについての情報が見つかるかもしれません．
Journey
迷いの森を歩いた道筋の記録です．当ブログにおける環境の構築の手順など，順序立ててまとめています．
独りごと
演習準備のこと，ブログの設定のこと，勉強していて思ったことなど，思いつくままにほろほろと紡いでいこうと思います．独り言なので人に読まれる意識は薄めです．ご了承ください． 思ったことを綴っていく分，これが一番ブログっぽいかも．
【第15回】情報セキュリティの雪山(3) ~root権限の保護~
皆さま，こんにちは． 迷子のエンリュです．
今回はroot権限の保護ということでやっていきたいと思います．sshをはじめとしたあらゆるサービスに対して管理者への昇格権限や操作の実行権限などを管理し，root権限が不正に使われないようにしていきます．よろしくお願いいたします．
前回のはじめにお話しした内部不正の話で，一般ユーザーのアクセス権限が適切に管理される必要があると言いました．システムの管理者権限はその最たるものです．root権限が奪われてしまえば，あらゆる設定を変えることができ，あらゆるデータにアクセスすることができ，あらゆるプログラムをインストールして走らせることができます．
したがって，root権限の保護はシステムの保護に直結します．ユーザーを信用することも大切ですが，その信用を守るためにもしっかり力を入れていきたいところです．
それでは早速始めていきましょう．
目次
- 目次
- root権限の保護
- rootシェルの無効化
- securettyの設定
- OpenSSHのrootログインの無効化
- PAMによるアクセス制限
- その他の防御手段
- 次回
- 参考ページ
- 情報セキュリティはいくら気にしても慎重が過ぎることはありません
root権限の保護
root権限にアクセスできるプログラム・サービス
root権限にアクセスできるプログラム・サービスを一覧にすると，次のようになります．
- login
- gdm, kdm, xdmなどのディスプレイマネージャ
- ttyを開くその他のネットワークサービス
- su
- ssh, scp, sftpなどのOpenSSHを使用するプログラム
- sudo
- FTPクライアント
- Emailクライアント
root権限はシステムを管理するために必要なものですから，ユーザーがシステムを操作するサービスからは大抵利用することができます．loginやgdmなどのディスプレイマネージャ，その他ttyを開くネットワークサービスは最も基本的なシステム操作用のサービスとなります．ttyとは仮想コンソールデバイスといい，最初にログインする端末を表します．これらはrootシェルを使って直接rootアカウントにアクセスすることができます．
suやOpenSSHもログインを行い，rootシェルを起動することができます．これらはsetuidを用いて管理者権限を利用します．これは実行時にファイルの所有者の権限でタスクを実行するというもので，便利な反面，セキュリティ面での注意が必要となります．suに関してはlogin.defsやPAMを用いてアクセス制御を行いました．同様に，OpenSSHを用いるsshなどもroot権限でのアクセス可否を設定することができます．
sudoもsetuidプログラムです．これはシェルを必要としないでroot権限によるタスク実行を可能にします．rootアカウントに直接アクセスすることはできませんが，PAMなどを用いてアクセスを制限する必要があります．
FTPクライアント，Emailクライアントもroot権限へのアクセスが可能です．これらはPAMを利用しているため，適切な設定を行ってアクセスを制限することができます．
root権限へのアクセスを拒否する方法
root権限へのアクセスを拒否する方法は，対象とするサービスによって異なります．ここでは，次のような方法でroot権限へのアクセスを拒否していきます．それぞれの方法が上で挙げたサービスに対して有効かどうかと合わせてみていきましょう．有効であればo, 無効または影響がない場合は-で表示しています．
| アクセス拒否方法 | 概要 | login | DM | su | sudo | SSH | FTP | |
|---|---|---|---|---|---|---|---|---|
| rootシェルの無効化 | rootのログインシェルを無効化します | o | o | o | - | o | - | - |
| securettyの設定 | securettyファイルを編集してrootアカウントがログインできるttyを制限します | o | o | - | - | - | o | o |
| SSHのrootログインの無効化 | OpenSSHの設定を変更しSSH経由のrootログインを無効化します | - | - | - | - | o | - | - |
| PAMによるアクセス制限 | PAMを使用してサービスへのrootアクセスを制限します | o | o | o | o | o | o | o |
これらの対策を行って，何重にもセキュリティウォールを築いておくことが大切です．それでは早速作業を始めていきましょう．なお，この作業を始めてしまうとrootアカウントに簡単にはアクセス出来なくなってしまいますので，sudoなどで管理者用のユーザーアカウントからroot権限が使えることを確かめてから行ってください．仮想マシンのバックアップを取っておくのもいいでしょう．
rootシェルの無効化
rootアカウントのログインシェルは，デフォルトではbashになっています．これをnologinシェルに変更してアクセスを阻止し，アクセス試行をログに記録するようにします．FTPクライアントやEmailクライアントには影響がないことに注意しましょう．
ログインシェルについては前回の記事(第14回#ログインシェルの管理)も参考にしてください．
$ usermod -s /sbin/nologin root $ getent passwd root $ su -
securettyの設定
securettyファイルはrootログインが可能なttyデバイスを指定します．
$ sudo cat /etc/securetty
バックアップを取ってから，このファイルを空にしましょう．なお，このファイル自体を削除してしまうと，どのデバイスからでもrootログインが可能になってしまうため注意しましょう．
$ sudo cp /etc/securetty /etc/securetty.bak $ sudo vi /etc/securetty > dG # ファイルの末尾まで全消去 > :wq
次にディスプレイマネージャのログイン処理時のPAM認証にsecurettyのチェックを加えます．以下のPAMの設定ファイルの先頭に
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
を追加します．追加するPAM設定ファイルは，
- /etc/pam.d/gdm
- /etc/pam.d/gdm-autologin
- /etc/pam.d/gdm-fingerprint
- /etc/pam.d/gdm-password
- /etc/pam.d/gdm-smartcard
- /etc/pam.d/kdm
- /etc/pam.d/kdm-np
- /etc/pam.d/xdm
のうち存在するものです．また，/etc/pam.d/loginには元から記述されています．
viでloginごとまとめて開き，該当行をコピーしていくと楽でしょう．yyで行のコピー，Shift+pで上の行に貼り付け， pで下の行に貼り付け，:wnで保存して次のファイルに移動です．
OpenSSHのrootログインの無効化
SSHプロトコルとは，暗号化された通信を利用して外部から接続する方式で，SSHサーバを立てることでどこからでもアクセスができる便利なサービスを提供します．しかし，便利なものはそれだけ危険がつきまとうもの．セキュアな設定を常に意識する必要があります．
SSHの設定ファイルは/etc/ssh/sshd_configです．今回はこの中のPermitRootLoginのパラメータを設定します．
PermitRootLoginの値はyes, without-password, forced-commands-only, noがあります．デフォルトではyesになっています．通常はrootログインを拒否し，コマンドオプションを設定したときのみ許可するのがforced-commands-onlyです．完全にrootログインを拒否するのがnoです．設定はこのどちらかにしましょう．ここではnoにします．
$ sudo vi /etc/ssh/ssh_config
PAMによるアクセス制限
PAMはこれまでも何度となく扱ってきました．suをwheelに限定する際はpam_wheelモジュールを使い，物理コンソールでログインしたユーザーにroot権限が必要なコマンドの実行許可を与える際はpam_consoleモジュールを使いました．
今回使用するのはpam_listfileモジュールです．これは，ファイルにリストされたユーザーやホスト名にサービスの実行許可を与えたり，逆に禁止したりすることができます．man pam_listfileで使い方を調べることができます．簡単な使い方は以下の通りです．
# リストに書かれていれば許可 auth required pam_listfile.so onerr=fail item=user sense=allow file=FILENAME # リストに書かれていたら拒絶 auth required pam_listfile.so onerr=succeed item=user sense=deny file=FILENAME
今はまだ追加すべきファイルがないので割愛しますが，上の3つの方法で制限しきれないときはこちらの方法を使っていきます．使うことがあれば逐次追記していきたいと思います．
その他の防御手段
suコマンドの権限を制限
suコマンドはログイン処理によるroot昇格が可能なコマンドです．suコマンドによる昇格を制限する必要があります．こちらを参考に設定を行ってください．
- 【第12回】目指せLinuxマスター(4) ~suの権限~
- wheelグループ以外のユーザーのsuをすべて禁止する設定にしていましたが，rootへの昇格のみを制限するように変更しました．ご確認ください．
sudoersを設定してsudoの権限を制限
sudoコマンドはrootアカウントにログインすることなく，root権限でコマンドを実行できるようにします．sudoの権限はsudoersファイルで設定します．こちらを参考に設定を行ってください．
今回扱うroot権限保護の手段は以上となりますが，root権限へのアクセス手段はまだまだあります．特に，物理マシンを直接操作できる環境においては，root保護のセキュリティシステムを解除する手段が色々と残っています．
しかし，あまり雁字搦めにしすぎると，トラブルが発生して通常の方法でログインできなくなった場合などに，正規のシステム管理者がアクセスできなくなるという懸念があります．私の作業する環境では，これ以上の厳密さは不要と考えますので，以下の内容は参考程度に記すまでに留めておこうと思います．
情報セキュリティは，何から何を守るのか，どの程度コストをかけて守るのかを常に考える必要があります．
シングルユーザモードの禁止
Linuxには，シングルユーザモードという起動方法があります．私たちが普段使っているのはグラフィカルモード，GUIなしの場合はマルチユーザモードで，どちらもアカウントを選択してログインしますが，シングルユーザモードは，rootアカウントでのみログインできます．
起動モードはシステムの起動時に変更することができ，例えばrootのパスワードを忘れてしまったときなどに利用して，新たにパスワードを設定することができます．
また，ランレベルを1にして起動しても同様にシングルユーザモードで起動します．
これらを制限するには，ブートローダのパスワード保護が必要になります．また，ブートローダのインタラクティブモードを回避する必要もあります．
ブートローダの設定などは，Red Hat Enterprise Linuxのマニュアルなどを参考にするとよいでしょう．
次回
今回のroot権限保護によって，システムのセキュリティレベルはかなり向上したといっていいでしょう．次回はいよいよネットワーク接続に向けて，おもにセキュリティ面で準備できることをまとめていきます．よろしくお願いいたします．
参考ページ
情報セキュリティはいくら気にしても慎重が過ぎることはありません
今回の内容はこちらの記事でも扱っています．
| Previous | Top | Next |
|---|---|---|
| 【第14回】 | Journey | 【第16回】 |
| 情報セキュリティの雪山(2) ~セキュアなアカウント管理~ | Index | 情報セキュリティの雪山(4) ~ネットワーク接続の準備~ |
【第14回】情報セキュリティの雪山(2) ~セキュアなアカウント管理~
皆さま，こんにちは． 迷子のエンリュです．
今回は，セキュリティを重視したアカウント管理を行っていきます．不要になったアカウントの削除，有効期限の設定，ログインシェルの管理などを主に扱います．よろしくお願いいたします．
前回は，Linuxのセキュリティ強化の基本としてパスワードに関するセキュリティ強化を主に行いました．正しいアカウントの管理もまた，セキュリティを向上させる基本です．しっかり勉強していきましょう．
目次
不適切なアカウント管理がもたらす脅威
近年では情報漏洩事件の話がちらほらと世間を騒がせています．情報化社会の到来とともに，私たちの身の回りのありとあらゆる情報が電子化され，ネットワーク上やクラウドで管理されるようになりました．また，ビッグデータ解析などの手法の確立によって情報がマーケティング業界などでも盛んに利用されるようになってきました．そんな時代ですから，情報漏洩がもたらす被害は，計り知れないほどになっています．
情報漏洩事件のうちの多くは，実は内部からの不正アクセスによって引き起こされています．情報漏洩のほかにも，情報の改竄や破壊など，組織内部者の不正行為は数多く発生しています．その原因として，システムの管理体制が杜撰で，内部からの不正行為が容易である(IPA - 組織内部者の不正行為によるインシデント調査)ということが挙げられます．日本型組織は，協調を重んじ，他人を信頼しやすい日本人の気質の影響で，データへのアクセス権限の管理が曖昧であるとも言われています．そのため，欧米に比べて日本での組織内不正行為が多いのです．
内部不正を未然に防ぐためには，「適切なアカウント管理」，「適切なアクセス権限」「操作ログの記録の徹底」などが必要です．「適切なアカウント管理」はシステムへのアクセスを制御することに通じます．実際に，退職者のアカウントが削除されずに残っており，それが犯罪に利用されてしまうといったケースもあります．
システムを運用する前に，アカウントの管理方法についてしっかり定めておきましょう．
不要になったユーザーアカウント
削除する
まずは不要になったユーザーアカウントを削除します．ユーザーの削除はuserdelコマンドによって行います．
$ sudo userdel -r USERNAME # 削除するユーザが使用中の場合，fオプションで強制削除できます $ sudo userdel -rf USERNAME
ロックする
もしまたアカウントを使用する可能性がある場合でも，ログインできないようロックしておくことは必要です．アカウントのロックはpasswdコマンドで行うことができます．
$ sudo passwd -l USERNAME
ロックを解除するときはuコマンドを使います．
$ sudo passwd -u USERNAME
管理者グループwheelから退会させる
管理者交代など，アカウントは残したままだがアクセス権限を変えたいときは，グループから退会させることで制御できるようにするといいでしょう．ここではwheelグループが管理者権限を有するグループとして設定してありますので，前の管理者をグループから退会させることで管理者権限を返還させます．
$ sudo gpasswd -d USERNAME wheel
アカウントの有効期限
あらかじめアカウントの有効期限を決めておくことも重要です．アカウントにはEXPIRE_DATEを設定でき，この日付を超えるとログインできなくなります．
既存のアカウント
# 既存のアカウントの有効期限はchage-Eまたはusermod-eで設定します. # 日付はYYYY-MM-DDの形式か1970-1-1を0日目として数えた日数で指定します． $ sudo chage -E YYYY-MM-DD USERNAME または $ sudo usermod -e YYYY-MM-DD USERNAME # 確認はchage-lでできます． $ sudo chage -l USERNAME
新規のアカウント
アカウントを新規に作る際にオプションで有効期限を設定することができます．
$ sudo useradd USERNAME -e YYYY-MM-DD
また，ユーザー作成時にオプションで指定されなかった値については，/etc/default/useraddに書かれたデフォルト値を使用します．デフォルト値は，直接ファイルを編集するかコマンドを介して変更することができます．
# -Dオプションのあとにオプションを続けることでデフォルト設定を変更します． $ sudo useradd -D -e YYYY-MM-DD # 確認は-Dオプション単独でできます． $ sudo useradd -D GROUP=100 HOME=/home INACTIVE=-1 EXPIRE=yyyy-mm-dd # 設定した値 SHELL=/bin/bash SKEL=/etc/skel CREATE_MAIL_SPOOL=yes
ログインシェルの管理
無効なシェルの設定
ユーザーがログインしたとき，passwdファイルに書かれたログインシェルを使ってログインします．/bin/bash, /bin/shなどが有効なログインシェルで，シェルが起動することでユーザーはシステムの操作を行うことができます．
アカウントには，ログインを想定していないものもあります．ftpやsshdなどのシステムアカウントがそれです．こうしたアカウントのログインシェルに有効なシェルが設定されてしまうと，それを介して不正ログインが行われる場合もあります．また，ログインを想定しないユーザーアカウントも，ログインシェルに無効なシェルを変更することでログインできなくすることができます．
システムアカウントやログインを想定しないユーザーアカウントのログインシェルには，/bin/falseという無効なシェルを設定する必要があります．
# ログインシェルの確認はpasswdファイルでできます．
$ getent passwd enryu
enryu:x:500:500:Lost Enryu:/home/enryu:/bin/bash
↑一番末尾に記載されている/bin/bashがログインシェルになります
# 有効なシェルは/etc/shellsファイルで確認できます．chshコマンドを使います．
$ chsh -l
/bin/sh
/bin/bash
/sbin/nologin
:
# 無効なシェルに変更します
$ sudo chsh /bin/false USERNAME
または
$ sudo usermod -s /bin/false USERNAME
# 新規ユーザーの場合
$ sudo useradd -s /bin/false USERNAME
falseとnologin
/sbin/nologinというログインできないシェルもあります．これはログインはできませんが，正当なシェルになっているため起動することができます．正当なシェルとは/etc/shellsに定義されたもので，FTPでのログインができてしまいます．nologinは起動すると，ログイン試行のログを残してからメッセージを残してログインを拒否します．
サイトによって言っていることはまちまちですが，システムアカウントには/bin/false，ログインを想定しないユーザーアカウントには/sbin/nologinを使うのがいいのかなと思います．
# /bin/falseへのログイン $ su user Password: $ # パスワードを入力したのち，何も起こらず終了します # /sbin/nologinへのログイン $ su user Password: This account is currently not available. $ # シェルは起動し，内部の処理でログインが拒否されます
システムアカウントのログインシェル
CentOS6.8はデフォルトでシステムアカウントのログインシェルに/sbin/nologinが指定されています．パスワードがロックされているためログインはできませんから，このままでも問題はありませんが，このロックはroot権限で解除できますから，念のために上述の通り/bin/falseに変更します．まとめて変更する場合は直接/etc/passwdを変更する方が効率的でしょう．
$ sudo vi /etc/passwd
:%s;/sbin/nologin;/bin/false/gcで確認しながらまとめて置換します．
パスワードの有効期限
万が一パスワードが漏洩してもアカウントが不正利用されるリスクを減らすために，パスワードの有効期限を設定して，定期的にパスワードを変更させるようにしましょう．パスワードに関しては前回扱いましたのでここでは割愛します．
今回扱うセキュアなアカウント管理方法は以上となりますが，実際には組織内でどのようにアカウントを運用していくか，誰がどれだけの権限でいつまで管理していくかなどのポリシーを定めておくことが大切です．刻々と変化する運用状況の中で，常にアカウントの管理について考えていくことを忘れないようにしましょう．
次回
次回は，root権限の保護について扱っていきたいと思います．よろしくお願いいたします．
参考ページ
- ゼロから始めるLinuxセキュリティ(1)：インストール直後に絶対やるべき作業と設定
- 知らないと危険な false と nologin の挙動の違い
- ログインできないユーザの作成とログインできるように変更するコマンドの使用方法
- /bin/false と /sbin/nologin と /etc/shells について
セキュリティ対策は急がず慌てず迅速に
今回の内容はこちらの記事でも扱っています．
| Previous | Top | Next |
|---|---|---|
| 【第13回】 | Journey | 【第15回】 |
| 情報セキュリティの雪山(1) ~パスワードの強化~ | Index | 情報セキュリティの雪山(3) ~root権限の保護~ |
【第13回】情報セキュリティの雪山(1) ~パスワードの強化~
皆さま，こんにちは． 迷子のエンリュです．
前回まではsudoやらsuやらの設定をしながら，LinuxをCUIベースでいろいろと動かす練習をしました．今回からは本格的にセキュリティ強化を行っていきます．面倒に思うかもしれませんが，これも早くネットワークに接続するためです．
あなたの開発環境が攻撃者に利用されてしまうことのないよう，しっかりと設定していきましょう．それではよろしくお願いします．
目次
はじめに
Linuxは，無料で手に入るOSであるがゆえに，攻撃者も簡単にセキュリティホールを研究できてしまうという弱点があります．これまで「Linuxはあまり攻撃対象になっていないから大丈夫」ということがたくさん言われてきましたが，クラウドコンピューティングが普及し，Windowsサーバーと同じくらいLinuxサーバーが動いているこの時代，そんなことも言っていられません．また，IoTの増加に伴うDDoS攻撃の脅威も考えないわけにはいきません．これは個人で動かしているIoT機器も利用されてしまいますから，個人運用でひっそりと楽しんでいる人も情報セキュリティの確保の責任が問われるのです．
ただネットワークに接続するだけでもそれなりに危険だということを認識する必要があります．情報技術を趣味として使えるようになった時代だからこそ，ひとりひとりが情報セキュリティを意識すべきなのです．
前回行ったsuコマンドの権限の設定も，情報セキュリティを向上させる大切な作業です．root権限を簡単に使われないようにすることは基本中の基本です．ただし，それだけでは実は十分ではありません．攻撃者は様々な攻撃手段を日々研究しています．私たちも，いくつもの防御・防護手段を講じて，何重にもセキュリティの壁を立てておく必要があるのです．
パスワードの強化
パスワードの強化は，セキュリティを向上させる大切な手段です．個人レベルでは強力なパスワードを用いたり，定期的にパスワードを変更するよう意識するくらいしかありませんが，管理者レベルでは，ユーザのパスワードレベルを保つための様々な対策を施すことができます．
パスワードに関わる脅威
そもそも，パスワードは日ごろどのような危険に晒されているのか，少しまとめてみましょう．
| 脅威 | 概要 | 対策 |
|---|---|---|
| 盗聴 | 通信路に入力したパスワード文字列が流れると，その都度盗聴される可能性がある． | 適切な暗号化 |
| ショルダーハッキング | パスワードを入力する際に覗き見られたり，メモとして書き残したものを見られるなどして，アカウントを利用されてしまう． | 定期的な更新 |
| 他人への譲渡 | やむを得ない事情でID/パスワードを他人に教えてしまう．正当な理由がなければ不正アクセス禁止法違反となってしまう． | 適切なパスワード管理，定期的な更新 |
| パスワードクラッキング | 総当たり攻撃，辞書攻撃，パスワードリスト攻撃などでパスワードを解除されてしまう．辞書に載っている単語を使う，8文字以下のパスワード，よく用いられるパスワードなどの場合はすぐに破られてしまう． | 強力なパスワード |
| 平文のパスワード管理 | 通常パスワードは暗号化されて保存されるが，自作のログインシステムなどの場合は，平文で保存されたり，通信されたりというケースも起こりうる． | 適切な暗号化 |
| 内部からのパスワード漏洩 | パスワードがユーザから見られるファイルに記録されていると，暗号化されていても総当たり攻撃などでパスワードを破られる可能性がある． | シャドウパスワード |
| サイドチャネル攻撃 | システムが発するノイズやCPUの稼働状況など，通常の通信盗聴手段と異なる方法で盗聴される危険性もある．パスワードの流出なども考えられる． | 適切な暗号化，定期的な更新，その他不正アクセス対策 |
以上，すぐに思いつくものだけでもこれだけありますが，対策の項を見ていただければわかる通り，普段からパスワードのセキュリティについて気を付けていれば，ある程度防げるものでもあります．
ここでは，パスワードのセキュリティを強化させるのに有効な，以下のことを扱っていきます．
- シャドウパスワードの設定 パスワードが一般ユーザに見えないようにします．
- パスワードポリシーの設定 パスワードの強度や更新頻度などを指定します．
暗号化アルゴリズムの設定 強力な暗号化アルゴリズムに変更します．
これでかなりセキュリティは強化されるはずですね．早速やっていきましょう．
シャドウパスワードの設定
シャドウパスワードは，一般ユーザから暗号化されたパスワードを見えなくしたものです．従来，ユーザーのアカウント情報はpasswdファイルにすべて記載されていました．このファイルは一般ユーザ権限で見られるものです．ユーザー名と暗号化されたパスワードを，誰でも調べることができました．しかし，暗号化されているとはいえ，あり得そうなパスワードを片っ端から同じ手法で暗号化して比較していけば，パスワードを特定することができてしまうため，これはとても危険でした．
そこで，passwdファイルのパスワードの部分を隠し，ユーザー認証などの際に暗号化パスワードを調べるファイルとして，root権限がなければ見られないshadowファイルを新たに用意する方法が生まれました．これがシャドウパスワードです．
確認方法
passwdもshadowもテキストファイルなのでファイル閲覧コマンドで見ることもできますが，これらはgetentコマンドで表示させるのが一般的です．
# /etc/passwdのユーザー名やそれぞれの設定の一覧を表示． $ getent passwd # 特定のユーザーを抜き出して表示． $ getent passwd USERNAME
「:」区切りでユーザー名，パスワード，uid，gid，...と並んでいます．パスワードの欄が「x」という文字に置き換わっていたらシャドウパスワードが有効になっている証拠です．shadowファイルの方も確認してみると，暗号化されたパスワードが記載されています．
# /etc/shadowを表示 $ sudo getent shadow enryu enryu:$1$********:17089:0:99999:7:::
********の部分が暗号化パスワードであり，その前の数字は暗号化アルゴリズムの種類を表しています．また，そのあとにはパスワードに関する設定などが続いています．
設定方法
もしシャドウパスワードになっていなかったり，解除してしまったときには有効化する必要があります．シャドウパスワードを有効にするには，pwconvコマンドを使います．詳しくは$ man pwconvで調べられます．
# シャドウパスワードの有効化 $ sudo pwconv # シャドウパスワードの無効化 $ sudo pwunconv
パスワードポリシーの設定
パスワードポリシーとは
パスワードポリシーとは，パスワードの設定や更新に関する決まりのことで，PAMで設定するものとlogin.defsで設定するものがあります．以下の項目があります．
| 設定方法 | 項目 | 意味・概要 | 例(デフォルト値) |
|---|---|---|---|
| login.defs | PASS_ALWAYS_WARN | パスワードが弱いと警告します． | yes(no) |
| login.defs | PASS_MAX_DAYS | 同じパスワードを使える最大日数です． | 180(99999) |
| login.defs | PASS_MIN_DAYS | パスワードを変更してから，次に変更できるようになるまでの最小日数です． | 1(0) |
| login.defs | PASS_WARN_AGE | パスワードの期限が切れる何日前から警告するかです．マイナスは警告しません． | 7(7) |
| PAM | minlen | パスワードの最小文字数です． | 8(4) |
| PAM | remember | パスワードを過去何世代と異なるものにするかを指定します． | 3() |
| PAM | deny | パスワード入力を何回間違えたらアカウントをロックするかを指定します． | 5() |
| PAM | unlock_time | アカウントをロックする時間(秒)を指定します． | 180() |
| PAM | minclass | パスワードに最低限含めるべき文字の種類(数字，大文字，小文字，記号)の数を指定します． | 3(0) |
| PAM | maxsequence | '12345', 'abcde'などの連続した並びが何文字以上続いたらパスワードを破棄するかを指定します． | 4(0) |
| PAM | dcredit, ucredit, lcredit, ocredit | パスワードに含める文字の種類と文字数などを指定します(※)． | 0(1) |
※dcreditは数字，ucreditは大文字，lcreditは小文字，ocreditは記号などを表します．これらの振る舞いは少々複雑です．例えば(case 1)dcredit=2, minlen=8のとき，数字が1つ含まれていたらパスワードが7文字でも許可します．これを2文字まで許すので，実質パスワードの長さは6文字以上となります．ただし，数字が含まれていなければ8文字以上ということです．(case 2)dcredit=-2, minlen=8のとき，数字が2文字以上含まれていないと許可されません．また，数字が含まれていた場合，minlenには影響しません．(case 3)creditを何も設定せず，minlen=8のとき，creditのデフォルト値は1となります．数字，大文字，小文字，記号などをすべて含めると，minlenは4になりますが，実際は5文字以下のパスワードは弾かれるため，6文字が最小文字数となります．厳密にminlenを設定したいときは，?creditを0以下に設定すべきです．
パスワードポリシーの設定
では実際に設定していきましょう．これからやるのはあくまで一例です．数値などはご自身で決めたものに適宜変えてください．
まずはlogin.defsです．ここでは編集にviを使っていますが，もちろんお好きなテキストエディタで構いません．画像のようにデフォルトでパスワードに関する設定が書かれている場所がありますので，変更していきます．
$ sudo vi /etc/login.defs
PASS_MAX_DAYS 180 PASS_MIN_DAYS 1 PASS_MIN_LEN 8 # PAMの設定が優先されるのであまり意味はありません PASS_WARN_AGE 7
次はPAMのsystem-authです．
$ sudo vi /etc/pam.d/system-auth
ここにどんどん書き足していきます．心配な人はバックアップを取っておいてもいいでしょう．ファイルが大きくて分かりにくいかもしれないので，編集ポイントをまとめます．なお，行数は:set numberで表示できます．
- 8行目の下に auth required pam_tally2.so deny=5 unlock_time=180 を挿入
- 17行目 password requisite pam_cracklib.so にminlen=8 minclass=3 maxsequence=4 dcredit=-1 ucredit=0 lcredit=0 ocredit=0を追加
- 18行目 password required pam_unix.so にremember=3を追加
これで設定は終了です．:wqで保存して終了しましょう．
ユーザごとの設定
上で設定した項目のうちのいくつかは，chageコマンドで確認したり，変更したりできます．
$ chage -l enryu Last password change : Nov 02, 2016 Password expires : May 01, 2017 Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 180 Number of days of warning before password expires : 7
変更するときは次のオプションを使います．
| オプション | 項目 | 意味 |
|---|---|---|
| -m | mindays | パスワードを変更してから次に変更できるようになるまでの最小日数を変更 |
| -M | maxdays | 同じパスワードを使用できる最大日数を変更 |
| -W | warndays | パスワードの期限が切れる警告を何日前から行うかを変更 |
このコマンドを使用して，各ユーザーごとに設定を変更することができます．
# 例：ユーザenryuのパスワード更新最小日数を0にする $ sudo chage -m 0 enryu
他のオプションについては次回お話しします．
暗号化アルゴリズムの設定
暗号化アルゴリズムの種類
パスワードを暗号化するアルゴリズムにはいろいろ種類があります．ひと昔前は標準的な暗号方式の規格であるDESが一般的でした．今使っているCentOS6.8ではMD5によるハッシュ化が用いられています．
しかし，DESは8文字までのパスワードしか扱えず，MD5は脆弱性が発見されてパスワードを破られる可能性が出てきたため，CentOS7からはSHA-2というハッシュ化方式が取られています．
暗号化アルゴリズムの方式は，時代を経るにしたがってまだまだ移り変わっていくでしょう．そのたびに新しい方式へと設定を直していく必要があるのです．
ここでは，SHA-2のひとつ，SHA512という方式に設定しましょう．
再びPAMのsystem-authを変更します．
# cオプションは起動時にコマンドを実行する $ sudo vi /etc/pam.d/system-auth -c "set number"
:
18 password sufficient pam_unix.so MD5 shadow nullok remember=3 try_first_pass use_authtok
↑この行のMD5をSHA512に変更↓
18 password sufficient pam_unix.so SHA512 shadow nullok try_first_pass use_authtok
:
設定の反映
以上でパスワードに関する設定が完了したわけですが，このままでは設定は反映されません．設定の仕方によって，反映されるタイミングは様々です．
login.defsの設定の反映
login.defsで設定した内容は，useraddで新しくアカウントを作るか，pwconvでshadowファイルを作り直すときに反映されます．useraddの場合は，既存のアカウントへは反映されないので，pwconvしなおすのが良いでしょう．
# pwconvしなおす場合 $ sudo pwunconv $ sudo pwconv # 確認 $ chage -l USERNAME
なおchageによる設定はその場で反映されます．
PAMの設定
PAMで設定したパスワードポリシーや，パスワードの暗号化方式は，新たにパスワードを発行するときに有効になります．したがって，既存のパスワードは以前の暗号化形式のままになっています．したがって，各ユーザが次回ログインするときに，パスワードを変更させる必要があります．
# 自分で行う場合 $ passwd # 次回ログイン時にUSERに変更させる場合 $ passwd -e USER
以上でパスワードの強化は完了です．次回はセキュアなアカウント管理について勉強していきます．よろしくお願いします．
参考ページ
- パスワードをシャドウパスワードに変更するには
- Linuxでパスワードポリシーを設定する｜俺的備忘録 〜なんかいろいろ〜
- CentOS/パスワードの長さや文字などの制限事項を設定する方法
- [FreeBSD]パスワードハッシュにmd5を使うのは小学生までだよねー
- Linux,UNIXで次回ログイン時にパスワードを変更させる
セキュリティ対策は急がず慌てず迅速に
今回の内容はこちらの記事でも扱っています．
| Previous | Top | Next |
|---|---|---|
| 【第12回】 | Journey | 【第14回】 |
| 目指せLinuxマスター(4) ~suの権限~ | Index | 情報セキュリティの雪山(2) ~セキュアなアカウント管理~ |
【第12回】目指せLinuxマスター(4) ~suの権限~
皆さん，こんにちは．迷子のエンリュです．
今回で権限の初期設定はラストです．今回はsuコマンドの権限を設定します．どんなに各コマンドの設定をしたところで，誰でもrootに昇格出来たら意味がありませんからね．具体的にはlogin.defsとPAMを変更します．よろしくお願いいたします．
※【2016.11.4 追記】PAMの設定を変更しました．
以前もPAMについては取り扱いました．suコマンドもPAMを利用しているのですね．もう一つのlogin.defsはログイン処理のときに使用される各アカウントの設定ファイルです．suコマンドを使うときも，この設定ファイルを使ってログイン処理を行います．
この設定を変更して，wheelグループのメンバー以外にはrootユーザーへのログインを禁止していきます．
メインユーザーをwheelに入れる
まずは，メインのユーザーがwheelグループに入っているか調べましょう．もし入っていなければusermodコマンドかgpasswdコマンドで加入させます．以前usermodは使いましたので，今回はgpasswdでやってみましょう．
$ groups # 自分の所属グループを表示 $ gpasswd -a USERNAME wheel # 所属していなかったら追加
ログイン処理の設定
※最近のCentOSではlogin.defsにSU_WHEEL_ONLYを設定する必要はなくなったそうです(CentOS6.8にて確認)
今度はlogin.defsをいじっていきます．root権限で開きましょう．
$ sudo vi /etc/login.defs
色々書いてありますね．コメントも分かりやすく書いてありますので，一度目を通しておくとよいでしょう．今回はこの一番末尾に次のように書きます．
# Only wheel group can su root SU_WHEEL_ONLY yes
PAMの設定
次はPAMの設定を行います．今回は/etc/pam.d/suを開きます．
2つコメントアウトされている行がありますね．これの下側のコメントを外します．dwでコメントを外しましょう．
# Uncomment the following line to require a user to be in the "wheel" group. # auth required pam_wheel.so use_uid ↑ ここのコメントを外す．dwで1単語削除．
これで，suコマンドでrootに昇格できるのはwheelメンバーに限定されました．もちろん他のユーザーに切り替えることもできません．
※[2016.11.4 追記]
次に，root_onlyオプションをつけます．
# root_onlyオプションをつけることで，rootへの昇格のみを制限します auth required pam_wheel.so use_uid root_only
あとは再起動すれば設定がすべて反映されます．
$ sudo shutdown -r now
例えば，Bobでログインしてsuコマンドを試してみましょう．
$ su -
パスワード入力の前にauth認証で弾かれていますから，何を入力しても「パスワードが違います」と表示されます．
参考ページ
次回
今回の設定はこれで完了です．少し短いですが，今日はここまでです．
次回はパスワードを強化したいと思います．それでは次回もよろしくお願いいたします．
チュートリアルしながらセキュリティ強化♪
今回の内容はこちらでもまとめています．
Qiita：目指せLinuxマスター(弐) ~suコマンドの権限~
Previous | Top | Next
Prev: 【第11回】目指せLinuxマスター(3) ~polkitの設定~
Next: 【第13回】情報セキュリティの雪山(1) ~パスワードの強化~
Index
Journey
【第11回】目指せLinuxマスター(3) ~polkitの設定~
皆さん，こんにちは．迷子のエンリュです．
今日はpolkitの設定をやっていきます．Polkitは，GNOMEなどのデスクトップ操作の権限を設定するセキュリティツールで，ポリシーという形でユーザーごとに操作の権限を定義することができます．
前回はPAMというセキュリティツールを覗きながら，実行ファイルのアクセス権限を変えることでユーザーのコマンド実行の権限を調節しました．これによって非ユーザーCUIからシャットダウンするのを完全に禁止できましたね．しかしGUIを使えばシャットダウンできてしまいます．それはなぜかというと，GUIの場合はまた違ったモジュールがセキュリティの管理を行っているからなんですね．面倒くさい限りです．
GUIベースで共用マシンを動かすケースを考慮して，その管理方法の基本となるPolkitを使いこなせるようになりましょう．
それではよろしくお願いいたします．
どうしてPolkitなのか
ログを見てみる
さて，そもそもどうやってPolkitなるものにたどり着いたらいいのか．そこから話したいと思います．Linuxは大体の場合，なにか操作を実行したらログが残ります．「プログラムは正常に終了しましたよ」とか「認証をクリアしましたよ」とかですね．
例えば，Aliceという非usersユーザーでログインし，GUIから再起動してみましょう．System > Shut Down... > Restartですね．
今度はwheelユーザーのenryuでログインし，ターミナルを立ち上げます．主なログは/var/logというディレクトリに入っています．ここでは/var/log/secureという，認証に関するログの最後の方を見てみましょう．
$ sudo tail -n 20 /var/log/secure | less
...え？これ読むの？ ちょっと頭痛くなってきますね．でも見るところが分かってこれば，大して苦ではないんですよ．例えば一番下，enryuがsudoを行ったログがあります．最初は日付，次はホスト名です．まずこれを見て関係なさそうなのは排除できます．ホストの次に書かれているのがサービス名です．正直これだけ見てれば大体の流れは追えます．
Shift+gでファイルの末尾に移動したら，kで上に戻りながらaliceという文字を探しましょう．すると，pam: gdm-password: pam_unix(gdm-password:session): session closed for user aliceという行があるでしょう．これがaliceによるシャットダウンの行ですね．gdmというのは"GNOME Display Manager"の略で，GUIのログイン処理などを行っています．
その次の行には，polkitdというサービスが書かれています．gdmはpolkitdを使って認証を行っているのです．下の方には/org/freedesktop/ConsoleKit/Session1や/org/gnome/PolicyKit1/AuthenticationAgentなどの文字も見えますね．
manで調べる
関係者が割り出せたところで，manで調べてみましょう．polkitについて見てみると，
とあります．PolicyKitは認証APIを提供するとありますから，今日の標的はこいつのようですね．もう少し下まで見てみると，
このような文があります．ローカル権限を設定したいいならpklocalauthorityというやつを調べろとのお達しですね．早速見てみましょう．qでmanを閉じたら，すかさずman 8 pklocalauthorityと入力します．
これを読んでいくと，設定ファイルは/etc/polkit-1/localauthority/以下に.pkla拡張子をつけて書いてくれとあります．さらに，設定ファイルの書き方についても記述があります．
いやあ，親切ですね．ResultAnyというのがデフォルトの挙動，ResultInactiveがアクティブでないローカルセッションに対する挙動，ResultActiveがアクティブなローカルセッションに対する挙動...ということですが，よく分かりませんね．アクティブってなんなんでしょう．ここではResultActiveで許可が出せるんだと思っておけば良さそうです．
Actionを調べる
では今度はシステムのシャットダウン・再起動に関わるアクションを調べてみましょう．pkactionコマンドを使います．
$ pkaction | grep restart $ pkaction | grep consolekit $ pkaction -v -a org.freedesktop.consolekit.system.restart
ありましたね．どうやらorg.freedesktop.consolekit.system以下の4つのアクションについて設定してやれば良さそうです．
設定を記述
localauthorityへの追加
やることが分かってきたところで，早速設定ファイルを追加していきましょう．/etc/polkit-1/localauthorityへの侵入権限がないらしいので，途中まで入ったらsudoで設定ファイルを作りましょう．なお，cdはコマンドではないため，sudo cdとすることはできません．
$ cd /etc/polkit-1 $ sudo vi localauthority/50-local.d/myConsoleKitSystem.pkla
例えばこんな感じで書いて保存してみます．
[ConsoleKit] Identity=unix-user:* Action=org.freedesktop.consolekit.system.* ResultAny=no ResultInactive=no ResultActive=no
ではGUIのシャットダウンウィンドウを表示してみましょう．
なんと，Shut DownとRestartが見事に消えてしまいました！ どうやら，この方針で間違いないようです．
では，今度はusersだけに許可を与えてみましょう．
[ConsoleKit] Identity=unix-group:users Action=org.freedesktop.consolekit.system.* ResultAny=no ResultInactive=no ResultActive=auth_self_keep
念のために各自のパスワードを入力させるようにしました．それでは再起動をしてみましょう．
パスワードの入力が求められました．
今度はaliceでログインしてみましょう．今はaliceには何も規制がかかっていませんね．おそらく従来通りに再起動できる状態でしょう．
ポリシーのデフォルトの変更
aliceをはじめとした非usersの規制をするには，先ほどのmyConsoleKitSystem.pklaの最初に，全ユーザー向けの設定を記述すればいい気がしますが，どうもそれだとうまく機能してくれません(似たようなことをしようといている投稿も見られましたが(polkit: disable all users except those in group wheel?)，users以外の全ユーザーを書く方法しかうまくいかなさそうなので，ここではデフォルトの設定を変えてしまいます．これはあまり推奨されない方法です．アップデートの際に書き換えられてしまうので... Polkitの更新の際は注意しましょう．
デフォルト設定は/usr/share/polkit-1/action以下で定義されています．pkactionで見られるような設定が書かれています．
$ cd /usr/share/polkit-1/action $ ls
シャットダウン関係のポリシーはorg.freedesktop.consolekit.policyになります．root権限でlessコマンドで見てみましょう．
$ su # less org.freedesktop.consolekit.policy
上の方はxmlファイルのおまじないです．<policyconfig>以下のタグがActionの設定です．これを見ると，allow_inactive，allow_activeなどのタグがありますね．これがResultActiveなどで設定した値のデフォルト値です．これを変えていくわけですね．
lessは，vを押すことで編集モードに移ることができます．デフォルトはviが起動しますが，設定を変えれば好きなエディタを起動することができます．早速vでviエディタを起動しましょう．
/allow_activeとして検索を行い，そのタグに囲まれた「yes」や「auth_admin_keep」などの値をすべて「no」に書き換えてしまいましょう．このファイル中には全部で4か所あります．
できたら:wqでviを終え，lessに戻り，qでlessも終わりましょう．これで設定完了です．
aliceやbobなど，ユーザーを切り替えてGUIからシャットダウンしようとしてみてください．いかがでしょうか．設定がうまくできていることが確認できるかと思います．
まとめ：CUI，GUIでのユーザーのシャットダウン権限
第9回から3回にかけて，シャットダウンに関する権限の設定を行ってきました．ちょっと何をやったか分かんなくなってきましたね．ここらで少しまとめてみましょう．
CUIのシャットダウン権限
- 基本的にシャットダウンコマンドにはroot権限が必要
- sudoersの設定を変更してsudoコマンドによるシャットダウンを特定ユーザーに許可
- 物理コンソールログインに限り，consolehelperによって一般ユーザーにシャットダウン権限を委譲
- consolehelperの所有グループを変更して物理コンソールログインでシャットダウン権限を委譲されるユーザーを，特定ユーザーに限定
- 他にもPAMを用いて認証や権限の制御が行われている
GUIのシャットダウン権限
- GUIでのシャットダウン権限はPolkitで定義されるポリシーに従っている
- /etc/polkit-1/localauthority以下でローカルのポリシーを設定できる
- /usr/share/polkit-1/Action以下でデフォルトのポリシーを設定できる
こうしてまとめてしまうと，随分簡単なことのように思えますね．これらの操作は，root権限があれば簡単にできてしまうものばかりです．つまり，せっかく一般ユーザーの操作を限定しても，suコマンドでroot権限に昇格してしまえば，システムに関わる変更もできてしまうのです．
次回
次回は，suコマンドによるroot権限への昇格について制限していきます．これで，基本的な権限の設定は完了となります．usersメンバーでないユーザーにはシステムの設定などを一切変更できなくなります．最後の大詰め，張り切ってまいりましょう．
次回もよろしくお願いいたします．
参考ページ
openSUSE 13.1: 第9章 PolKit を利用した権限認可
gnomeメニューからシャットダウンを消去
Polkit - ArchWiki
polkit: disable all users except those in group wheel?
シャットダウンの権限についてこちらでまとめています
Qiita：目指せLinuxマスター(壱) ~CUI/GUIからの強制終了/再起動権限~
Previous | Top | Next
Prev: 【第10回】目指せLinuxマスター(2) ~権限の制御~
Next: 【第12回】目指せLinuxマスター(4) ~suの権限~
Index
Journey
【第10回】目指せLinuxマスター(2) ~権限の制御~
皆さん，こんにちは． 迷子のエンリュです．
記念すべき第10回？いえいえ，私の中ではまだ第0x0a回に過ぎません．
今回は「目指せLinuxマスター第2回」ということで，権限の制御について考えていきたいと思います．具体的には，コマンドについて調べたり，コマンドの実行ファイルの権限を変えたりしていきます．よろしくお願いいたします．
前回はsudoersを設定して，sudoコマンドの挙動を制御しました．しかし，実はまだ一般ユーザ(非usersメンバ)がシャットダウン系のコマンドを使うことができる状態です．GUIでも実行できますが今回はそれはおいておいて，CUIからのhalt，rebootなどの実行を，usersメンバーに限定します．
それでは早速始めていきましょう．
環境
- CentOS 6.8
なぜ一般ユーザがシャットダウンできるのか
先ほどから一般ユーザがシャットダウンできると言っておりますが，より細かくシャットダウンできる条件を調べてみましょう．
which ― コマンドのフルパスの表示
whichコマンドは，Linuxコマンドが呼び出す実行ファイルのフルパスを調べるコマンドです．ほとんどのコマンドはバイナリファイルと呼ばれる機械語で書かれた実行ファイルを呼び出すことで，命令を実行しています．これを用いて，haltコマンドとshutdownコマンドを調べてみましょう．
$ which halt shutdown
shutdownコマンドは，/sbinに入っているからroot権限が必要なのです．ところで，sudoersの設定の時に/sbin/haltというファイルをSHUTDOWNに含めましたね．haltも/sbinに入っています．ではなぜhaltコマンドは/usr/bin/haltを参照するのでしょうか．今度は実行ファイルをls-lで詳しく見てみましょう．
$ ls -l /usr/bin/halt
パーミッションの前の「l」は，リンクを表します．/usr/bin/haltはconsolehelperへのシンボリックリンクになっているのです．シンボリックリンクについてはここでは詳しく触れませんが，haltコマンドは/usr/bin/haltを呼び出し，これがさらに/usr/bin/consolehelperを呼び出しているのです．
man ― マニュアルの表示
consolehelperって何でしょうか．調べてみましょう．今日はとにかく「調べる」方法特集ですね．今度はmanコマンドを使います．これは"manual"という意味で，マニュアルを表示します．Linuxでわかんないことがあったら，大体manで調べれば解決します．
$ man consolehelper
consolehelperはコンソールユーザーがシステムプログラムを使いたいときに使うもののようですね．ここでどうやらPAMというものが使われるようです．これについて少し見てみましょう．もちろんman pamで詳しい情報を知ることができます．
PAMによる認証
PAMとは「Pluggable Authentication Modules」の略で，認証方式をまとめて管理し，変更しやすくするためのモジュールです．ログイン時やパスワード変更時，そして一般ユーザがシャットダウンを行おうとするときも，このPAMが認証を行います．
rebootコマンドを行ったときのPAM認証の流れを少し見てみましょう．まずはPAMの設定ファイルがあるディレクトリに移動します．
# cd /etc/pam.d # ls
シャットダウンや再起動に関わる，
- halt
- poweroff
- reboot
の設定ファイルが入っています．
これらのファイルをviエディタで開いてみましょう．
$ sudo vi reboot halt poweroff
何やらよくわからない分が羅列されていますね．各行の最初に書いてあるauth, accountというのが認証の種類，次のsufficient, requiredなどがアクション，そして最後が実際に認証を行うライブラリを表します．PAMの認証はauth, account, password, sessionの4つの段階すべてで成功する必要があります．何も書かれていない認証段階もありますが，それはデフォルトでOKということです．
rebootでは，auth認証とaccount認証のクリアが条件ということです．各行の意味をざっくり説明しましょう．
| 行 | 内容 | 意味 |
|---|---|---|
| 1 | #%PAM-1.0 | おまじない |
| 2 | auth sufficient pam_rootok.so | (auth認証)ルートであれば十分条件でクリア．そうでなければ次へ． |
| 3 | auth required pam_console.so | (auth認証)物理コンソールからのログインで条件を満たしていればクリア．そうでなければ認証失敗．結果に関わらず次へ． |
| 4 | #auth include system-auth | コメントアウトされているが，システムの認証方式を使って認証する． |
| 5 | account required pam_permit.so | (アカウント認証)すべてクリア． |
つまり，ポイントは3行目のpam_console.soです．pam_console.soが認証を行うものは主に二つあります．デバイスの所有権とアプリケーションアクセスです．manコマンドでpam_consoleを調べると詳しいことが書いてありますが，/etc/security/console.appsにファイルのあるコマンドは，物理コンソールから実行することができるということです．
参考：Red Hat Enterprise Linux 4: リファレンスガイド 章 16章. PAM（Pluggable Authentication Modules）
consolehelperの使用をusersメンバーに限定
これまでの調査で，一般ユーザがシステム管理コマンドであるhalt, rebootを使えた理由が分かってきました．まとめるとこんな感じです．
- /usr/binにコマンドを実行するバイナリファイルがある
- シンボリックリンクによりconsolehelperを呼び出している．
- consolehelper呼び出すPAM認証の中でpam_console.soの認証が行われる．
- /etc/security/console.appsにコマンド名のファイルがある．
consolehelperは実際非常に便利な機能です．usersメンバーに限定して，この機能は継続して使っていきたいですね．そこで，consolehelperの実行権限をusersに限定してみましょう．
ファイルの実行権限の変更
ファイルの実行権限については以前お話ししました．ls -lで調べることができるパーミッション，ファイルの所有者，所有グループによって，そのファイルへのアクセス権限が決まっており，実行権限はその「x」が表しています．(第6回)
では，consolehelperの実行権限を変えてみましょう．chmodコマンドを使います．
$ sudo chmod -v o-x /usr/bin/consolehelper
o-xというのは，「others」の「x」権限をなくす，という意味です．oの代わりに[u(ユーザ)，g(グループ)，a(全員)」を指定できます．また，権限を付与するときは「-」の代わりに「+」を指定します．
これで，一般ユーザにはconsolehelperが使えなくなりました．
ファイルの所有者・所有グループの変更
次は，ファイルの所有グループを変えます．chownコマンドかchgrpコマンドを使います．ここではchownを使いましょう．chown USERNAME:GROUPNAME FILENAMEという書式で使います．
$ sudo chown -v :users /usr/bin/consolehelper
これで，usersグループはconsolehelperを使うことができます．
試しに，suコマンドでusersグループではないaliceにログインしてhalt, rebootのフルパスを表示してみましょう．
$ su alice $ which halt reboot /sbin/halt /sbin/reboot
次に，usersグループのbobにログインして，同様に調べてみましょう．
$ exit $ su bob # ここではsudoは使わない．bobのパスワードを入力する． $ which halt reboot /usr/bin/halt /usr/bin/reboot
実行ファイルへのアクセスが，思い通りに制限されましたね．ちなみに，root権限でsuしてしまうと，/sbinの方が表示されるようになってしまいます．
今度は実際にhaltをbobで実行してみましょう．
$ halt halt: Need to be root
suでのログインでは物理コンソールでのログインとは見なされませんので，bobがhaltを実行してもPAMに弾かれてしまいます．
exitして，enryuでhaltしてみましょう．
$ exit $ halt
今度は正常に終了できたでしょうか．このように，usersメンバーが物理コンソールでログインしたときに限り，sudoなしでhaltによるシャットダウンができました．同様に，rebootやpoweroffコマンドも実行することができます．
次回
今回は権限の制御ということで，コマンドの実行ファイルを調べたり，PAMによる認証を覗いたり，実行ファイルの権限を変更したりしました．
まだGUIからのシャットダウンができてしまう点が解決されていませんね．次回は，usersのメンバー以外のGUIのメニューから，シャットダウン，再起動のボタンを消してしまいます．usersじゃない人はログアウトしてね，ということですね．これはPolkitの設定を変えることで実現できます．
それでは次回もよろしくお願いします．
PAM, consolehelperの使い方がこちらで紹介されています
Red Hat Enterprise Linux 4: リファレンスガイド 16.4. PAM設定ファイルのサンプル
いますぐ実践! Linuxシステム管理｜PAM をカスタマイズする
いますぐ実践! Linuxシステム管理｜システム管理ツールを気軽に使う
Previous | Top | Next
Prev: 【第9回】目指せLinuxマスター(1) ~sudoersの管理~
Next: 【第11回】目指せLinuxマスター(3) ~polkitの設定~
