SlideShare a Scribd company logo
1 of 121
Download to read offline
hbstudy#28

SELinux Hands-on
   2011年度版
 日本セキュアOSユーザ会
   (ishikawa84g)




                   1
本資料について

   本資料は下記資料をマージしたものを一部使用しています。

   2008年10月29日「セキュアOS塾-01」内
      第一部:今だから始める SELinux入門
       講師: 中村雄一氏
         http://goo.gl/WQLKT
         http://goo.gl/fn30a


   2009年5月28日「セキュアOS塾-03」内
      SELinuxを使ってみる入門BoF

      講師: 海外浩平氏
           http://goo.gl/b8iAK

   公開用に一部修正
      10px の怪しい位置の文章はノート部を一部転記したもの   2
セキュリティを決めるのは軍事力と政治ではない。
          法律と裁判所でもない。
   個々の人がどのように考え、行動するのかで決まる。




セキュリティ&プログラミングキャンプ2011 及び高度ポリテクセンター セミナー 資料より
TOMOYO Linux が考えたセキュリティ
                                                3
自己紹介

 HN: ishikawa84g
 Web: http://2done.org
 所属
       日本セキュアOSユーザ会 サーバ担当


   検閲




                             4
本日のトピック

1.   SELinux とは
2.   SELinux の効能
3.   簡単 SELinux 活用法
4.   付き合い方とコマンドの活用
5.   ハンズオン: WordPress の構築




                            5
1. SELinuxとは




               6
1.1. 質問

   あなたに守りたいものはありますか?




            High Key Baby Portrait
            By Wesley Oostvogels
            http://www.flickr.com/photos/higashitori/2700207474/
                                                                   7
            Attribution-NoDerivs 2.0 Generic (CC BY-ND 2.0)
1.2. セキュリティとは

   辞書的意味
       安全。保安。防犯。防犯装置。担保。

   なぜセキュリティが必要なのか
       守るべき資産が存在する
       資産に対する脅威が存在する

   資産に対する脅威がない場合 → セキュリティ不要
   資産価値よりもコストが大きい場合 → 通常不要

   特殊な例: 健康のためなら死んでもいい
       健康(生) <   死
                               8
1.3. 情報資産

   情報資産 とは
     個人情報
     技術情報

     財務情報

     知的財産

    など


   これらに対する脅威
     盗難,流出
     情報システムの停止

    など

                    9
1.4. 情報セキュリティ

   機密性(Confidentiality)
       権限のないユーザ、リソース、プロセスが保護された情
        報(権限のない情報)にアクセスできないようにすること

   完全性(Integrity)
       システムの情報が、
        故意または意図せず、変更されないよう保護すること

   可用性(Availability)
       権限のあるユーザが必要な時、いつでも必要なリソース
        にアクセスできること

情報セキュリティの3大要素(ISO/IEC27001より)
その他、真正性,責任追跡性,否認防止性,信頼性を含めることも可能
                                   10
1.5. アクセス制御

     目的
         正当な権限を持つユーザにリソースへのアクセスを許可
         権限のないユーザのアクセスを排除
         SELinux は機密性(アクセス制御)を担当する

     任意アクセス制御(DAC)
         UNIX系OSでサポートされている伝統的なアクセス制御方式
         リソースに対する所有者権限による制御
         root は神

     強制アクセス制御(MAC)
         SELinux 等が提供するアクセス制御方式
         root であってもセキュリティポリシーの適用(回避不能)
         リソースの所有者であってもアクセス権の変更不可

                                          11
セキュリティ技術の分類 ISO/IEC15408の機能要件抜粋
1.6. DAC と MAC は競合するか?

   答え
       DAC と MAC は共存する

   SELinux の場合、
    1. DAC のアクセス権限を評価
    2. MAC のアクセス権限を評価

   例: /tmp/file.txt (0777) の場合
     DAC のアクセス権限を評価
        1. 許可されている場合 → 通過
        2. 拒否されている場合 → 拒否
     MAC のアクセス権限を評価
        1. 許可されている場合 → 通過
        2. 拒否されている場合 → 拒否          12
1.7. SELinux とは

   いわゆるセキュアOS技術
       アメリカ国家安全保障局(NSA)を中心に開発
                                                          公開: 2000年12月22日
       http://www.nsa.gov/research/selinux/index.shtml   LSM 統合: 2003年8月13日




   機能:OSレベルでのアクセス制御機能の強化
       プロセス、ユーザを必要最小限の権限で動作させる
       rootでも逆らえないアクセス制御を提供する

   当たり前になってきている技術
       Linux Kernel 2.6.x 標準オプション
       RHEL, Fedora でデフォルトON
       最近は組込み向けでも注目!
            SMACKもよろしく!


   Linux Kernel におけるリファレンスモニタ の1つ                                       13
1.8. リファレンスモニタ

   リファレンスモニタとは
       セキュリティ分野では長い歴史のある概念
       管理下のリソースに対するアクセス要求を許可するか否か
        といった意思決定を行うモジュール
       セキュリティポリシーに基づいて意思決定をする
       ユーザのシステムに対するリクエストを例外なく捕捉する
        SELinuxの場合

                             リファレンス   セキュテリィ
                             モニタ       ポリシー

                  要求                           システム
             read,write など   評価           判定   リソース
    ユーザ      (システムコール)

                                       システム           14
1.9. セキュリティポリシー

   リファレンスモニタが満たすべき3つ条件
       回避不可能
       改ざん不可能
       検証可能

   セキュリティポリシー
       「誰が」「何に対して」「何をできる」のルールセット
       明示的な許可のない組み合わせは全て禁止
           ホワイトリスト方式
       SELinux ではセキュリティコンテキストを利用する


                                      15
1.10. セキュリティコンテキスト

   セキュリティコンテキスト
       セキュリティモデル上の識別子
       誰(Subject)・何(Object)・何を(Action) の識別子
       ファイル・プロセス・ユーザ・ソケットなど全てに付与

        プロセス       system_u:system_r:httpd_t:s0


        ファイル       system_u:object_r:shadow_t:s0


        ユーザ      staff_u:staff_r:staff_t:s0-s0:c0.c123
                                                         16
1.10. セキュリティコンテキスト

       system_u:object_r:shadow_t:s0
        ユーザ属性   ロール属性    タイプ属性    機密ラベル

   ユーザ属性
     サブジェクトやオブジェクトに付ける SELinux の ユーザID

   ロール属性
     ユーザに割り当てる権限の範囲を定義したもの

     ロールが不要なオブジェクトにはダミーロール(object_r)を付与

   タイプ属性
     SELinux がアクセス可否を判定する時に使用するセキュリティ属性

     プロセスに付与すると : ドメイン

     ファイルに付与すると : タイプ

   機密ラベル
     組織・役職などで分ける識別子                     17
小休止:
なぜ SELinux が必要とされたか




                      18
所謂、セキュアOSが必要とされた背景

   政府, 金融の要請
       TCSEC B1
       Common Criteria(EAL4+以上)
       LSPP


   日本だと
       政府機関の情報セキュリティ対策のための統一基準
           http://goo.gl/3FKoD
       金融機関等コンピュータシステムの安全対策基準
       経済産業省システム管理基準追補版


参考:第03回まっちゃ445勉強会
「セキュアOSが進化した歴史を振り返って来年はチャレンジしよう」(田口さん)   19
参加特典

   検閲




                20
SELinux が要求された背景

   先の要件を満たすため

   SELinux 出現以前はSolaris(Trusted Solaris)の独壇場

   EAL の認証はとれても、LSPP でEAL4+以上の取得が
    できなかった。

   SELinux のようなものを取り入れなければ
    調達基準をまったく満たせなかった


                                          21
2. SELinux の効能




                 22
2.1. 任意アクセス制御の課題

   user, group, others に rwx パーミッションを設定、
    ファイルアクセスを制御(DAC)
       余計なアクセスを許しうる
         othersパーミッションが立ってると誰でもアクセス可
         ネットワークアクセスは制限されない



   root は神
       root を取られるとおしまい

   root 昇格への抜け道
       一般ユーザ権限からでも root を取られてしまう
         setuid=0 のプログラムのセキュリティホールを突いて昇格
         カーネルセキュリティホールを突いて昇格
                                            23
2.2. 何が起こる?

   不正侵入されてしまった時
       バッファオーバーフロー攻撃
       ツールをダウンロード・実行、他のサイトへの攻撃
       など

   不具合を突いたアプリケーションの権限で
    任意の命令を実行可
       一般ユーザ から root に昇格
       コマンドインジェクション攻撃
       など


                                  24
2.2. 何が起こる?

   ログインユーザの誤操作・悪意
       誤操作(サーバ管理操作を root で実施)
         rm –rf /
         ウィルスを誤って実行


       悪意
         何かの脆弱性を利用した root への権限昇格
         攻撃ツールダウンロードおよび実行




                                    25
【息抜き】root 昇格への抜け道(デモ)

   検閲




                                 26
【息抜き】PHP標準機能の脆弱(デモ)

   検閲




                               27
2.3. SELinux の機能

   細かく厳密なアクセス制御
       プロセスに余計なアクセスを許さない
       ファイルパーミッション数百種類
       ネットワークアクセス、プロセス間通信なども制限
       抜け道がなく root であっても例外なく強制可能


   よく SELinux が悪さをして~…と言われるが
       ポリシーに基づいて制御をしているに過ぎない
       なんでも防ぐわけじゃない。許可されていないことだけ。



                                    28
2.4. SELinux の効能

     その1:不正な攻撃があった場合の防御
         攻撃者の動作を封じ込める

     その2:内部犯行に対する防御
         悪意あるユーザ、ユーザの操作ミスからの保護


      現代のコンピューティング環境によって生じる脅威は、セキュアな
      オペレーティングシステムの存在無しには対応不可能である。
      この事実を無視したあらゆるセキュリティ対策は
      「砂上の楼閣」に等しい。

      Loscocco, Smalley, Muckelbauer, Taylor, Turner, and Farrell
      米国家安全保障局(NSA:National Security Agency)
                                                                    29
「砂上に建てた楼閣は基礎がやわらかくて、てん覆するおそれがあることから、永続きしない物事のこと」(広辞苑)
2.5.1. 不正侵入対策(1)

   プロセスに必要最小限の権限を割り当てる


     httpd          samba        DNS


        アクセス可           アクセス可      アクセス可


    Webリソース        共有ファイル       ゾーンファイル

               権限外の
              アクセスは拒否

                   権限割り当て


                    SELinux                30
2.5.2. 不正侵入対策(2)

   攻撃者が取れる権限を限定
       root 権限奪取に対応。パッチ当てる前でも有効
         httpdのセキュリティホールを突いて乗っ取り



         httpd        samba         DNS


           アクセス可                      アクセス可
                        アクセス可

        Webリソース      共有ファイル        ゾーンファイル


httpdの権限しか取れない
この権限では悪さは困難                                   31
2.5.3. 不正侵入対策(3)

   実際はもっと早い段階で攻撃が止まる
       「バッファオーバーフロー攻撃」に必要な権限が足りず
        攻撃失敗
       攻撃支援ツールが使えず攻撃失敗
       SetUID の機能が利用できず攻撃失敗




                                32
【息抜き】root 昇格デモの場合

   検閲
       CAP_SETUID




                              33
2.6. ログインユーザのセキュリティ強化

   ログインユーザに独自の権限を割り当て可能

   「一般ユーザ」との違い
       ネットワーク操作も制限
           他ホストへの ping 送信禁止など
       普通のパーミッションチェックとは独立している
         others パーミッションが許可されていてもアクセスできない
         root になっても権限はそのまま


   活用例
       管理者の分割
           ログ管理者、Web管理者、メール管理者
       Webブラウズ専用のユーザ
                                            34
2.7. SELinux では防げないもの

1.   設定の不備
2.   与えられた権限内での破壊活動
3.   管理者や過大な権限を与えたユーザの犯行
4.   平易なパスワードを設定したことによるなりすまし
5.   カーネルのセキュリティホール
6.   DoS攻撃
7.   XSS, CSRF, SQLインジェクションなどのWebからの攻撃




                                         35
2.8.1. (応用)SELinux キオスクパソコン

   Fedora 9 から入っている SELinux 応用機能
       RHEL6 も対応

   キオスクパソコン:
       不特定多数の人が使える PC
         主に Web 閲覧を目的とする
         書店などでは専用プログラムによる検索機能を提供

       例:ネットカフェやホテルロビーの PC

   SELinux 安全なキオスク環境を構築可能

   参考: http://goo.gl/XQrY6
                                      36
2.8.2. 従来のキオスクパソコン



             ログイン・ユーザ
             (一般ユーザ権限)



                         (1)root昇格攻撃で
                         書き込み可能
(3)任意のネット    読み書き実行可
  ワーク通信可



 (2)不正プログラ   ホームディレクトリ   システムファイル
    ムも実行可


  キーロガーを仕込まれるかも! 踏み台に使われるかも!37
2.8.3. SELinux キオスク


             ログイン・ユーザ
             (SELinux独自権限)

                         (1) rootに昇格して
                         も書き込み不可
(3)http関連の   読み書き可              su, sudo 不可
 通信のみ可能      実行不可

(2)不正プログラ                      システムファイル
             ホームディレクトリ
   ム実行不可

                     独自の権限割り当て

                     SELinux

        ログインユーザ・ウィルスは悪さをできない                  38
2.8.4. SELinuxキオスクの構築

   構築はコマンド一発
       # yum -y install xguest

   RHEL6 の場合はインストール時、
    GNOME を選択すると自動的にインストールされる。
       らしい。(GUI使わないのでわかりません。。)

   詳細
       http://danwalsh.livejournal.com/13376.html




                                                     39
2.9. SELinuxの仕組み

   2つの仕掛け
       漏れの無いアクセス制御 ⇒ 強制アクセス制御
       最小限の権限で動作させる⇒ TE(Type Enforcement)




                                             40
2.10. 強制アクセス制御(MAC)

   やっても良いことを定義し、
    それに従った動作しかさせない。

     任意アクセス制御のイメージ                        強制アクセス制御適用後のイメージ




http://tomoyo.sourceforge.jp/about.html                  41
2.11.1. TE: Type Enforcement (1/3)

   型(タイプ)の強制(エンフォースメント)
       プロセス、ファイル、ソケット、etc...
            SELinux は、全ての資源をどれか1種類のタイプに当てはめる
       “型にはまった” 動作だけを許可
           ホワイトリスト方式



  Apache
サーバプロセス                           Jpeg画像             HTML文書




                      “file の read”
            httpd_t       を許可         httpd_sys_content_t     42
2.11.2. TE: Type Enforcement (2/3)

   セキュリティポリシーのルールの内容
       「誰が(Subject)」「何に(Object)」「何をできるか(Action)」
       例: Webサーバが、HTML文書を、読み込める
        allow httpd_t httpd_sys_content_t : file { read };



        Webサーバの型(タイプ)         HTML文書の型(タイプ)




                                                         43
2.11.3. TE: Type Enforcement (3/3)


                        read
                        mmap              /lib 共有ライブラリ


                                         read   lib_t
          PostgreSQL
                                         mmap
         サーバプロセス

         postgresql_t
                                                        read        HTML文書
read                              Apache
write                           サーバプロセス                        httpd_sys_content_t
                                   httpd_t

        データベース                  read
                               execute
         ファイル
                                                    CGIプログラム
    postgresql_db_t                                                            44
                                                 httpd_sys_script_t
3. 簡単 SELinux 活用法




                    45
3.1. SELinux が使えるディストリビューション

   RHEL, CentOS, Fedora, Scientific Linux などで
    SELinux デフォルト有効
       インストール作業は必要なし!

   Gentoo・Debian・Ubuntu など
       別途ポリシーファイルやユーティリティの導入が必要


   本気でやるなら Fedora 一択!
       漢なら黙って Rawhideとボスが言っていました。




                                                 46
3.2. SELinux の使い方

   初期設定
       初期からセキュリティポリシー、タイプが設定されている
       標準添付のアプリが最小限の権限で動くよう設定済

   トラブル対応が必要な場合
       まれによくトラブルが生じるので、それを解決する
         setroubleshoot の利用
         boolean の設定
         ラベルの設定
         ポリシーの作成




                                  47
3.3. SELinux 設定ファイル

   /etc/selinux/config


# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.

SELINUX=enforcing                                  ← SELinux の初期状態
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted                               ← SELinux のタイプ


                                                                     48
3.3. SELINUX

   SELinux の初期状態
       システム起動時の SELinux の状態を定義
         Enforcing      有効
         Permissive     警告
         Disabled       無効(コマンド変更不可)
       Permissive モード
           アクセス拒否のログのみを出力し実制御を行わないモード




                                         49
3.3. SELINUXTYPE

   SELinux のタイプ
       Targeted    特定のサブジェクトに対してのみ制御を行う
                    このあたりが制御対象: dhcpd, httpd, named, nscd, ntpd, portmap, snmpd, squid, syslogd
                    それ以外は制限を受けない、unconfined_t で動作する

       Strict      Targeted よりもさらに厳密なモード
                    unconfined_t を外したドSモード


       MLS         上記にRBAC(ロールベースアクセス制御)を追加したもの
                    ドMモード


   Strictモード
       RHEL5系の SELinux に存在したモード
       現在は統合されモジュール化されている
       RHEL6 以降で Strict モード相当にする場合はモジュールを外す
       参考
          http://danwalsh.livejournal.com/42394.html

          http://2done.org/index.php?id=38
                                                                                                  50
3.4. SELinux の状態を知る

   getenforce
       SELinux の現在の状態を表示する
    # getenforce
    Enforcing


   sestatus [-v]
       SELinux のステータスを表示する(-v で詳細表示)
    # sestatus
    SELinux status:            enabled
    SELinuxfs mount:           /sys/fs/selinux
    Current mode:              enforcing
    Mode from config file:     enforcing
    Policy version:            26
    Policy from config file:   targeted
                                                 51
3.5. ラベルを知る

   プロセスのタイプの確認
       ps –Z
    #ps –eZ
    LABEL                               PID TTY    TIME     CMD
    system_u:system_r:init_t:s0           1 ?      00:00:01 init
    system_u:system_r:httpd_t:s0       2655 ?      00:00:00 httpd


   ファイルのタイプの確認
       ls –Z
    # ls -Z /
    drwxr-xr-x   root   root   system_u:object_r:bin_t:s0      bin
    drwxr-xr-x   root   root   system_u:object_r:boot_t:s0     boot
    drwxr-xr-x   root   root   system_u:object_r:device_t:s0   dev
    drwxr-xr-x   root   root   system_u:object_r:etc_t:s0      etc

                                                                      52
3.4. SELinuxによるトラブル

   アプリケーションが動かない!

   原因は?
       セキュリティポリシーの不足やバグ
       SELinux によって、アクセスが拒否されてしまう

   SELinux を無効にする前に SELinux のせいか否か
    を切り分け、そして問題をスッキリ解決!




                                      53
3.5. トラブル切り分け

   2つの切り分け方法
    1.   Permissive モードでの動作確認
    2.   ログの確認




                                54
3.6. Permissiveモードでの動作確認

   Permissive モードではアクセス制御を行わない
       Permissive モードで動作すれば、
        トラブルの原因が SELinux かどうか分かる
       Permissive で操作をしてエラーがなければ SELinux が黒

   setenforce
     Permissive モードへの切り替え
    # setenforce 0

     Enforcing モードへの切り替え
    # setenforce 1

    ※コマンドでは Disabled に切り替えられない            55
3.7. ログの確認




    後述!

             56
3.8.1. setroubleshoot

   トラブルの解決はどうすれば?
       典型的なトラブルは setroubleshoot で解決可能

   setroubleshoot?
       SELinux の典型的トラブル事例を集約した DB を使い
         SELinux のトラブルを通知してくれる
         SELinux のトラブル解決方法を教えてくれる




                                         57
3.8.2. setroubleshoot:トラブルの通知

   SELinux が原因の問題が起こるとポップアップ




                                      58
3.8.3. setroubleshoot:解決方法の通知




                                59
3.8.4. コマンドラインからの利用

   setroubleshoot 動作時以下にログを出力する
       /var/log/messages

   ログの例
     # grep sealert /var/log/messages
    Dec 13 00:29:23 angler setroubleshoot: SELinux is preventing
    /usr/sbin/httpd from getattr access on the file
    /var/www/html/index.html. For complete SELinux messages. run sealert -l
    3d2b7a55-d060-4607-9b84-052cdd02e8c3
       赤字部分を実行するとヒントを出力してくれる。(LANG=C 推奨)



   実のところ…
       よく嘘をつかれますが参考程度に使ってみてください。
       が、Fedora 16 のはよさそう?
                                                                         60
3.8.5. 実行例
[root@angler log]# sealert -l 3d2b7a55-d060-4607-9b84-052cdd02e8c3
SELinux is preventing /usr/sbin/httpd from getattr access on the ファイル
    /var/www/html/index.html.

***** プラグイン restorecon (99.5 confidence) が提案しています             *************************

もし、ラベルを修正することになります。
/var/www/html/index.html のデフォルトラベルは httpd_sys_content_t のはずです。
そして、restorecon を実行することができます。
行ってください
# /sbin/restorecon -v /var/www/html/index.html

***** プラグイン catchall (1.49 confidence) が提案しています             ***************************

もし、httpd に、 index.html file の getattr アクセスがデフォルトで許可されるべきです。
そして、これをバグをして報告すべきです。
このアクセスを許可するために、ローカルポリシーモジュールを生成することができます。
行ってください
このアクセスを一時的に許可するには、以下を実行してください。:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol

                                                                                          61
3.9. 設定を触りたい場合は・・・

   セキュリティポリシを直接設定するのは難しいが、
    ツールの整備がゆっくりと進んでいる

   semanage
       ポリシの細かい調整を行なえるCLI

   SELinux Policy Generation Tool
       設定が用意されていないアプリの設定をウィザードで作れる

   SELinux Policy Editor (SEEdit): 開発停止中
       設定書式を根本から単純にしている
       自力で設定を作りたい場合に適する
            組込みシステム向けポリシ記述に特に適している
       http://seedit.sourceforge.net/      62
3.10. トラブルを解決できない時は?

   学ぶ
       ポリシーソースを読む
       RHEL6 のマニュアルや Fedora のマニュアルを読む
       本家 ML を購読する。質問する。
           結構教えてくれます、ただし英語


   ユーザ会MLに質問する
       フル日本語!
       濃い人が気づいたら教えてくれます。
           http://www.secureos.jp/




                                         63
4. 付き合い方とコマンドの活用




                   64
4.1. ~ 4.3. 検閲




                 65
4.4. SELinux を有効にする

   # vi /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.

#SELINUX=disabled
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted

                                                               66
4.5. 再ラベル付けをする

   SELinux 無効時作成されたファイル
        ラベルがつかない
        再ラベル付けをする必要がある


   /.autorelabel という空ファイルを作成し、再起動
    1.   # touch /.autorelabel
            ./autorelabel ではない
    2.   # shutdown –r 0
            起動時にファイルシステム全体に再ラベル付けが行われる


   超重要(失敗するとハンズオン終了)
        再ラベル付け際は、必ず Permissive にする
                                          67
4.5. 再ラベル付けをする

   /etc/selinux/config を編集し、permissive にする
       # sed -i "s/^¥(SELINUX=¥).*/¥1permissive/" /etc/selinux/config
       # grep ^S /etc/selinux/config
        SELINUX=permissive
        SELINUXTYPE=targeted
       # touch /.autorelabel
       # shutdown -r 0
       誤記があると、Disabled か カーネルパニックになるよ


   しばらくすると起動する
       これで再ラベル付けはOK




                                                                         68
4.5. 再ラベル付けをする

   起動を確認したら・・・
       再度、設定を編集
       # sed -i "s/^¥(SELINUX=¥).*/¥1enforcing/" /etc/selinux/config
       # grep ^S /etc/selinux/config
        SELINUX=enforcing
        SELINUXTYPE=targeted



       カレント状態を変更
       # setenforce 1

       状態を確認
       # sestatus

                                                                        69
4.6. ラベルを確認する

   ファイルのラベルを確認する
       ls -Z /


   プロセスのラベルを確認する
       ps axZ


   自分のラベルを確認する
       id
       id -Z


   今度は表示される!ようこそ SELinux!
                             70
4.7. 重要なパッケージ群

   libselinux-utils
       getenforce     …   SELinux の状態を表示
       setenforce     …   SELinux の状態を変更
       getsebool      …   Boolean の値を取得


   policycoreutils
       restorecon     …   再ラベル付けを行う
       run_init       …   略
       semodule       …   モジュールの設定を行う
       sestatus       …   SELinux の状態を表示
       setsebool      …   Boolean の値を設定

                                            71
4.7. 重要なパッケージ群

   policycoreutils-python
       audit2allow   …   ログからポリシーを生成する
       audit2why     …   アクセス拒否の理由を表示する
       semanage      …   各種設定を実施


   setools-console
       seinfo        …   SELinux policy query tool
       sesearch      …   SELinux のポリシーを表示




                                                      72
4.8. SELinux の状態を知る

   getenforce
       SELinux の現在の状態を表示する
    # getenforce
    Permissive


   sestatus [-v]
       SELinux のステータスを表示する(-v で詳細表示)
    # sestatus
    SELinux status:            enabled
    SELinuxfs mount:           /sys/fs/selinux
    Current mode:              enforcing
    Mode from config file:     enforcing
    Policy version:            26
    Policy from config file:   targeted
                                                 73
4.9. SELinux の状態を変更

   setenforce
       SELinux の現在の一時的に状態を変更する
       (Enforcing)     # setenforce 0
       (Permisssive)   # setenforce 1
       (Disabled)      # 不可。Disabled ←遷移不可→ Enforcing/Permissive


   sestatus
    # sestatus
    SELinux status:                 enabled
    SELinuxfs mount:                /sys/fs/selinux
    Current mode:                   permissive ← コマンドで変更した値
    Mode from config file:          enforcing   ← ファイルで設定した値
    Policy version:                 26
    Policy from config file:        targeted

                                                                    74
4.10. ポリシーソース

   SELinux 本体とポリシーは作成母体が違う
       本体: NSA, Red Hat
       ポリシー: Tresys, Red Hat


   今回は、Fedora 16 のSRPM を利用
       http://goo.gl/Cg1Dy


   現在のポリシーは "Reference Policy" と呼ぶ
       Tresysのはこっち: http://goo.gl/TV9Kf



                                           75
4.10. ポリシーソース

   良く見るディレクトリ
       ./policy/modules/*
            admin, app, kernel, roles, services, system


   ファイルの種類
       TE(Type Enforcement)
            ポリシー本体


       FC(File Context)
            どのファイルにどのラベルを設定するかを記述


       IF(Interface)
            外部モジュールに公開するインタフェース(マクロ)
                                                           76
4.10. ポリシーソース(zabbix.pp)

   zabbix のポリシーを読む
       ./policy/modules/services/zabbix.*




                                             77
4.11. ソースを読まずAllowを知る

   sesearch
       定義済みのポリシーを検索する

   書式
       sesearch [OPTIONS] RULE_TYPE [RULE_TYPE ...] [EXPESSION] [POLICY ...]


   よく使うオプション
       -A       Allow を出力
       -T       ドメイン遷移を表示
       -C       Boolean を設定した場合のポリシーを出力
       -s       scontext を指定
       -t       tcontext を指定
       -c       class を指定


                                                                         78
4.12. httpd_t 関連の Allow Rule

   # sesearch -A –C | head -100
   # sesearch -A -C -s httpd_t
   # sesearch -A -C -s httpd_t -c file
   # sesearch -A -C -s httpd_t -t httpd_sys_content_t -c file




                                                                 79
4.13. Apache + SELinux

   SELinux を有効にして、Apache を動作させる
    # yum -y install httpd
    # systemctl start httpd.service
    # ps axZ | grep httpd


   デモ用ファイル取得(自分で作らない事!)
    # cd /tmp
    # wget http://2done.org/sample/1.html
    # ls -Z /tmp/1.html
    # mv /tmp/1.html /var/www/html
                                            アクセス!   403
    # chown -R apache:apache /var/www
    # chmod 777 /var/www/html/1.html                      80
4.14. Permissive モードでの動作

   Permissive モードではアクセス制御を行わない
       Permissive モードで動作させ、原因を探る
       Permissive で操作をしてエラーがなければ SELinux が黒


   動作確認の際には、必ず Permissive モードにする
       意図しない動作が設定不備なのかSELinuxが原因なのかを切り分ける
       正しく設定してから SELinux を疑う


   Enforcing で動作が拒否された場合
       処理はそこで停止する

   Permissiveで動作させた場合
       処理が停止することはない
       拒否のログは出力する                             81
4.15.1. ログの確認

   既定のポリシーに反する操作はログとして記録される
       /var/log/audit/audit.log に拒否ログが出力される
       Enforcing で操作すると実際にアクセスが拒否される

   audit.log は auditd が起動中のみ出力される
   auditd 停止中は /var/log/messages に出力される




                                               82
4.15.2. audit.log の確認

   /var/log/audit/audit.log を確認する
    # grep denied /var/log/audit/audit.log
       httpd_t が tmp_t の属性を取得しようとして失敗

type=AVC msg=audit(1323703762.864:94): avc: denied { getattr }
for pid=1949 comm="httpd" path="/var/www/html/1.html"
dev=sda3 ino=26080 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file




                                                                 83
4.15.3. audit.log の読み方

type=AVC msg=audit(1323703762.864:94): avc: denied { getattr } for pid=1949 comm="httpd"
path="/var/www/html/1.html" dev=sda3 ino=26080 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file


項目                説明
type              監査ログのタイプ(AVC: SELinuxアクセス拒否ログ)
judge             アクセス許可の種類(denied, granted)
access vector     操作に使用しようとしたアクセスベクタ(read, write 等)
pid               プロセス番号:アクセス要求元プロセスのプロセス番号
comm              アクセス要求元のコマンド名
name              対象ファイル名
dev               対象デバイス名
ino               対象ファイルのinode番号
scontext          アクセスドメイン情報
tcontext          リソースラベル
tclass            リソース種別                                                                   84
4.15.4. ログのココを見よう

type=AVC msg=audit(1323703762.864:94): avc: denied { getattr } for pid=1949 comm="httpd"
path="/var/www/html/1.html" dev=sda3 ino=26080 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=file


   judge, access vector, scontext, tcontext, tclass あたりが重要
項目               値                                           説明
type             AVC                                         SELinux 関連のログ
judge            denied                                      拒否した
access vector    getattr                                     属性の取得
comm             httpd                                       アクセス要求元は httpd
name             1.html                                      対象ファイルは 1.html
ino              26080                                       ファイルの inode は 26080
scontext         system_u:system_r:httpd_t:s0                アクセス要求元のタイプ
tcontext         system_u:object_r:tmp_t:s0                  アクセス要求先のタイプ
tclass           file                                        クラスタイプは file

プロセス: httpd(httpd_t)の ファイル: 1.html (tmp_t)に対する属性取得要求を拒否した。
という意味になる。                                                                                  85
4.15.5. ログの時間が見辛い!

   正直、/var/log/audit/audit.log は見辛い
       時刻が人間に分かり難い
       ausearchコマンドでログを見る

   #ausearch -m avc
    time->Tue Dec 13 00:29:22 2011
    ....
    type=AVC msg=audit(1323703762.864:93): avc: denied { getattr } for
    pid=1949 comm="httpd" path="/var/www/html/index.html" dev=sda3
    ino=26080 scontext=system_u:system_r:httpd_t:s0
    tcontext=system_u:object_r:tmp_t:s0 tclass=file




                                                                         86
4.16.1. ラベルを設定

   FCファイル に定義がある場合
       restorecon コマンドでラベルの再設定が行える


   FCファイル に定義がない場合
       chcon で一時的にラベルを設定する
       semanage と restorecon でラベルを設定する


   許可しようとしているポリシーは正しいか
       理解するには多くの時間 SELinux に触れる必要がある



                                          87
4.16.2. restorecon

   既定値に従いファイルコンテキストを設定し直す

   書式
       restorecon [-o outfilename ] [-R] [-n] [-p] [-v] [-e directory ] pathname...
       restorecon -f infilename [-o outfilename ] [-e directory ] [-R] [-n] [-p] [-v] [-F]


   よく使うオプション
       -R         再帰的にラベルを設定する
       -F         強制的にラベルを再設定する
       -v         ラベルが再設定されたものを表示する


   今回はFCファイル に定義がある
       # restorecon -FRv /var/www/html                           定義を知るには?


                                                                                      88
4.16.3. semanage

   定義済みのラベルを付与するパスを表示/設定する

   書式
       semanage fcontext -{a|d|m|l|D|E} [-efnrst] file_spec


   よく使うオプション
       -a       : 定義を追加
       -m       : 定義を修正
       -d       : 定義を削除
       -t       : タイプを指定


# semanage fcontext -l | grep /var/www                         89
[追記]どこにどのラベルを付けるか
   どこにどのラベルを付けるか
   どのラベルを付ければよいのか

   これらを知るには多くの時間 SELinux と付き合う必要があります。
       ドキュメントを読む
       TE, FC をみる
       職人の世界と言われても仕方ない


   ここはどう頑張っても一概には言えません。
   個々の事例でその場合は何と言えますが、こういう場合はこう!
    といいきることはできません。

   この部分が SELinux を触る人が一番挫折していく箇所ではないかと思っ
    ています。
       ラベルに対する混乱
       付けて動いたものの本当にこれで良いのかを判断できない不安
                                          90
4.17. トラブル解決フロー

1. SELinux が原因か / Enforcing でも動作するか
  /var/log/audit/audit.log を確認
  Permissive モードで動作するか


2. ポリシーを変更せずに対応する
  適切なファイルコンテキストを付与する
  boolean値を変更する

3. 最終手段ポリシーを作成する
  自らポリシーを付与する

4. 本家MLに質問する(バグかも?)
                                      91
5. ミニ実践 3本




             92
5.1.1. UserDir の設定

   UserDir を設定してみよう
       # useradd angler
       # vim /etc/httpd/conf/httpd.conf
        UserDir disabled
        ↓
        UserDir public_html
       # systemctl restart httpd.service
       # su - angler
       $ mkdir ~/public_html
       $ cd ~/public_html
       $ wget http://2done.org/sample/1.html
       # restorecon -RF ~angler            アクセス!   403
                                                          93
5.1.2. Permissive での動作

1. Permissive モードで動作を確認

   アクセス!   403




2. まだ、403。
  設定不備の可能性
  UserDir を使用する時にはユーザディレクトリに
   o+x が必要
  # chmod o+x ~angler

   アクセス!
                                94
5.1.3. Enforce での動作

3. Enforce モードで動作を確認

   アクセス!     403




4. まだ、403。ログを確認。
  # grep denied /var/log/audit/audit.log




                                            95
5.1.4. ログの確認

avc: denied { getattr } for pid=1276
comm="httpd" path="/home/angler" dev=sda4
ino=139633
scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:user_home_dir_t:s0
  tclass=dir



•   httpd(httpd_t) が
•   /home/angler (user_home_dir_t)に対して
•   属性取得(getattr)することを拒否
5.1.5. ポリシーの調査

•   httpd(httpd_t) が
•   /home/angler (user_home_dir_t)に対して
•   属性取得(getattr)することを拒否

1. これを許可する定義がないか確認
     # sesearch -A -C -s httpd_t -t user_home_dir_t -c dir
        Found 2 semantic av rules:
        DT allow httpd_t user_home_dir_t : dir { getattr search open } ; [ httpd_enable_homedirs ]
        DT allow httpd_t user_home_dir_t : dir { ioctl read getattr lock search open } ; [ httpd_read_user_content ]



 定義自体はありそう
       ただし、[BOOLEAN] がデフォルト無効(DT)になっている
       Boolean 値を有効にすることでアクセスが可能になる
       Boolean?
5.2.1. Boolean値

   Boolean値(条件変数)
       セキュリティポリシーの一部をBooleanと呼ばれる条件変数の値に
        応じて動的に有効化/無効化するための機能
       Boolean 値 が True の場合のみ追加のアクセス許可を与える


       こんなイメージ
        if (boolenA) {
            ...
            許可ルール
            ...
        }




                                          98
5.2.3. Boolean値の確認と設定

   Boolean値の確認
      コマンド: getsebool

      書式:
      getsebool [-a] [boolean]

   Boolean値の設定
      コマンド: setsebool

      書式:
      setsebool [ -P ] boolean value | bool1=val1 bool2=val2 ...

    ※ 設定は一時的なものとなり再起動後は初期化される
      永続的に設定したい場合は P オプション を付与する


                                                                   99
5.2.4. Boolean値の意味を知る

   それが何かをどうやって知るか
       ポリシーソースを見る
       sesearch を使用する
       Web で検索


   どうやってあたりをつけるか
       名前から判断
       setroubleshoot に頼る
       その他、長年の勘と経験と。。。


   RHEL6 の SELinux マニュアルには各Booleanの意味が書か
    れているのでオススメ

                                       100
5.1.6. Boolean を設定をする

    今回はBoolean <httpd_enable_homedirs>を設定
1.   状態を取得
        # getsebool httpd_enable_homedirs
         httpd_enable_homedirs --> off


2.   状態を変更する
        # setsebool [-P] httpd_enable_homedirs 1


3.   状態を取得
        # getsebool httpd_enable_homedirs
         httpd_enable_homedirs --> on

                                                    101
5.3.1. DocumentRoot変更

   /www をDocumentRoot に変更する
    1.   # mkdir /www
    2.   # chown apache:apache /www
    3.   # vim /etc/httpd/conf/httpd.conf
         DocumentRoot "/www"
    4.   (F16) # systemctl restart httpd.service
         (C6) # run_init /etc/init.d/httpd restart
    5.   アクセス!


   デフォルトトップページが表示される
        index.html へのアクセス拒否

                                                     102
5.3.2. Permissive モード

   Permissive モードで動作させる
       # setenforce 0


   ログを確認する
       # grep denied /var/log/audit/audit.log


   再ラベル付けをする
       # restorecon -RFv /www
       # setenforce 1


                  403
                          定義がないので restorecon ではダメ
        アクセス!
                          定義を作る
                                                 103
5.3.3. 解決方法は?

1.   httpd_t がアクセスできるラベルを付与する
        推奨
        5.4. で解説


2.   オリジナルポリシーを作る
        httpd_t が default_t にアクセスすることを許可
        5.5. で解説




                                            104
5.4. ラベルを付与する

   定義されたラベルが存在する
       httpd_sys_content_t を設定
       # semanage fcontext -a -t httpd_sys_content_t "/www(/.*)?"
       # restorecon -RFv /www


                                                         アクセス!




                                                                     105
5.5.1. オリジナルポリシーを作る

    正攻法は自分で TE と FC を作る
        IF はとりあえず無くてもOK
    面倒な場合はログからポリシーを自動生成する

    下準備
    1.   5.4.で定義したラベル削除する
         # semanage fcontext -d -t httpd_sys_content_t "/www(/.*)?"
    2.   再ラベル付け
         # restorecon -RFv /www
    3.   audit.log の初期化
         # echo -n > /var/log/audit/audit.log
         # systemctl restart auditd.service

                                                                      106
5.5.2. audit2allow

   audit2allow
       ログファイルからルールを生成する

   書式
       audit2allow [options]

   よく使うオプション
       -a              auditログとmessageログを入力とする
       -d              dmesgコマンドの出力を入力とする
       -i              input ファイルを指定
       -m [module]     指定したモジュールを生成
       -M              モジュールをバイナリで生成
       -R              インストール済みマクロを使用してポリシーを生成
       -v              詳細出力

                                                  107
5.5.2. オリジナルポリシーを作る

   # audit2allow -R -i /var/log/audit/audit.log -m local ¥
    > local.te
   または



   # cat /var/log/audit/audit.log | ¥
      audit2allow -R -m local > local.te


   重要
       この時、不要な定義がある場合は手動で抹消する

   コンパイル
    # make -f /usr/share/selinux/devel/Makefile
                                                              108
5.5.3. semodule

   semodule
       SELinux のモジュール管理ツール

   書式
       semodule [options]... MODE [MODES]...

   よく使うオプション
       -l             ロード済みのモジュールリストを出力
       -i [module]    モジュールを適用する
       -r [module]    ロード済みのモジュールを取り除く
       -R             ロード済みのモジュールを再ロードする
       -d             ロード済みのモジュールを無効化する
       -e             ロード済みのモジュールを有効化する


                                                109
5.5.4. モジュールを組み込む

   作成したモジュールを組み込む
       # semodule –i local.pp
       # semodule -l | grep local
       # semodule -R




                                     110
6. 実践 SELinux ~CMSの構築~




                         111
6.1. 環境

   Fedora 16
   Apache 2.2.x
   PHP 5.3.x
   MySQL 5.5.x
   WordPress 3.3
      http://ja.wordpress.org/



   今回は (説明が面倒なので)DocumentRoot に直接インストールをする




                                          112
6.3. WordPress 展開と権限付与

   WordPress を展開し、権限を付与する
    # cd /var/www/html
    # wget http://ja.wordpress.org/wordpress-3.3-ja.zip
    # unzip wordpress-3.3-ja.zip
    # rm -f wordpress-3.3-ja.zip
    # mv wordpress/* .
    # rmdir wordpress
    # chown -R apache:apache /var/www/html
    # restorecon -RFv /var/www/html




                                                          113
6.4. /etc/my.cnf 設定
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
character-set-server=utf8

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
character-set-server=utf8

[mysql]
default-character-set=utf8

[mysqldump]
default-character-set=utf8

[client]
default-character-set=utf8
                                                                               114
6.5. MySQL 設定

# service mysqld start
# mysql -u root
mysql> create database wordpress;
mysql> grant all privileges on wordpress.* to
        wordpress@localhost identified by 'PASSW0RD';
mysql> exit

※ ID/PASSWD は適切に設定する
  基盤が脆弱であればシステム全体が脆弱になってしまう




                                                        115
6.6. サービスの起動と自動設定

   Apache
       # systemctl start httpd.service
       # systemctl enable httpd.service


   MySQL
       # systemctl start mysqld.service
       # systemctl enable mysqld.service




                                            116
(個人的な考え)

   インストール時は Permissive する
       インストールに必要な権限と運用に必要な権限は異なる
       不要なファイルへの書き込みなどが発生する
          共通設定ファイルの作成
          ./install などのファイル削除



   以降、WordPress のインストールを行うが
    Permissive でインストールを行う
       # setenforce 0




                                    117
6.7. WordPress のインストール

1.   http://127.0.0.1/wp-admin/install.php を表示
2.   「設定ファイルを作成する」を押下
3.   「次に進みましょう !」を押下
4.   データベース設定をし、「作成する」を押下
     ※ ここで SELinux のエラーとなるがスルー
5. 「インストール実行」を押下
6. サイト設定をし「 WordPress をインストール」を押下
     ※ ここでも多量のエラーが発生する
7. 実際にログインをしてみる




                                                 118
6.8. 下準備とログ出力

1. インストール時の audit.log 削除
   # echo -n > /var/log/audit/audit.log

2. システム全体のラベルを再設定
   # touch /.autorelabel
   # shutdown -r now

3. 再度 Permissive モードにし WordPress を一通り操作する
   # setenforce 0




                                          119
6.9. 俺たちの戦いはまだまだこれからだ

   さぁ、あとは頑張って解くんだ
       ヒント: https_sys_rw_content_t




                                      120
chcon

   定義済みのラベルを"一時的"に付与する

   書式
       chcon [OPTION]... CONTEXT FILE...
       chcon [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...
       chcon [OPTION]... --reference=RFILE FILE...


   よく使うオプション
       -R        : 再帰的にラベルを付与
       -u        : SELinux USER を設定
       -r        : SELinux role を設定
       -t        : File Context を設定
       -l        : range を設定

注意: chcon で設定したラベルは restorecon などで初期化される                                     121

More Related Content

What's hot

Debianの修正はどのように出荷されるか
Debianの修正はどのように出荷されるかDebianの修正はどのように出荷されるか
Debianの修正はどのように出荷されるかHideki Yamane
 
ARM LinuxのMMUはわかりにくい
ARM LinuxのMMUはわかりにくいARM LinuxのMMUはわかりにくい
ARM LinuxのMMUはわかりにくいwata2ki
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」Masahito Zembutsu
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Akihiro Suda
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較Akihiro Suda
 
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会ShuheiUda
 
Linux-HA Japanプロジェクトのこれまでとこれから
Linux-HA JapanプロジェクトのこれまでとこれからLinux-HA Japanプロジェクトのこれまでとこれから
Linux-HA Japanプロジェクトのこれまでとこれからksk_ha
 
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方歩 柴田
 
Dockerと外部ルータを連携させる仕組みを作ってみた
Dockerと外部ルータを連携させる仕組みを作ってみたDockerと外部ルータを連携させる仕組みを作ってみた
Dockerと外部ルータを連携させる仕組みを作ってみたnpsg
 
#logstudy 01 rsyslog入門
#logstudy 01 rsyslog入門#logstudy 01 rsyslog入門
#logstudy 01 rsyslog入門Takashi Takizawa
 
PostgreSQLの冗長化について
PostgreSQLの冗長化についてPostgreSQLの冗長化について
PostgreSQLの冗長化についてSoudai Sone
 
基礎から学ぶ組み込みAndroid
基礎から学ぶ組み込みAndroid基礎から学ぶ組み込みAndroid
基礎から学ぶ組み込みAndroiddemuyan
 
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/Fall
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/FallZabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/Fall
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/FallAtsushi Tanaka
 
VirtualBox と Rocky Linux 8 で始める Pacemaker ~ VirtualBox でも STONITH 機能が試せる! Vi...
VirtualBox と Rocky Linux 8 で始める Pacemaker  ~ VirtualBox でも STONITH 機能が試せる! Vi...VirtualBox と Rocky Linux 8 で始める Pacemaker  ~ VirtualBox でも STONITH 機能が試せる! Vi...
VirtualBox と Rocky Linux 8 で始める Pacemaker ~ VirtualBox でも STONITH 機能が試せる! Vi...ksk_ha
 
Serf / Consul 入門 ~仕事を楽しくしよう~
Serf / Consul 入門 ~仕事を楽しくしよう~Serf / Consul 入門 ~仕事を楽しくしよう~
Serf / Consul 入門 ~仕事を楽しくしよう~Masahito Zembutsu
 
MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話Yoshinori Matsunobu
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Masahito Zembutsu
 
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例kazuhcurry
 
【SRX】JUNOS ハンズオントレーニング資料 SRXシリーズ サービス ゲートウェイ コース
【SRX】JUNOS ハンズオントレーニング資料 SRXシリーズ サービス ゲートウェイ コース【SRX】JUNOS ハンズオントレーニング資料 SRXシリーズ サービス ゲートウェイ コース
【SRX】JUNOS ハンズオントレーニング資料 SRXシリーズ サービス ゲートウェイ コースJuniper Networks (日本)
 

What's hot (20)

Debianの修正はどのように出荷されるか
Debianの修正はどのように出荷されるかDebianの修正はどのように出荷されるか
Debianの修正はどのように出荷されるか
 
ARM LinuxのMMUはわかりにくい
ARM LinuxのMMUはわかりにくいARM LinuxのMMUはわかりにくい
ARM LinuxのMMUはわかりにくい
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
initramfsについて
initramfsについてinitramfsについて
initramfsについて
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較
 
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
 
Linux-HA Japanプロジェクトのこれまでとこれから
Linux-HA JapanプロジェクトのこれまでとこれからLinux-HA Japanプロジェクトのこれまでとこれから
Linux-HA Japanプロジェクトのこれまでとこれから
 
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
 
Dockerと外部ルータを連携させる仕組みを作ってみた
Dockerと外部ルータを連携させる仕組みを作ってみたDockerと外部ルータを連携させる仕組みを作ってみた
Dockerと外部ルータを連携させる仕組みを作ってみた
 
#logstudy 01 rsyslog入門
#logstudy 01 rsyslog入門#logstudy 01 rsyslog入門
#logstudy 01 rsyslog入門
 
PostgreSQLの冗長化について
PostgreSQLの冗長化についてPostgreSQLの冗長化について
PostgreSQLの冗長化について
 
基礎から学ぶ組み込みAndroid
基礎から学ぶ組み込みAndroid基礎から学ぶ組み込みAndroid
基礎から学ぶ組み込みAndroid
 
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/Fall
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/FallZabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/Fall
Zabbix最新情報 ~Zabbix 6.0に向けて~ @OSC2021 Online/Fall
 
VirtualBox と Rocky Linux 8 で始める Pacemaker ~ VirtualBox でも STONITH 機能が試せる! Vi...
VirtualBox と Rocky Linux 8 で始める Pacemaker  ~ VirtualBox でも STONITH 機能が試せる! Vi...VirtualBox と Rocky Linux 8 で始める Pacemaker  ~ VirtualBox でも STONITH 機能が試せる! Vi...
VirtualBox と Rocky Linux 8 で始める Pacemaker ~ VirtualBox でも STONITH 機能が試せる! Vi...
 
Serf / Consul 入門 ~仕事を楽しくしよう~
Serf / Consul 入門 ~仕事を楽しくしよう~Serf / Consul 入門 ~仕事を楽しくしよう~
Serf / Consul 入門 ~仕事を楽しくしよう~
 
MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話MHA for MySQLとDeNAのオープンソースの話
MHA for MySQLとDeNAのオープンソースの話
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
 
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
 
【SRX】JUNOS ハンズオントレーニング資料 SRXシリーズ サービス ゲートウェイ コース
【SRX】JUNOS ハンズオントレーニング資料 SRXシリーズ サービス ゲートウェイ コース【SRX】JUNOS ハンズオントレーニング資料 SRXシリーズ サービス ゲートウェイ コース
【SRX】JUNOS ハンズオントレーニング資料 SRXシリーズ サービス ゲートウェイ コース
 

Viewers also liked

VlanManagerを使ってみた
VlanManagerを使ってみたVlanManagerを使ってみた
VlanManagerを使ってみたHiroki Ishikawa
 
OpenStackを体で操作する
OpenStackを体で操作するOpenStackを体で操作する
OpenStackを体で操作するHiroki Ishikawa
 
SELinuxによる攻撃防止の例
SELinuxによる攻撃防止の例SELinuxによる攻撃防止の例
SELinuxによる攻撃防止の例Hiroki Ishikawa
 
OpenStackの情報をどこから得ているのか
OpenStackの情報をどこから得ているのかOpenStackの情報をどこから得ているのか
OpenStackの情報をどこから得ているのかHiroki Ishikawa
 
AvailabilityZoneとHostAggregate
AvailabilityZoneとHostAggregateAvailabilityZoneとHostAggregate
AvailabilityZoneとHostAggregateHiroki Ishikawa
 
Sidekiq Proを1年ほど使ってみて良かったところ、困ったところ | 新宿.rb 29th #shinjukurb
Sidekiq Proを1年ほど使ってみて良かったところ、困ったところ | 新宿.rb 29th #shinjukurbSidekiq Proを1年ほど使ってみて良かったところ、困ったところ | 新宿.rb 29th #shinjukurb
Sidekiq Proを1年ほど使ってみて良かったところ、困ったところ | 新宿.rb 29th #shinjukurbKoichiro Sumi
 
韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015
韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015
韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015CODE BLUE
 
気になるあのコにアタック☆
気になるあのコにアタック☆気になるあのコにアタック☆
気になるあのコにアタック☆Hiroki Ishikawa
 
rsyslog + SE-PostgreSQL = ???
rsyslog + SE-PostgreSQL = ???rsyslog + SE-PostgreSQL = ???
rsyslog + SE-PostgreSQL = ???Hiroki Ishikawa
 
APASEC 2013 - ROP/JIT を使わずに DEP/ASLR を回避する手法を見てみた。
APASEC 2013 - ROP/JIT を使わずに DEP/ASLR を回避する手法を見てみた。APASEC 2013 - ROP/JIT を使わずに DEP/ASLR を回避する手法を見てみた。
APASEC 2013 - ROP/JIT を使わずに DEP/ASLR を回避する手法を見てみた。Satoshi Mimura
 
リナックスに置ける様々なリモートエキスプロイト手法 by スクハー・リー
リナックスに置ける様々なリモートエキスプロイト手法 by スクハー・リーリナックスに置ける様々なリモートエキスプロイト手法 by スクハー・リー
リナックスに置ける様々なリモートエキスプロイト手法 by スクハー・リーCODE BLUE
 
動的計画法入門(An introduction to Dynamic Programming)
動的計画法入門(An introduction to Dynamic Programming)動的計画法入門(An introduction to Dynamic Programming)
動的計画法入門(An introduction to Dynamic Programming)kakira9618
 
CamSec Sept 2016 - Tricks to improve web app excel export attacks
CamSec Sept 2016 - Tricks to improve web app excel export attacksCamSec Sept 2016 - Tricks to improve web app excel export attacks
CamSec Sept 2016 - Tricks to improve web app excel export attacksJerome Smith
 
第9回 OpenStack 勉強会(Glance)
第9回 OpenStack 勉強会(Glance)第9回 OpenStack 勉強会(Glance)
第9回 OpenStack 勉強会(Glance)Hiroki Ishikawa
 
障害対応・運用におけるトリアージ的対応とZabbixの活用
障害対応・運用におけるトリアージ的対応とZabbixの活用障害対応・運用におけるトリアージ的対応とZabbixの活用
障害対応・運用におけるトリアージ的対応とZabbixの活用Masahito Zembutsu
 

Viewers also liked (20)

VlanManagerを使ってみた
VlanManagerを使ってみたVlanManagerを使ってみた
VlanManagerを使ってみた
 
OpenStackを体で操作する
OpenStackを体で操作するOpenStackを体で操作する
OpenStackを体で操作する
 
SELinuxによる攻撃防止の例
SELinuxによる攻撃防止の例SELinuxによる攻撃防止の例
SELinuxによる攻撃防止の例
 
OpenStackの情報をどこから得ているのか
OpenStackの情報をどこから得ているのかOpenStackの情報をどこから得ているのか
OpenStackの情報をどこから得ているのか
 
AvailabilityZoneとHostAggregate
AvailabilityZoneとHostAggregateAvailabilityZoneとHostAggregate
AvailabilityZoneとHostAggregate
 
MySQL Casual な生活
MySQL Casual な生活MySQL Casual な生活
MySQL Casual な生活
 
Sidekiq Proを1年ほど使ってみて良かったところ、困ったところ | 新宿.rb 29th #shinjukurb
Sidekiq Proを1年ほど使ってみて良かったところ、困ったところ | 新宿.rb 29th #shinjukurbSidekiq Proを1年ほど使ってみて良かったところ、困ったところ | 新宿.rb 29th #shinjukurb
Sidekiq Proを1年ほど使ってみて良かったところ、困ったところ | 新宿.rb 29th #shinjukurb
 
韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015
韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015
韓国のサイバーセキュリティ人材資源への投資 by Seungjoo Gabriel Kim - CODE BLUE 2015
 
Sesearch
SesearchSesearch
Sesearch
 
気になるあのコにアタック☆
気になるあのコにアタック☆気になるあのコにアタック☆
気になるあのコにアタック☆
 
rsyslog + SE-PostgreSQL = ???
rsyslog + SE-PostgreSQL = ???rsyslog + SE-PostgreSQL = ???
rsyslog + SE-PostgreSQL = ???
 
APASEC 2013 - ROP/JIT を使わずに DEP/ASLR を回避する手法を見てみた。
APASEC 2013 - ROP/JIT を使わずに DEP/ASLR を回避する手法を見てみた。APASEC 2013 - ROP/JIT を使わずに DEP/ASLR を回避する手法を見てみた。
APASEC 2013 - ROP/JIT を使わずに DEP/ASLR を回避する手法を見てみた。
 
AppArmorの話
AppArmorの話AppArmorの話
AppArmorの話
 
リナックスに置ける様々なリモートエキスプロイト手法 by スクハー・リー
リナックスに置ける様々なリモートエキスプロイト手法 by スクハー・リーリナックスに置ける様々なリモートエキスプロイト手法 by スクハー・リー
リナックスに置ける様々なリモートエキスプロイト手法 by スクハー・リー
 
動的計画法入門(An introduction to Dynamic Programming)
動的計画法入門(An introduction to Dynamic Programming)動的計画法入門(An introduction to Dynamic Programming)
動的計画法入門(An introduction to Dynamic Programming)
 
CamSec Sept 2016 - Tricks to improve web app excel export attacks
CamSec Sept 2016 - Tricks to improve web app excel export attacksCamSec Sept 2016 - Tricks to improve web app excel export attacks
CamSec Sept 2016 - Tricks to improve web app excel export attacks
 
OpenStack & SELinux
OpenStack & SELinuxOpenStack & SELinux
OpenStack & SELinux
 
第9回 OpenStack 勉強会(Glance)
第9回 OpenStack 勉強会(Glance)第9回 OpenStack 勉強会(Glance)
第9回 OpenStack 勉強会(Glance)
 
XSS再入門
XSS再入門XSS再入門
XSS再入門
 
障害対応・運用におけるトリアージ的対応とZabbixの活用
障害対応・運用におけるトリアージ的対応とZabbixの活用障害対応・運用におけるトリアージ的対応とZabbixの活用
障害対応・運用におけるトリアージ的対応とZabbixの活用
 

Similar to hbstudy# 28 SELinux HandsOn 公開版

Active Directory 侵害と推奨対策
Active Directory 侵害と推奨対策Active Directory 侵害と推奨対策
Active Directory 侵害と推奨対策Yurika Kakiuchi
 
使いこなせて安全なLinuxを目指して
使いこなせて安全なLinuxを目指して使いこなせて安全なLinuxを目指して
使いこなせて安全なLinuxを目指してToshiharu Harada, Ph.D
 
20031020 「プロセス実行履歴に基づくアクセスポリシー自動生成システム」
20031020 「プロセス実行履歴に基づくアクセスポリシー自動生成システム」20031020 「プロセス実行履歴に基づくアクセスポリシー自動生成システム」
20031020 「プロセス実行履歴に基づくアクセスポリシー自動生成システム」Toshiharu Harada, Ph.D
 
20031030 「読み込み専用マウントによる改ざん防止Linuxサーバの構築」
20031030 「読み込み専用マウントによる改ざん防止Linuxサーバの構築」20031030 「読み込み専用マウントによる改ざん防止Linuxサーバの構築」
20031030 「読み込み専用マウントによる改ざん防止Linuxサーバの構築」Toshiharu Harada, Ph.D
 
Linuxセキュリティ強化エッセンシャル
Linuxセキュリティ強化エッセンシャルLinuxセキュリティ強化エッセンシャル
Linuxセキュリティ強化エッセンシャルToshiharu Harada, Ph.D
 
闘うITエンジニアのためのLinuxセキュリティ講座
闘うITエンジニアのためのLinuxセキュリティ講座闘うITエンジニアのためのLinuxセキュリティ講座
闘うITエンジニアのためのLinuxセキュリティ講座Toshiharu Harada, Ph.D
 
Linux Security
Linux SecurityLinux Security
Linux Securitysounakano
 
Sec014 ゼロデイ攻撃やラ
Sec014 ゼロデイ攻撃やラSec014 ゼロデイ攻撃やラ
Sec014 ゼロデイ攻撃やラTech Summit 2016
 
CaitSith 新しいルールベースのカーネル内アクセス制御
CaitSith 新しいルールベースのカーネル内アクセス制御CaitSith 新しいルールベースのカーネル内アクセス制御
CaitSith 新しいルールベースのカーネル内アクセス制御Toshiharu Harada, Ph.D
 
Active directory のセキュリティ対策 130119
Active directory のセキュリティ対策 130119Active directory のセキュリティ対策 130119
Active directory のセキュリティ対策 130119wintechq
 
[data security showcase Sapporo 2015] D22:今求められるセキュリティレベルとFireEye適応型防御 by ファイ...
[data security showcase Sapporo 2015] D22:今求められるセキュリティレベルとFireEye適応型防御 by ファイ...[data security showcase Sapporo 2015] D22:今求められるセキュリティレベルとFireEye適応型防御 by ファイ...
[data security showcase Sapporo 2015] D22:今求められるセキュリティレベルとFireEye適応型防御 by ファイ...Insight Technology, Inc.
 
クラウド移行で解決されるセキュリティとリスク 公開用
クラウド移行で解決されるセキュリティとリスク 公開用クラウド移行で解決されるセキュリティとリスク 公開用
クラウド移行で解決されるセキュリティとリスク 公開用Lumin Hacker
 
Bitvisorをベースとした既存Windowsのドライバメモリ保護
Bitvisorをベースとした既存Windowsのドライバメモリ保護Bitvisorをベースとした既存Windowsのドライバメモリ保護
Bitvisorをベースとした既存Windowsのドライバメモリ保護Kuniyasu Suzaki
 
OSやアプリを問わず装着するだけで重要データを防御するセキュリティバリアデバイス by 戸田 賢二
OSやアプリを問わず装着するだけで重要データを防御するセキュリティバリアデバイス by 戸田 賢二OSやアプリを問わず装着するだけで重要データを防御するセキュリティバリアデバイス by 戸田 賢二
OSやアプリを問わず装着するだけで重要データを防御するセキュリティバリアデバイス by 戸田 賢二CODE BLUE
 
プロセス実行履歴に基づくアクセスポリシー自動生成システム
プロセス実行履歴に基づくアクセスポリシー自動生成システムプロセス実行履歴に基づくアクセスポリシー自動生成システム
プロセス実行履歴に基づくアクセスポリシー自動生成システムToshiharu Harada, Ph.D
 

Similar to hbstudy# 28 SELinux HandsOn 公開版 (20)

Active Directory 侵害と推奨対策
Active Directory 侵害と推奨対策Active Directory 侵害と推奨対策
Active Directory 侵害と推奨対策
 
使いこなせて安全なLinuxを目指して
使いこなせて安全なLinuxを目指して使いこなせて安全なLinuxを目指して
使いこなせて安全なLinuxを目指して
 
20031020 「プロセス実行履歴に基づくアクセスポリシー自動生成システム」
20031020 「プロセス実行履歴に基づくアクセスポリシー自動生成システム」20031020 「プロセス実行履歴に基づくアクセスポリシー自動生成システム」
20031020 「プロセス実行履歴に基づくアクセスポリシー自動生成システム」
 
20031030 「読み込み専用マウントによる改ざん防止Linuxサーバの構築」
20031030 「読み込み専用マウントによる改ざん防止Linuxサーバの構築」20031030 「読み込み専用マウントによる改ざん防止Linuxサーバの構築」
20031030 「読み込み専用マウントによる改ざん防止Linuxサーバの構築」
 
Linuxセキュリティ強化エッセンシャル
Linuxセキュリティ強化エッセンシャルLinuxセキュリティ強化エッセンシャル
Linuxセキュリティ強化エッセンシャル
 
闘うITエンジニアのためのLinuxセキュリティ講座
闘うITエンジニアのためのLinuxセキュリティ講座闘うITエンジニアのためのLinuxセキュリティ講座
闘うITエンジニアのためのLinuxセキュリティ講座
 
20 秋
20 秋20 秋
20 秋
 
Linux Security
Linux SecurityLinux Security
Linux Security
 
20 秋
20 秋20 秋
20 秋
 
20 秋
20 秋20 秋
20 秋
 
Sec014 ゼロデイ攻撃やラ
Sec014 ゼロデイ攻撃やラSec014 ゼロデイ攻撃やラ
Sec014 ゼロデイ攻撃やラ
 
CaitSith 新しいルールベースのカーネル内アクセス制御
CaitSith 新しいルールベースのカーネル内アクセス制御CaitSith 新しいルールベースのカーネル内アクセス制御
CaitSith 新しいルールベースのカーネル内アクセス制御
 
Active directory のセキュリティ対策 130119
Active directory のセキュリティ対策 130119Active directory のセキュリティ対策 130119
Active directory のセキュリティ対策 130119
 
[data security showcase Sapporo 2015] D22:今求められるセキュリティレベルとFireEye適応型防御 by ファイ...
[data security showcase Sapporo 2015] D22:今求められるセキュリティレベルとFireEye適応型防御 by ファイ...[data security showcase Sapporo 2015] D22:今求められるセキュリティレベルとFireEye適応型防御 by ファイ...
[data security showcase Sapporo 2015] D22:今求められるセキュリティレベルとFireEye適応型防御 by ファイ...
 
クラウド移行で解決されるセキュリティとリスク 公開用
クラウド移行で解決されるセキュリティとリスク 公開用クラウド移行で解決されるセキュリティとリスク 公開用
クラウド移行で解決されるセキュリティとリスク 公開用
 
Bitvisorをベースとした既存Windowsのドライバメモリ保護
Bitvisorをベースとした既存Windowsのドライバメモリ保護Bitvisorをベースとした既存Windowsのドライバメモリ保護
Bitvisorをベースとした既存Windowsのドライバメモリ保護
 
LSMの壁
LSMの壁LSMの壁
LSMの壁
 
Azure Key Vault
Azure Key VaultAzure Key Vault
Azure Key Vault
 
OSやアプリを問わず装着するだけで重要データを防御するセキュリティバリアデバイス by 戸田 賢二
OSやアプリを問わず装着するだけで重要データを防御するセキュリティバリアデバイス by 戸田 賢二OSやアプリを問わず装着するだけで重要データを防御するセキュリティバリアデバイス by 戸田 賢二
OSやアプリを問わず装着するだけで重要データを防御するセキュリティバリアデバイス by 戸田 賢二
 
プロセス実行履歴に基づくアクセスポリシー自動生成システム
プロセス実行履歴に基づくアクセスポリシー自動生成システムプロセス実行履歴に基づくアクセスポリシー自動生成システム
プロセス実行履歴に基づくアクセスポリシー自動生成システム
 

Recently uploaded

TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdfTSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdftaisei2219
 
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineerYuki Kikuchi
 
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察  ~Text-to-MusicとText-To-ImageかつImage-to-Music...モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察  ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...博三 太田
 
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)Hiroki Ichikura
 
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介Yuma Ohgami
 
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdfクラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdfFumieNakayama
 
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdfAWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdfFumieNakayama
 
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する       2024/04/19 の勉強会で発表されたものですSOPを理解する       2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものですiPride Co., Ltd.
 
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...Toru Tamaki
 
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)UEHARA, Tetsutaro
 
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案sugiuralab
 
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNetToru Tamaki
 
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A surveyToru Tamaki
 
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?akihisamiyanaga1
 

Recently uploaded (14)

TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdfTSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdf
 
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
 
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察  ~Text-to-MusicとText-To-ImageかつImage-to-Music...モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察  ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
 
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
 
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
 
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdfクラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
 
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdfAWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
 
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する       2024/04/19 の勉強会で発表されたものですSOPを理解する       2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものです
 
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
 
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
 
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
 
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet
 
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey
 
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
 

hbstudy# 28 SELinux HandsOn 公開版

  • 1. hbstudy#28 SELinux Hands-on 2011年度版 日本セキュアOSユーザ会 (ishikawa84g) 1
  • 2. 本資料について  本資料は下記資料をマージしたものを一部使用しています。  2008年10月29日「セキュアOS塾-01」内  第一部:今だから始める SELinux入門 講師: 中村雄一氏  http://goo.gl/WQLKT  http://goo.gl/fn30a  2009年5月28日「セキュアOS塾-03」内  SELinuxを使ってみる入門BoF  講師: 海外浩平氏  http://goo.gl/b8iAK  公開用に一部修正  10px の怪しい位置の文章はノート部を一部転記したもの 2
  • 3. セキュリティを決めるのは軍事力と政治ではない。 法律と裁判所でもない。 個々の人がどのように考え、行動するのかで決まる。 セキュリティ&プログラミングキャンプ2011 及び高度ポリテクセンター セミナー 資料より TOMOYO Linux が考えたセキュリティ 3
  • 4. 自己紹介  HN: ishikawa84g  Web: http://2done.org  所属  日本セキュアOSユーザ会 サーバ担当  検閲 4
  • 5. 本日のトピック 1. SELinux とは 2. SELinux の効能 3. 簡単 SELinux 活用法 4. 付き合い方とコマンドの活用 5. ハンズオン: WordPress の構築 5
  • 7. 1.1. 質問  あなたに守りたいものはありますか? High Key Baby Portrait By Wesley Oostvogels http://www.flickr.com/photos/higashitori/2700207474/ 7 Attribution-NoDerivs 2.0 Generic (CC BY-ND 2.0)
  • 8. 1.2. セキュリティとは  辞書的意味  安全。保安。防犯。防犯装置。担保。  なぜセキュリティが必要なのか  守るべき資産が存在する  資産に対する脅威が存在する  資産に対する脅威がない場合 → セキュリティ不要  資産価値よりもコストが大きい場合 → 通常不要  特殊な例: 健康のためなら死んでもいい  健康(生) < 死 8
  • 9. 1.3. 情報資産  情報資産 とは  個人情報  技術情報  財務情報  知的財産 など  これらに対する脅威  盗難,流出  情報システムの停止 など 9
  • 10. 1.4. 情報セキュリティ  機密性(Confidentiality)  権限のないユーザ、リソース、プロセスが保護された情 報(権限のない情報)にアクセスできないようにすること  完全性(Integrity)  システムの情報が、 故意または意図せず、変更されないよう保護すること  可用性(Availability)  権限のあるユーザが必要な時、いつでも必要なリソース にアクセスできること 情報セキュリティの3大要素(ISO/IEC27001より) その他、真正性,責任追跡性,否認防止性,信頼性を含めることも可能 10
  • 11. 1.5. アクセス制御  目的  正当な権限を持つユーザにリソースへのアクセスを許可  権限のないユーザのアクセスを排除  SELinux は機密性(アクセス制御)を担当する  任意アクセス制御(DAC)  UNIX系OSでサポートされている伝統的なアクセス制御方式  リソースに対する所有者権限による制御  root は神  強制アクセス制御(MAC)  SELinux 等が提供するアクセス制御方式  root であってもセキュリティポリシーの適用(回避不能)  リソースの所有者であってもアクセス権の変更不可 11 セキュリティ技術の分類 ISO/IEC15408の機能要件抜粋
  • 12. 1.6. DAC と MAC は競合するか?  答え  DAC と MAC は共存する  SELinux の場合、 1. DAC のアクセス権限を評価 2. MAC のアクセス権限を評価  例: /tmp/file.txt (0777) の場合  DAC のアクセス権限を評価 1. 許可されている場合 → 通過 2. 拒否されている場合 → 拒否  MAC のアクセス権限を評価 1. 許可されている場合 → 通過 2. 拒否されている場合 → 拒否 12
  • 13. 1.7. SELinux とは  いわゆるセキュアOS技術  アメリカ国家安全保障局(NSA)を中心に開発 公開: 2000年12月22日  http://www.nsa.gov/research/selinux/index.shtml LSM 統合: 2003年8月13日  機能:OSレベルでのアクセス制御機能の強化  プロセス、ユーザを必要最小限の権限で動作させる  rootでも逆らえないアクセス制御を提供する  当たり前になってきている技術  Linux Kernel 2.6.x 標準オプション  RHEL, Fedora でデフォルトON  最近は組込み向けでも注目!  SMACKもよろしく!  Linux Kernel におけるリファレンスモニタ の1つ 13
  • 14. 1.8. リファレンスモニタ  リファレンスモニタとは  セキュリティ分野では長い歴史のある概念  管理下のリソースに対するアクセス要求を許可するか否か といった意思決定を行うモジュール  セキュリティポリシーに基づいて意思決定をする  ユーザのシステムに対するリクエストを例外なく捕捉する SELinuxの場合 リファレンス セキュテリィ モニタ ポリシー 要求 システム read,write など 評価 判定 リソース ユーザ (システムコール) システム 14
  • 15. 1.9. セキュリティポリシー  リファレンスモニタが満たすべき3つ条件  回避不可能  改ざん不可能  検証可能  セキュリティポリシー  「誰が」「何に対して」「何をできる」のルールセット  明示的な許可のない組み合わせは全て禁止  ホワイトリスト方式  SELinux ではセキュリティコンテキストを利用する 15
  • 16. 1.10. セキュリティコンテキスト  セキュリティコンテキスト  セキュリティモデル上の識別子  誰(Subject)・何(Object)・何を(Action) の識別子  ファイル・プロセス・ユーザ・ソケットなど全てに付与 プロセス system_u:system_r:httpd_t:s0 ファイル system_u:object_r:shadow_t:s0 ユーザ staff_u:staff_r:staff_t:s0-s0:c0.c123 16
  • 17. 1.10. セキュリティコンテキスト system_u:object_r:shadow_t:s0 ユーザ属性 ロール属性 タイプ属性 機密ラベル  ユーザ属性  サブジェクトやオブジェクトに付ける SELinux の ユーザID  ロール属性  ユーザに割り当てる権限の範囲を定義したもの  ロールが不要なオブジェクトにはダミーロール(object_r)を付与  タイプ属性  SELinux がアクセス可否を判定する時に使用するセキュリティ属性  プロセスに付与すると : ドメイン  ファイルに付与すると : タイプ  機密ラベル  組織・役職などで分ける識別子 17
  • 19. 所謂、セキュアOSが必要とされた背景  政府, 金融の要請  TCSEC B1  Common Criteria(EAL4+以上)  LSPP  日本だと  政府機関の情報セキュリティ対策のための統一基準  http://goo.gl/3FKoD  金融機関等コンピュータシステムの安全対策基準  経済産業省システム管理基準追補版 参考:第03回まっちゃ445勉強会 「セキュアOSが進化した歴史を振り返って来年はチャレンジしよう」(田口さん) 19
  • 20. 参加特典  検閲 20
  • 21. SELinux が要求された背景  先の要件を満たすため  SELinux 出現以前はSolaris(Trusted Solaris)の独壇場  EAL の認証はとれても、LSPP でEAL4+以上の取得が できなかった。  SELinux のようなものを取り入れなければ 調達基準をまったく満たせなかった 21
  • 23. 2.1. 任意アクセス制御の課題  user, group, others に rwx パーミッションを設定、 ファイルアクセスを制御(DAC)  余計なアクセスを許しうる  othersパーミッションが立ってると誰でもアクセス可  ネットワークアクセスは制限されない  root は神  root を取られるとおしまい  root 昇格への抜け道  一般ユーザ権限からでも root を取られてしまう  setuid=0 のプログラムのセキュリティホールを突いて昇格  カーネルセキュリティホールを突いて昇格 23
  • 24. 2.2. 何が起こる?  不正侵入されてしまった時  バッファオーバーフロー攻撃  ツールをダウンロード・実行、他のサイトへの攻撃  など  不具合を突いたアプリケーションの権限で 任意の命令を実行可  一般ユーザ から root に昇格  コマンドインジェクション攻撃  など 24
  • 25. 2.2. 何が起こる?  ログインユーザの誤操作・悪意  誤操作(サーバ管理操作を root で実施)  rm –rf /  ウィルスを誤って実行  悪意  何かの脆弱性を利用した root への権限昇格  攻撃ツールダウンロードおよび実行 25
  • 28. 2.3. SELinux の機能  細かく厳密なアクセス制御  プロセスに余計なアクセスを許さない  ファイルパーミッション数百種類  ネットワークアクセス、プロセス間通信なども制限  抜け道がなく root であっても例外なく強制可能  よく SELinux が悪さをして~…と言われるが  ポリシーに基づいて制御をしているに過ぎない  なんでも防ぐわけじゃない。許可されていないことだけ。 28
  • 29. 2.4. SELinux の効能  その1:不正な攻撃があった場合の防御  攻撃者の動作を封じ込める  その2:内部犯行に対する防御  悪意あるユーザ、ユーザの操作ミスからの保護 現代のコンピューティング環境によって生じる脅威は、セキュアな オペレーティングシステムの存在無しには対応不可能である。 この事実を無視したあらゆるセキュリティ対策は 「砂上の楼閣」に等しい。 Loscocco, Smalley, Muckelbauer, Taylor, Turner, and Farrell 米国家安全保障局(NSA:National Security Agency) 29 「砂上に建てた楼閣は基礎がやわらかくて、てん覆するおそれがあることから、永続きしない物事のこと」(広辞苑)
  • 30. 2.5.1. 不正侵入対策(1)  プロセスに必要最小限の権限を割り当てる httpd samba DNS アクセス可 アクセス可 アクセス可 Webリソース 共有ファイル ゾーンファイル 権限外の アクセスは拒否 権限割り当て SELinux 30
  • 31. 2.5.2. 不正侵入対策(2)  攻撃者が取れる権限を限定  root 権限奪取に対応。パッチ当てる前でも有効 httpdのセキュリティホールを突いて乗っ取り httpd samba DNS アクセス可 アクセス可 アクセス可 Webリソース 共有ファイル ゾーンファイル httpdの権限しか取れない この権限では悪さは困難 31
  • 32. 2.5.3. 不正侵入対策(3)  実際はもっと早い段階で攻撃が止まる  「バッファオーバーフロー攻撃」に必要な権限が足りず 攻撃失敗  攻撃支援ツールが使えず攻撃失敗  SetUID の機能が利用できず攻撃失敗 32
  • 34. 2.6. ログインユーザのセキュリティ強化  ログインユーザに独自の権限を割り当て可能  「一般ユーザ」との違い  ネットワーク操作も制限  他ホストへの ping 送信禁止など  普通のパーミッションチェックとは独立している  others パーミッションが許可されていてもアクセスできない  root になっても権限はそのまま  活用例  管理者の分割  ログ管理者、Web管理者、メール管理者  Webブラウズ専用のユーザ 34
  • 35. 2.7. SELinux では防げないもの 1. 設定の不備 2. 与えられた権限内での破壊活動 3. 管理者や過大な権限を与えたユーザの犯行 4. 平易なパスワードを設定したことによるなりすまし 5. カーネルのセキュリティホール 6. DoS攻撃 7. XSS, CSRF, SQLインジェクションなどのWebからの攻撃 35
  • 36. 2.8.1. (応用)SELinux キオスクパソコン  Fedora 9 から入っている SELinux 応用機能  RHEL6 も対応  キオスクパソコン:  不特定多数の人が使える PC  主に Web 閲覧を目的とする  書店などでは専用プログラムによる検索機能を提供  例:ネットカフェやホテルロビーの PC  SELinux 安全なキオスク環境を構築可能  参考: http://goo.gl/XQrY6 36
  • 37. 2.8.2. 従来のキオスクパソコン ログイン・ユーザ (一般ユーザ権限) (1)root昇格攻撃で 書き込み可能 (3)任意のネット 読み書き実行可 ワーク通信可 (2)不正プログラ ホームディレクトリ システムファイル ムも実行可 キーロガーを仕込まれるかも! 踏み台に使われるかも!37
  • 38. 2.8.3. SELinux キオスク ログイン・ユーザ (SELinux独自権限) (1) rootに昇格して も書き込み不可 (3)http関連の 読み書き可 su, sudo 不可 通信のみ可能 実行不可 (2)不正プログラ システムファイル ホームディレクトリ ム実行不可 独自の権限割り当て SELinux ログインユーザ・ウィルスは悪さをできない 38
  • 39. 2.8.4. SELinuxキオスクの構築  構築はコマンド一発  # yum -y install xguest  RHEL6 の場合はインストール時、 GNOME を選択すると自動的にインストールされる。  らしい。(GUI使わないのでわかりません。。)  詳細  http://danwalsh.livejournal.com/13376.html 39
  • 40. 2.9. SELinuxの仕組み  2つの仕掛け  漏れの無いアクセス制御 ⇒ 強制アクセス制御  最小限の権限で動作させる⇒ TE(Type Enforcement) 40
  • 41. 2.10. 強制アクセス制御(MAC)  やっても良いことを定義し、 それに従った動作しかさせない。 任意アクセス制御のイメージ 強制アクセス制御適用後のイメージ http://tomoyo.sourceforge.jp/about.html 41
  • 42. 2.11.1. TE: Type Enforcement (1/3)  型(タイプ)の強制(エンフォースメント)  プロセス、ファイル、ソケット、etc... SELinux は、全ての資源をどれか1種類のタイプに当てはめる  “型にはまった” 動作だけを許可  ホワイトリスト方式 Apache サーバプロセス Jpeg画像 HTML文書 “file の read” httpd_t を許可 httpd_sys_content_t 42
  • 43. 2.11.2. TE: Type Enforcement (2/3)  セキュリティポリシーのルールの内容  「誰が(Subject)」「何に(Object)」「何をできるか(Action)」  例: Webサーバが、HTML文書を、読み込める allow httpd_t httpd_sys_content_t : file { read }; Webサーバの型(タイプ) HTML文書の型(タイプ) 43
  • 44. 2.11.3. TE: Type Enforcement (3/3) read mmap /lib 共有ライブラリ read lib_t PostgreSQL mmap サーバプロセス postgresql_t read HTML文書 read Apache write サーバプロセス httpd_sys_content_t httpd_t データベース read execute ファイル CGIプログラム postgresql_db_t 44 httpd_sys_script_t
  • 45. 3. 簡単 SELinux 活用法 45
  • 46. 3.1. SELinux が使えるディストリビューション  RHEL, CentOS, Fedora, Scientific Linux などで SELinux デフォルト有効  インストール作業は必要なし!  Gentoo・Debian・Ubuntu など  別途ポリシーファイルやユーティリティの導入が必要  本気でやるなら Fedora 一択!  漢なら黙って Rawhideとボスが言っていました。 46
  • 47. 3.2. SELinux の使い方  初期設定  初期からセキュリティポリシー、タイプが設定されている  標準添付のアプリが最小限の権限で動くよう設定済  トラブル対応が必要な場合  まれによくトラブルが生じるので、それを解決する  setroubleshoot の利用  boolean の設定  ラベルの設定  ポリシーの作成 47
  • 48. 3.3. SELinux 設定ファイル  /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing ← SELinux の初期状態 # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted ← SELinux のタイプ 48
  • 49. 3.3. SELINUX  SELinux の初期状態  システム起動時の SELinux の状態を定義  Enforcing 有効  Permissive 警告  Disabled 無効(コマンド変更不可)  Permissive モード  アクセス拒否のログのみを出力し実制御を行わないモード 49
  • 50. 3.3. SELINUXTYPE  SELinux のタイプ  Targeted 特定のサブジェクトに対してのみ制御を行う このあたりが制御対象: dhcpd, httpd, named, nscd, ntpd, portmap, snmpd, squid, syslogd それ以外は制限を受けない、unconfined_t で動作する  Strict Targeted よりもさらに厳密なモード unconfined_t を外したドSモード  MLS 上記にRBAC(ロールベースアクセス制御)を追加したもの ドMモード  Strictモード  RHEL5系の SELinux に存在したモード  現在は統合されモジュール化されている  RHEL6 以降で Strict モード相当にする場合はモジュールを外す  参考  http://danwalsh.livejournal.com/42394.html  http://2done.org/index.php?id=38 50
  • 51. 3.4. SELinux の状態を知る  getenforce  SELinux の現在の状態を表示する # getenforce Enforcing  sestatus [-v]  SELinux のステータスを表示する(-v で詳細表示) # sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux Current mode: enforcing Mode from config file: enforcing Policy version: 26 Policy from config file: targeted 51
  • 52. 3.5. ラベルを知る  プロセスのタイプの確認  ps –Z #ps –eZ LABEL PID TTY TIME CMD system_u:system_r:init_t:s0 1 ? 00:00:01 init system_u:system_r:httpd_t:s0 2655 ? 00:00:00 httpd  ファイルのタイプの確認  ls –Z # ls -Z / drwxr-xr-x root root system_u:object_r:bin_t:s0 bin drwxr-xr-x root root system_u:object_r:boot_t:s0 boot drwxr-xr-x root root system_u:object_r:device_t:s0 dev drwxr-xr-x root root system_u:object_r:etc_t:s0 etc 52
  • 53. 3.4. SELinuxによるトラブル  アプリケーションが動かない!  原因は?  セキュリティポリシーの不足やバグ  SELinux によって、アクセスが拒否されてしまう  SELinux を無効にする前に SELinux のせいか否か を切り分け、そして問題をスッキリ解決! 53
  • 54. 3.5. トラブル切り分け  2つの切り分け方法 1. Permissive モードでの動作確認 2. ログの確認 54
  • 55. 3.6. Permissiveモードでの動作確認  Permissive モードではアクセス制御を行わない  Permissive モードで動作すれば、 トラブルの原因が SELinux かどうか分かる  Permissive で操作をしてエラーがなければ SELinux が黒  setenforce  Permissive モードへの切り替え # setenforce 0  Enforcing モードへの切り替え # setenforce 1 ※コマンドでは Disabled に切り替えられない 55
  • 56. 3.7. ログの確認 後述! 56
  • 57. 3.8.1. setroubleshoot  トラブルの解決はどうすれば?  典型的なトラブルは setroubleshoot で解決可能  setroubleshoot?  SELinux の典型的トラブル事例を集約した DB を使い  SELinux のトラブルを通知してくれる  SELinux のトラブル解決方法を教えてくれる 57
  • 58. 3.8.2. setroubleshoot:トラブルの通知  SELinux が原因の問題が起こるとポップアップ 58
  • 60. 3.8.4. コマンドラインからの利用  setroubleshoot 動作時以下にログを出力する  /var/log/messages  ログの例 # grep sealert /var/log/messages Dec 13 00:29:23 angler setroubleshoot: SELinux is preventing /usr/sbin/httpd from getattr access on the file /var/www/html/index.html. For complete SELinux messages. run sealert -l 3d2b7a55-d060-4607-9b84-052cdd02e8c3  赤字部分を実行するとヒントを出力してくれる。(LANG=C 推奨)  実のところ…  よく嘘をつかれますが参考程度に使ってみてください。  が、Fedora 16 のはよさそう? 60
  • 61. 3.8.5. 実行例 [root@angler log]# sealert -l 3d2b7a55-d060-4607-9b84-052cdd02e8c3 SELinux is preventing /usr/sbin/httpd from getattr access on the ファイル /var/www/html/index.html. ***** プラグイン restorecon (99.5 confidence) が提案しています ************************* もし、ラベルを修正することになります。 /var/www/html/index.html のデフォルトラベルは httpd_sys_content_t のはずです。 そして、restorecon を実行することができます。 行ってください # /sbin/restorecon -v /var/www/html/index.html ***** プラグイン catchall (1.49 confidence) が提案しています *************************** もし、httpd に、 index.html file の getattr アクセスがデフォルトで許可されるべきです。 そして、これをバグをして報告すべきです。 このアクセスを許可するために、ローカルポリシーモジュールを生成することができます。 行ってください このアクセスを一時的に許可するには、以下を実行してください。: # grep httpd /var/log/audit/audit.log | audit2allow -M mypol 61
  • 62. 3.9. 設定を触りたい場合は・・・  セキュリティポリシを直接設定するのは難しいが、 ツールの整備がゆっくりと進んでいる  semanage  ポリシの細かい調整を行なえるCLI  SELinux Policy Generation Tool  設定が用意されていないアプリの設定をウィザードで作れる  SELinux Policy Editor (SEEdit): 開発停止中  設定書式を根本から単純にしている  自力で設定を作りたい場合に適する  組込みシステム向けポリシ記述に特に適している  http://seedit.sourceforge.net/ 62
  • 63. 3.10. トラブルを解決できない時は?  学ぶ  ポリシーソースを読む  RHEL6 のマニュアルや Fedora のマニュアルを読む  本家 ML を購読する。質問する。  結構教えてくれます、ただし英語  ユーザ会MLに質問する  フル日本語!  濃い人が気づいたら教えてくれます。  http://www.secureos.jp/ 63
  • 65. 4.1. ~ 4.3. 検閲 65
  • 66. 4.4. SELinux を有効にする  # vi /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. #SELINUX=disabled SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted 66
  • 67. 4.5. 再ラベル付けをする  SELinux 無効時作成されたファイル  ラベルがつかない  再ラベル付けをする必要がある  /.autorelabel という空ファイルを作成し、再起動 1. # touch /.autorelabel  ./autorelabel ではない 2. # shutdown –r 0  起動時にファイルシステム全体に再ラベル付けが行われる  超重要(失敗するとハンズオン終了)  再ラベル付け際は、必ず Permissive にする 67
  • 68. 4.5. 再ラベル付けをする  /etc/selinux/config を編集し、permissive にする  # sed -i "s/^¥(SELINUX=¥).*/¥1permissive/" /etc/selinux/config  # grep ^S /etc/selinux/config SELINUX=permissive SELINUXTYPE=targeted  # touch /.autorelabel  # shutdown -r 0  誤記があると、Disabled か カーネルパニックになるよ  しばらくすると起動する  これで再ラベル付けはOK 68
  • 69. 4.5. 再ラベル付けをする  起動を確認したら・・・  再度、設定を編集  # sed -i "s/^¥(SELINUX=¥).*/¥1enforcing/" /etc/selinux/config  # grep ^S /etc/selinux/config SELINUX=enforcing SELINUXTYPE=targeted  カレント状態を変更  # setenforce 1  状態を確認  # sestatus 69
  • 70. 4.6. ラベルを確認する  ファイルのラベルを確認する  ls -Z /  プロセスのラベルを確認する  ps axZ  自分のラベルを確認する  id  id -Z  今度は表示される!ようこそ SELinux! 70
  • 71. 4.7. 重要なパッケージ群  libselinux-utils  getenforce … SELinux の状態を表示  setenforce … SELinux の状態を変更  getsebool … Boolean の値を取得  policycoreutils  restorecon … 再ラベル付けを行う  run_init … 略  semodule … モジュールの設定を行う  sestatus … SELinux の状態を表示  setsebool … Boolean の値を設定 71
  • 72. 4.7. 重要なパッケージ群  policycoreutils-python  audit2allow … ログからポリシーを生成する  audit2why … アクセス拒否の理由を表示する  semanage … 各種設定を実施  setools-console  seinfo … SELinux policy query tool  sesearch … SELinux のポリシーを表示 72
  • 73. 4.8. SELinux の状態を知る  getenforce  SELinux の現在の状態を表示する # getenforce Permissive  sestatus [-v]  SELinux のステータスを表示する(-v で詳細表示) # sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux Current mode: enforcing Mode from config file: enforcing Policy version: 26 Policy from config file: targeted 73
  • 74. 4.9. SELinux の状態を変更  setenforce  SELinux の現在の一時的に状態を変更する  (Enforcing) # setenforce 0  (Permisssive) # setenforce 1  (Disabled) # 不可。Disabled ←遷移不可→ Enforcing/Permissive  sestatus # sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux Current mode: permissive ← コマンドで変更した値 Mode from config file: enforcing ← ファイルで設定した値 Policy version: 26 Policy from config file: targeted 74
  • 75. 4.10. ポリシーソース  SELinux 本体とポリシーは作成母体が違う  本体: NSA, Red Hat  ポリシー: Tresys, Red Hat  今回は、Fedora 16 のSRPM を利用  http://goo.gl/Cg1Dy  現在のポリシーは "Reference Policy" と呼ぶ  Tresysのはこっち: http://goo.gl/TV9Kf 75
  • 76. 4.10. ポリシーソース  良く見るディレクトリ  ./policy/modules/*  admin, app, kernel, roles, services, system  ファイルの種類  TE(Type Enforcement)  ポリシー本体  FC(File Context)  どのファイルにどのラベルを設定するかを記述  IF(Interface)  外部モジュールに公開するインタフェース(マクロ) 76
  • 77. 4.10. ポリシーソース(zabbix.pp)  zabbix のポリシーを読む  ./policy/modules/services/zabbix.* 77
  • 78. 4.11. ソースを読まずAllowを知る  sesearch  定義済みのポリシーを検索する  書式  sesearch [OPTIONS] RULE_TYPE [RULE_TYPE ...] [EXPESSION] [POLICY ...]  よく使うオプション  -A Allow を出力  -T ドメイン遷移を表示  -C Boolean を設定した場合のポリシーを出力  -s scontext を指定  -t tcontext を指定  -c class を指定 78
  • 79. 4.12. httpd_t 関連の Allow Rule  # sesearch -A –C | head -100  # sesearch -A -C -s httpd_t  # sesearch -A -C -s httpd_t -c file  # sesearch -A -C -s httpd_t -t httpd_sys_content_t -c file 79
  • 80. 4.13. Apache + SELinux  SELinux を有効にして、Apache を動作させる # yum -y install httpd # systemctl start httpd.service # ps axZ | grep httpd  デモ用ファイル取得(自分で作らない事!) # cd /tmp # wget http://2done.org/sample/1.html # ls -Z /tmp/1.html # mv /tmp/1.html /var/www/html アクセス! 403 # chown -R apache:apache /var/www # chmod 777 /var/www/html/1.html 80
  • 81. 4.14. Permissive モードでの動作  Permissive モードではアクセス制御を行わない  Permissive モードで動作させ、原因を探る  Permissive で操作をしてエラーがなければ SELinux が黒  動作確認の際には、必ず Permissive モードにする  意図しない動作が設定不備なのかSELinuxが原因なのかを切り分ける  正しく設定してから SELinux を疑う  Enforcing で動作が拒否された場合  処理はそこで停止する  Permissiveで動作させた場合  処理が停止することはない  拒否のログは出力する 81
  • 82. 4.15.1. ログの確認  既定のポリシーに反する操作はログとして記録される  /var/log/audit/audit.log に拒否ログが出力される  Enforcing で操作すると実際にアクセスが拒否される  audit.log は auditd が起動中のみ出力される  auditd 停止中は /var/log/messages に出力される 82
  • 83. 4.15.2. audit.log の確認  /var/log/audit/audit.log を確認する # grep denied /var/log/audit/audit.log  httpd_t が tmp_t の属性を取得しようとして失敗 type=AVC msg=audit(1323703762.864:94): avc: denied { getattr } for pid=1949 comm="httpd" path="/var/www/html/1.html" dev=sda3 ino=26080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file 83
  • 84. 4.15.3. audit.log の読み方 type=AVC msg=audit(1323703762.864:94): avc: denied { getattr } for pid=1949 comm="httpd" path="/var/www/html/1.html" dev=sda3 ino=26080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file 項目 説明 type 監査ログのタイプ(AVC: SELinuxアクセス拒否ログ) judge アクセス許可の種類(denied, granted) access vector 操作に使用しようとしたアクセスベクタ(read, write 等) pid プロセス番号:アクセス要求元プロセスのプロセス番号 comm アクセス要求元のコマンド名 name 対象ファイル名 dev 対象デバイス名 ino 対象ファイルのinode番号 scontext アクセスドメイン情報 tcontext リソースラベル tclass リソース種別 84
  • 85. 4.15.4. ログのココを見よう type=AVC msg=audit(1323703762.864:94): avc: denied { getattr } for pid=1949 comm="httpd" path="/var/www/html/1.html" dev=sda3 ino=26080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file  judge, access vector, scontext, tcontext, tclass あたりが重要 項目 値 説明 type AVC SELinux 関連のログ judge denied 拒否した access vector getattr 属性の取得 comm httpd アクセス要求元は httpd name 1.html 対象ファイルは 1.html ino 26080 ファイルの inode は 26080 scontext system_u:system_r:httpd_t:s0 アクセス要求元のタイプ tcontext system_u:object_r:tmp_t:s0 アクセス要求先のタイプ tclass file クラスタイプは file プロセス: httpd(httpd_t)の ファイル: 1.html (tmp_t)に対する属性取得要求を拒否した。 という意味になる。 85
  • 86. 4.15.5. ログの時間が見辛い!  正直、/var/log/audit/audit.log は見辛い  時刻が人間に分かり難い  ausearchコマンドでログを見る  #ausearch -m avc time->Tue Dec 13 00:29:22 2011 .... type=AVC msg=audit(1323703762.864:93): avc: denied { getattr } for pid=1949 comm="httpd" path="/var/www/html/index.html" dev=sda3 ino=26080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=file 86
  • 87. 4.16.1. ラベルを設定  FCファイル に定義がある場合  restorecon コマンドでラベルの再設定が行える  FCファイル に定義がない場合  chcon で一時的にラベルを設定する  semanage と restorecon でラベルを設定する  許可しようとしているポリシーは正しいか  理解するには多くの時間 SELinux に触れる必要がある 87
  • 88. 4.16.2. restorecon  既定値に従いファイルコンテキストを設定し直す  書式  restorecon [-o outfilename ] [-R] [-n] [-p] [-v] [-e directory ] pathname...  restorecon -f infilename [-o outfilename ] [-e directory ] [-R] [-n] [-p] [-v] [-F]  よく使うオプション  -R 再帰的にラベルを設定する  -F 強制的にラベルを再設定する  -v ラベルが再設定されたものを表示する  今回はFCファイル に定義がある  # restorecon -FRv /var/www/html 定義を知るには? 88
  • 89. 4.16.3. semanage  定義済みのラベルを付与するパスを表示/設定する  書式  semanage fcontext -{a|d|m|l|D|E} [-efnrst] file_spec  よく使うオプション  -a : 定義を追加  -m : 定義を修正  -d : 定義を削除  -t : タイプを指定 # semanage fcontext -l | grep /var/www 89
  • 90. [追記]どこにどのラベルを付けるか  どこにどのラベルを付けるか  どのラベルを付ければよいのか  これらを知るには多くの時間 SELinux と付き合う必要があります。  ドキュメントを読む  TE, FC をみる  職人の世界と言われても仕方ない  ここはどう頑張っても一概には言えません。  個々の事例でその場合は何と言えますが、こういう場合はこう! といいきることはできません。  この部分が SELinux を触る人が一番挫折していく箇所ではないかと思っ ています。  ラベルに対する混乱  付けて動いたものの本当にこれで良いのかを判断できない不安 90
  • 91. 4.17. トラブル解決フロー 1. SELinux が原因か / Enforcing でも動作するか  /var/log/audit/audit.log を確認  Permissive モードで動作するか 2. ポリシーを変更せずに対応する  適切なファイルコンテキストを付与する  boolean値を変更する 3. 最終手段ポリシーを作成する  自らポリシーを付与する 4. 本家MLに質問する(バグかも?) 91
  • 93. 5.1.1. UserDir の設定  UserDir を設定してみよう  # useradd angler  # vim /etc/httpd/conf/httpd.conf UserDir disabled ↓ UserDir public_html  # systemctl restart httpd.service  # su - angler  $ mkdir ~/public_html  $ cd ~/public_html  $ wget http://2done.org/sample/1.html  # restorecon -RF ~angler アクセス! 403 93
  • 94. 5.1.2. Permissive での動作 1. Permissive モードで動作を確認 アクセス! 403 2. まだ、403。  設定不備の可能性  UserDir を使用する時にはユーザディレクトリに o+x が必要  # chmod o+x ~angler アクセス! 94
  • 95. 5.1.3. Enforce での動作 3. Enforce モードで動作を確認 アクセス! 403 4. まだ、403。ログを確認。  # grep denied /var/log/audit/audit.log 95
  • 96. 5.1.4. ログの確認 avc: denied { getattr } for pid=1276 comm="httpd" path="/home/angler" dev=sda4 ino=139633 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir • httpd(httpd_t) が • /home/angler (user_home_dir_t)に対して • 属性取得(getattr)することを拒否
  • 97. 5.1.5. ポリシーの調査 • httpd(httpd_t) が • /home/angler (user_home_dir_t)に対して • 属性取得(getattr)することを拒否 1. これを許可する定義がないか確認  # sesearch -A -C -s httpd_t -t user_home_dir_t -c dir Found 2 semantic av rules: DT allow httpd_t user_home_dir_t : dir { getattr search open } ; [ httpd_enable_homedirs ] DT allow httpd_t user_home_dir_t : dir { ioctl read getattr lock search open } ; [ httpd_read_user_content ]  定義自体はありそう  ただし、[BOOLEAN] がデフォルト無効(DT)になっている  Boolean 値を有効にすることでアクセスが可能になる  Boolean?
  • 98. 5.2.1. Boolean値  Boolean値(条件変数)  セキュリティポリシーの一部をBooleanと呼ばれる条件変数の値に 応じて動的に有効化/無効化するための機能  Boolean 値 が True の場合のみ追加のアクセス許可を与える  こんなイメージ if (boolenA) { ... 許可ルール ... } 98
  • 99. 5.2.3. Boolean値の確認と設定  Boolean値の確認  コマンド: getsebool  書式: getsebool [-a] [boolean]  Boolean値の設定  コマンド: setsebool  書式: setsebool [ -P ] boolean value | bool1=val1 bool2=val2 ... ※ 設定は一時的なものとなり再起動後は初期化される 永続的に設定したい場合は P オプション を付与する 99
  • 100. 5.2.4. Boolean値の意味を知る  それが何かをどうやって知るか  ポリシーソースを見る  sesearch を使用する  Web で検索  どうやってあたりをつけるか  名前から判断  setroubleshoot に頼る  その他、長年の勘と経験と。。。  RHEL6 の SELinux マニュアルには各Booleanの意味が書か れているのでオススメ 100
  • 101. 5.1.6. Boolean を設定をする  今回はBoolean <httpd_enable_homedirs>を設定 1. 状態を取得  # getsebool httpd_enable_homedirs httpd_enable_homedirs --> off 2. 状態を変更する  # setsebool [-P] httpd_enable_homedirs 1 3. 状態を取得  # getsebool httpd_enable_homedirs httpd_enable_homedirs --> on 101
  • 102. 5.3.1. DocumentRoot変更  /www をDocumentRoot に変更する 1. # mkdir /www 2. # chown apache:apache /www 3. # vim /etc/httpd/conf/httpd.conf DocumentRoot "/www" 4. (F16) # systemctl restart httpd.service (C6) # run_init /etc/init.d/httpd restart 5. アクセス!  デフォルトトップページが表示される  index.html へのアクセス拒否 102
  • 103. 5.3.2. Permissive モード  Permissive モードで動作させる  # setenforce 0  ログを確認する  # grep denied /var/log/audit/audit.log  再ラベル付けをする  # restorecon -RFv /www  # setenforce 1 403 定義がないので restorecon ではダメ アクセス! 定義を作る 103
  • 104. 5.3.3. 解決方法は? 1. httpd_t がアクセスできるラベルを付与する  推奨  5.4. で解説 2. オリジナルポリシーを作る  httpd_t が default_t にアクセスすることを許可  5.5. で解説 104
  • 105. 5.4. ラベルを付与する  定義されたラベルが存在する  httpd_sys_content_t を設定  # semanage fcontext -a -t httpd_sys_content_t "/www(/.*)?"  # restorecon -RFv /www アクセス! 105
  • 106. 5.5.1. オリジナルポリシーを作る  正攻法は自分で TE と FC を作る  IF はとりあえず無くてもOK  面倒な場合はログからポリシーを自動生成する  下準備 1. 5.4.で定義したラベル削除する # semanage fcontext -d -t httpd_sys_content_t "/www(/.*)?" 2. 再ラベル付け # restorecon -RFv /www 3. audit.log の初期化 # echo -n > /var/log/audit/audit.log # systemctl restart auditd.service 106
  • 107. 5.5.2. audit2allow  audit2allow  ログファイルからルールを生成する  書式  audit2allow [options]  よく使うオプション  -a auditログとmessageログを入力とする  -d dmesgコマンドの出力を入力とする  -i input ファイルを指定  -m [module] 指定したモジュールを生成  -M モジュールをバイナリで生成  -R インストール済みマクロを使用してポリシーを生成  -v 詳細出力 107
  • 108. 5.5.2. オリジナルポリシーを作る  # audit2allow -R -i /var/log/audit/audit.log -m local ¥ > local.te  または  # cat /var/log/audit/audit.log | ¥ audit2allow -R -m local > local.te  重要  この時、不要な定義がある場合は手動で抹消する  コンパイル # make -f /usr/share/selinux/devel/Makefile 108
  • 109. 5.5.3. semodule  semodule  SELinux のモジュール管理ツール  書式  semodule [options]... MODE [MODES]...  よく使うオプション  -l ロード済みのモジュールリストを出力  -i [module] モジュールを適用する  -r [module] ロード済みのモジュールを取り除く  -R ロード済みのモジュールを再ロードする  -d ロード済みのモジュールを無効化する  -e ロード済みのモジュールを有効化する 109
  • 110. 5.5.4. モジュールを組み込む  作成したモジュールを組み込む  # semodule –i local.pp  # semodule -l | grep local  # semodule -R 110
  • 111. 6. 実践 SELinux ~CMSの構築~ 111
  • 112. 6.1. 環境  Fedora 16  Apache 2.2.x  PHP 5.3.x  MySQL 5.5.x  WordPress 3.3  http://ja.wordpress.org/  今回は (説明が面倒なので)DocumentRoot に直接インストールをする 112
  • 113. 6.3. WordPress 展開と権限付与  WordPress を展開し、権限を付与する # cd /var/www/html # wget http://ja.wordpress.org/wordpress-3.3-ja.zip # unzip wordpress-3.3-ja.zip # rm -f wordpress-3.3-ja.zip # mv wordpress/* . # rmdir wordpress # chown -R apache:apache /var/www/html # restorecon -RFv /var/www/html 113
  • 114. 6.4. /etc/my.cnf 設定 [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 character-set-server=utf8 [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid character-set-server=utf8 [mysql] default-character-set=utf8 [mysqldump] default-character-set=utf8 [client] default-character-set=utf8 114
  • 115. 6.5. MySQL 設定 # service mysqld start # mysql -u root mysql> create database wordpress; mysql> grant all privileges on wordpress.* to wordpress@localhost identified by 'PASSW0RD'; mysql> exit ※ ID/PASSWD は適切に設定する 基盤が脆弱であればシステム全体が脆弱になってしまう 115
  • 116. 6.6. サービスの起動と自動設定  Apache  # systemctl start httpd.service  # systemctl enable httpd.service  MySQL  # systemctl start mysqld.service  # systemctl enable mysqld.service 116
  • 117. (個人的な考え)  インストール時は Permissive する  インストールに必要な権限と運用に必要な権限は異なる  不要なファイルへの書き込みなどが発生する  共通設定ファイルの作成  ./install などのファイル削除  以降、WordPress のインストールを行うが Permissive でインストールを行う  # setenforce 0 117
  • 118. 6.7. WordPress のインストール 1. http://127.0.0.1/wp-admin/install.php を表示 2. 「設定ファイルを作成する」を押下 3. 「次に進みましょう !」を押下 4. データベース設定をし、「作成する」を押下 ※ ここで SELinux のエラーとなるがスルー 5. 「インストール実行」を押下 6. サイト設定をし「 WordPress をインストール」を押下 ※ ここでも多量のエラーが発生する 7. 実際にログインをしてみる 118
  • 119. 6.8. 下準備とログ出力 1. インストール時の audit.log 削除 # echo -n > /var/log/audit/audit.log 2. システム全体のラベルを再設定 # touch /.autorelabel # shutdown -r now 3. 再度 Permissive モードにし WordPress を一通り操作する # setenforce 0 119
  • 120. 6.9. 俺たちの戦いはまだまだこれからだ  さぁ、あとは頑張って解くんだ  ヒント: https_sys_rw_content_t 120
  • 121. chcon  定義済みのラベルを"一時的"に付与する  書式  chcon [OPTION]... CONTEXT FILE...  chcon [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...  chcon [OPTION]... --reference=RFILE FILE...  よく使うオプション  -R : 再帰的にラベルを付与  -u : SELinux USER を設定  -r : SELinux role を設定  -t : File Context を設定  -l : range を設定 注意: chcon で設定したラベルは restorecon などで初期化される 121