2015年6月22日月曜日

Red Hat Enterprise Linuxのセキュリティ対応に OpenSCAPを活用しよう

https://oss.sios.com/redhat-ch/blog/openscap_intro に投稿したものの再掲です。
「システムに既知の脆弱性や問題のある設定がないかチェックをしよう」というとき、あなたならどうしますか? 本稿ではセキュリティ対応の自動化のためRHELに最近導入されたOpenSCAPおよびSCAP Security Guideを紹介します。

セキュリティ対応、どうしてますか?

「システムに既知の脆弱性や問題のある設定がないかチェックをしよう」というとき、あなたならどうしますか? 緊急の対策については、文書をもとに手作業で確認するケースも多いかと思います。しかし組織内での恒常的なセキュリティ対応のためには、自動化が必要になります。
本稿ではセキュリティ対応の自動化のためRHELに導入されたソフトウェアを紹介します。

SCAP(Security Content Automation Protocol)

アメリカ政府ではあらゆるシステムにセキュリティ対応(発見・対策)をおこなう必要があり、これを自動化・定型化するための仕組みが作られてきました。SCAPはNIST(National Institute of Standards and Technology)により開発された、情報セキュリティ対策の自動化と標準化のための規格です。前提となる各種のID策定、セキュリティ上の問題の検出と対策などを記述するフォーマットなどを規定しています。
SCAPの一環として、製品についてのID(CPE)、 脆弱性についてのID(CVE)、設定についてのID(CCE), 脆弱性の深刻さのスコアづけ(CVSS)、自動チェックのための言語(OVAL)、チェックリストのフォーマット(XCCDF)などが標準化されています。脆弱性情報などでCVEやCVSSの名前を見たことがある方も多いのではないかと思います。
OVAL規格では各種のOSやアプリケーションに対応しており、テスト項目を「ファイルや設定、パッケージなどの検査項目」と「どういう状態になっているか」の組み合わせで記載して専用の処理系によって自動的に検査することができるようになっています。
SCAPについて詳しくはIPAのSCAP概説ページをごらんください。関連する規格についても紹介がされています。Red Hat製品についても従来からアップデート情報をOVALフォーマットで提供しています
この記事では、このSCAPに関連した以下の3つのソフトウェアを紹介します。
  • XCCDFまたはOVAL形式のファイルを処理するOpenSCAP
  • XCCDFフォーマットで作成された包括的なチェックリストであるSCAP Security Guide
  • XCCDFフォーマットのチェックリストを必要にあわせてカスタマイズするSCAP Workbench

OpenSCAP

OpenSCAPは、SCAPを実装しているオープンソースのプロジェクトで、OpenSCAP 1.0.8 でSCAP 1.2の認証をNISTから受けています。OpenSCAPはOVALまたはXCCDFで記述されたチェックリストと組織にあわせたカスタマイズにしたがって、実際のシステムを検証してレポートを作成します。一部の項目については自動的な対策も可能です。
OpenSCAPの利用方法のイメージはドキュメントに、DISAが公開しているガイドを利用してチェックを行う例などがあります。OpenSCAPはRed Hat Enterprise Linux の5.7および6.0から同梱されています。

report_sample.png
OpenSCAPで出力されるレポート例

SCAP Security Guide

SCAP Security Guide は、Fedora, Java, Red Hat Enterprise Linux 5, 6, 7, OpenStack, JBoss Enterprise Application Server 5, JBossFuse6 のセキュリティについてついてのガイドと関連する検証メカニズムをXCCDF形式で提供しているプロジェクトです。

SCAP Security Guide内には「/var/logを別のパーティションにする」といった多数のチェック項目と説明、関連するIDや規格文書などへのリファレンス、自動でチェックや修正が可能なものについてはその手順が含まれます。これらの項目から組織のポリシーにあわせて選択してカスタマイズしたチェックリストを作ります。OpenSCAPはこのチェックリストを自動でチェックしてレポートを生成します。オプションによっては自動的な修正もおこないます。
openscap.png

このプロジェクトは2011年にRHEL6についての高品質なセキュリティガイドを作成するためのNSAとRed Hatの共同作業からはじまり、その後カバーする範囲や参加者を増やしつつ成長しています。RHEL 7.1からSCAP Security Guideが同梱されるようになりましたので「SCAP Security GuideをSCAP WorkbenchでカスタマイズしたチェックリストをOpenSCAPで自動的に確認し、レポートを作成する」プロセスの全体をRed Hatがサポートできるようになりました。

SCAP Workbench

SCAP WorkbenchはXCCDF内でのチェック項目を組織にあわせて選択・調整したプロファイルを作り、ローカルまたはリモートの環境をチェックする作業を簡単にするためのGUIツールです。RHEL 7.1からはサポート対象として同梱されています。

Screenshot_rhel7.1_2015-06-15_21:39:31.png
Screenshot_rhel7.1_2015-06-15_21:41:19.png

Red Hat Satelliteからの管理

Red Hat Satelliteから管理対象になっている複数台のRHELに対してOpenSCAPを実行してレポートを蓄積します。監査結果の概要や履歴を確認したり、同一のスキャンを行って前回との差分を確認するなどの機能が提供されます。以下はRed Hat Satellite 5.7でのスキャン結果概要画面の例です。

Red_Hat_Satellite_-_システム_-_システム_-_監査_-_スキャンの一覧_-_2015-06-15_22.01.17.png

関連資料


RHEL 7.0時点のもので現在とは多少見た目がちがいますが紹介ビデオがあります

Red Hat Software Collections 2.0 とは

RHEL上で新しいソフトウェアを利用したい!

Red Hat Enterprise Linux は初期バージョンでリリースしたソフトウェアについて10年間基本的に同じバージョンを維持します。
これは多くの場合に企業ユーザにとってうれしいポリシーですが、新しいソフトウェアを利用したい時もあります。

特にupstreamの開発が早いソフトウェアは3年もすると時代遅れになり、5年も前のバージョンだとあれもこれも使えないという状態になってしまいます。

開発ツールについても新しい言語仕様への対応、新CPUの命令セットへ対応、最適化の強化などで新しいバージョンを利用したいという声がありました。

Red Hat Software Collections の登場

これらの問題に対する解として、Red HatではRed Hat Software Collections を提供しています。
これは今までのadd-on製品などと異なり、以下のような特徴があります。

    Red Hat Enterprise Linux のライフサイクルと独立して、新しいソフトウェアコンポーネントを追加・リタイアさせます。
        具体的にはRHEL の10年間のサポートライフサイクルに対してSoftware Collectionsは一部の例外を除いて3年間のライフサイクルとなります。
    Red Hat Enterprise Linux に同梱されているソフトウェアと競合しないよう工夫されています。
        たとえば Pythonのバージョン3.3 をRHEL 6に導入しようとすると、多数の競合が発生してしまいます。
        Software Collectionsでは、通常とは異なるディレクトリにインストールする仕組みを標準化することで、競合を防ぎつつ便利に利用できるようにしています。

Red Hat Software Collections 2.0

Red Hat Software Collections 2.0 (以下RHSCL 2.0)は 2015年6月に出荷されました。
Red Hat Enterprise Linux 6 および 7 で利用できるソフトウェアを提供しています。
UpstreamにあたるSoftware Collectionsプロジェクト https://www.softwarecollections.org/en/ では、FedoraやCentOSなどで利用できるリポジトリが公開されています。自作のコレクションを追加することもできます。

RHSCL 2.0に含まれる主要なソフトウェアを紹介します。

言語処理系:

    gcc, gdbなどCやfortranの開発環境を含むRed Hat Developer Toolset
    Perl 5.16.3, 5.20.1
    PHP 5.4.40, 5.5.21, 5.6.5
    Python 2.7.8, 3.3.2, 3.4.2
    Ruby 1.9.3, 2.0.0, 2.2.2
    V8 3.14.5.10

Webサーバ:

    nginx 1.6.2
    Apache httpd 2.4.12
    Ruby on Rails 4.0.2, 4.1.5
    Node.js 0.10
    Passenger 4.0.50

データベース:

    MariaDB 5.5.37, 10.0.17
    MongoDB 2.4.9, 2.6.9
    MySQL 5.5.37, 5.6.24
    PostgreSQL 9.2.8, 9.4.1

その他にもGitなどの開発者むけツールが含まれています。

Red Hat Software Collections を使ってみよう

利用の前提

RHSCLは特に追加の費用はかかりません。通常のRed Hat Enterprise Linux 6 または7 を導入されていると、RHSCLを入手することができます。レッドハットによる直接のサポートを受けている場合はサポート対象でもあります。OEM版をご利用の場合は、OEM各社によりサポートポリシーがかわりますのでご注意ください。

購入時期によって、利用できるよう設定されていない場合があります。 詳細についてはこちらをご確認ください。

リポジトリの登録と導入


Software CollectionsはRed HatのカスタマーポータルにRHELを直接接続するか、Red Hat Satellite経由で接続することで利用できます。カスタマーポータルから個別のパッケージをダウンロードすることはできませんのでご注意ください。

リポジトリを登録します。RHSCLの1.xと2.0は同じリポジトリを利用しますので、1.xを利用していた方は登録しなおす必要はありません。

# subscription-manager repos --enable rhel-server-rhscl-7-rpms 
# yum install python33


RHSCLを導入すると、sclコマンドにより環境を切りかえられるようになります。

$ scl enable python33 bash $ python Python 3.3.2 (default, Mar 20 2014, 18:55:17) [GCC 4.8.2 20140120 (Red Hat 4.8.2-16)] on linux 
Type "help", "copyright", "credits" or "license" for more information. 
>>> 

Red Hat Software Collections のサポート


RHSCLのサポート期間はRHELのサポート期間と独立しています。RHEL 6やRHEL 7のサポートが続いていても RHSCLのサポートは独立して切れてしまう点に注意が必要です。

RHSCL 2.0 には同じソフトウェアの複数バージョンが含まれています。この中には RHSCL 1.xからひきつづいて提供しされているものが存在しています。

登場時期によりサポート終了期間がことなります。基本的にはRHSCL 1.xで登場したものは2016年10月まで、RHSCL 2.0で登場したものは 2018年4月までというように各コンポーネントごとにリリースから3年間(Developer Toolsetは2年間)のサポート期間が設定されています。そしてRHSCLの1.xと2.xでリポジトリは同一です。

各コンポーネントについてサポート期間一覧が案内されています。


2015年5月19日火曜日

RHEL7でとったスナップショットにroot fsをロールバックするメモ

snapperで作ったスナップショットに戻したい

なにもなかったことにしたいとき、あります。
というわけでsnapperで取得したsnapshotの差分をとって…… というのではなく、まるごとそのまま前の状態にもどしましょう。

rootfs切り替え時の注意

RHELだと/bootはLVMで管理しない生 パーティションのため、この手法でロールバックされません。「カーネルやinitramfsが/bootに入っているが/lib/modules以下にカー ネルモジュールが入っていない」という状態になる可能性があります。root fsのmountまではinitramfsでできているはずなのでなんとかkernelパッケージを再インストールしてしのぎます。
snapperのメタデータは対象のディレクトリ直下にある .snapshots ディレクトリに作成されます。この情報も古い状態にもどってしまいますので、必要に応じてバックアップ&リストアするのがよいです。
snapperはスナップショットのlv名が衝突すると適当に数を大きくして競合しないように命名してくれるので、既にあるスナップショットを snapperが管理してくれなくなる(=古いスナップショットが消えないので容量の無駄になる)以外には大きな実害はありません。

snapperによって作成されるLVの属性を確認する

まずはsnapperが作成するLVの状態を確認します。

 [root@localhost ~]# lvs
  LV              VG   Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00          rhel twi-aotz-- 12.00g               10.85  18.55                           
  root            rhel Vwi-aotz-- 12.00g pool00        10.02                                  
  root-snapshot10 rhel Vri---tz-k 12.00g pool00 root                                          
  root-snapshot11 rhel Vri---tz-k 12.00g pool00 root                                          
  root-snapshot12 rhel Vri---tz-k 12.00g pool00 root                                          
  root-snapshot13 rhel Vri---tz-k 12.00g pool00 root
Vri—-tz-k というのが属性で、元々のroot fsであるVwi-aotz— というのとはちょっと違いますね。
man lvs 内に各フラグの意味が書いてあります。関係するところだけひっぱってきます

              1  Volume  type:  thin (V)olume
              2  Permissions: (w)riteable, (r)ead-only
              3  Allocation policy:  (i)nherited
              4  fixed (m)inor ← なし
              5  State:  (a)ctive
              6  device (o)pen
              7  Target type: (t)hin; whereas snapshots of thin volumes using the new thin provisioning driver appear as (t).
              8  Newly-allocated data blocks are overwritten with blocks of (z)eroes before use.
              9  Volume Health: ← なし
              10 s(k)ip activation: this volume is flagged to be skipped during activation.
rootと、root-snapshot10 を比べてみると「read-onlyでactiveではなく、openされておらず、activationのときにskipされる」というのが違いです。
つまりこれを普通のボリュームにするには、「writableに変更し、activationのときにスキップしないように変更する」必要があります。起動時に自動的にLVをactivationする処理により、activeとopenは勝手に設定されます。
普段はsnapshotのデバイスがずらずらと並んでも同じUUIDを持っていたりしてxfsの誤動作の元になったりするくらいでいいことがないのでskipにしてあります。

dracutによるinitramfsで、root fsをmountする前に停止する

「じゃあ一旦umountしてからlvchangeでフラグを変更して、lvrenameすればいいんだな……」となるわけですが、 root fsが含まれているので「一旦umountして」という処理がちょっと面倒になります。
RHELの6から採用されているdracutでは、 カーネルのコマンドラインオプションに rd.break=pre-mount とつけることでroot fsをマウントする直前のところで停止してshellに落ちてくれる便利機能がついています。(RHEL6だとすこしオプション名がちがってrdbreak=…です)
man dracut.cmdline より

       rd.break={cmdline|pre-udev|pre-trigger|initqueue|pre-mount|mount|pre-pivot|cleanup}
           drop to a shell on defined breakpoint
再起動して、grubのメニューから rd.break=pre-mount というオプションを一時的に追加することで、initramfsだけがマウントされている状態のシェルが起動します。
この環境ではlvchangeなどのコマンドはlvmの対話シェル内から打ちこみます。

lvmでの作業

デフォルトではinitramfs内でLVMのメタデータを変更しない設定になっているので、lvmでの作業前に /etc/lvm/lvm.conf 内の locking_mode = 4 となっている行を1に変更します。
lvmの中で以下のような変更をおこないます。今回はsnapshot10の状態に戻してみます。

lvm>  lvrename rhel/root root-original

lvm> lvrename rhel/root-snapshot10 root



lvm> lvchange -k n rhel/root   ← s(k)ip をはずす

lvm> lvchange -p rw rhel/root    ← readwriteができるようにする



lvm> lvchange -k y rhel/root-original  ← s(k)ipするようにする

lvm> lvchange -p ro rhel/root-original ← read only にする

lvm> exit
しくじると再起動するときにroot fsのmountに失敗してしまうので、随時lvsなどで思った通り操作できているか確認しましょう。
このあと reboot コマンドで再起動します。

再起動後


[root@localhost ~]# snapper create

[root@localhost ~]# lvs
  LV              VG   Attr       LSize  Pool   Origin        Data%  Meta%  Move Log Cpy%Sync Convert
  pool00          rhel twi-aotz-- 12.00g                      11.15  24.41                           
  root            rhel Vwi-aotz-- 12.00g pool00 root-original 10.00                                  
  root-original   rhel Vwi---tz-k 12.00g pool00                                                      
  root-snapshot11 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot12 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot13 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot14 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot15 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot16 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot17 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot18 rhel Vri---tz-k 12.00g pool00 root-original                                        
  root-snapshot19 rhel Vri---tz-k 12.00g pool00 root                                                 
  root-snapshot9  rhel Vri---tz-k 12.00g pool00 root-original                                        
  swap            rhel -wi-ao----  2.00g               


[root@localhost ~]# snapper list
Type   | #  | Pre # | Date                     | User | Cleanup | Description | Userdata
-------+----+-------+--------------------------+------+---------+-------------+---------
single | 0  |       |                          | root |         | current     |         
single | 9  |       | Mon May 18 18:15:10 2015 | root |         |             |         
single | 19 |       | Tue May 19 18:48:48 2015 | root |         |             |
snapperはきれいさっぱり10から18までのことは忘れています。記録がないから当然ですね。

元LVの削除

もろもろ試して、うまいこと古い状態に戻せて いることが確認できたら、元のLVをlvremoveで削除します。

[root@localhost ~]# lvremove rhel/root-original
  Logical volume "root-original" successfully removed
[root@localhost ~]# lvs
  LV              VG   Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00          rhel twi-aotz-- 12.00g               11.07  22.66                           
  root            rhel Vwi-aotz-- 12.00g pool00        10.00                                  
  root-snapshot11 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot12 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot13 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot14 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot15 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot16 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot17 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot18 rhel Vri---tz-k 12.00g pool00                                               
  root-snapshot19 rhel Vri---tz-k 12.00g pool00 root                                          
  root-snapshot9  rhel Vri---tz-k 12.00g pool00                                               
  swap            rhel -wi-ao----  2.00g
Originの表記が消えたりしていますがやはりあまり実害はないので気にしない方向で… 。

2015年5月18日月曜日

RHEL7でスナップショットとり放題設定をためしたメモ

インストール

RHEL7のインストーラではインストール対象としてLVM thinprovisioningが選択できるようになっている。ここを選択して、適当に空きが残るように容量を設定しておく。

状態を確認

操作する前に現在の状態を確認

[root@localhost log]# lsblk
NAME                    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                       8:0    0   20G  0 disk 
├─sda1                    8:1    0  500M  0 part /boot
└─sda2                    8:2    0 16.4G  0 part 
  ├─rhel-swap           253:0    0    2G  0 lvm  [SWAP]
  ├─rhel-pool00_tmeta   253:1    0   12M  0 lvm  
  │ └─rhel-pool00-tpool 253:3    0   12G  0 lvm  
  │   ├─rhel-root       253:4    0   12G  0 lvm  /
  │   └─rhel-pool00     253:5    0   12G  0 lvm  
  └─rhel-pool00_tdata   253:2    0   12G  0 lvm  
    └─rhel-pool00-tpool 253:3    0   12G  0 lvm  
      ├─rhel-root       253:4    0   12G  0 lvm  /
      └─rhel-pool00     253:5    0   12G  0 lvm  
sr0                      11:0    1  3.6G  0 rom  

[root@localhost log]# lvs
  LV     VG   Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00 rhel twi-aotz-- 12.00g               9.38   5.18                            
  root   rhel Vwi-aotz-- 12.00g pool00        9.38                                   
  swap   rhel -wi-ao----  2.00g
lsblkに同じエントリが2回でているのが不安ですが、tmetaの方はメタデータ、tdataの方は実際のデータがはいっています。
12GBのpool00の下に12GBということになっているrootが含まれている状態。
プールの詳細
[root@localhost log]# lvdisplay /dev/rhel/pool00 
  --- Logical volume ---
  LV Name                pool00
  VG Name                rhel
  LV UUID                vuooGK-VHow-JfAo-cPQb-Egf1-fCk4-qRpLqK
  LV Write Access        read/write
  LV Creation host, time localhost, 2015-05-15 19:15:03 +0900
  LV Pool metadata       pool00_tmeta
  LV Pool data           pool00_tdata
  LV Status              available
  # open                 2
  LV Size                12.00 GiB
  Allocated pool data    9.38%
  Allocated metadata     5.18%
  Current LE             3072
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:3
これで、lvmにより任意のタイミングでsnapshotをとり放題です。以下のようなコマンドでスナップショットを作成できます。

lvcreate --permission r --snapshot --name snapshot  rhel/root

snapper設定の作成

さて、snapshot作り放題、なのはいいですがlvcreateで都度作成するのはしんどいです。というわけでRHEL7には、SUSE出身のsnapperが含まれています。SUSEだとYaSTと連携してGUIまでありますが、RHELだとコマンドラインのみ。しかしとても便利です。
まずは設定を作成します。デフォルトだと “root” という名前の設定で、それ以外だと-c “設定名” みたいなオプションをつけて実行することでどこの操作をしているか指定します。
[root@localhost ~]# snapper create-config -f 'lvm(xfs)' /
このコマンドで /etc/snapper/configs/rootに設定本体が作成され、
さらに設定一覧が /etc/sysconfig/snapper にあるのでここに設定名が追加されます。
今の設定一覧を確認する。”root”設定があるのがわかります。
[root@localhost log]# snapper list-configs
Config | Subvolume
-------+----------
root   | /

snapshot作成

ここまで準備をするとスナップショットの作成は簡単。snapper createコマンドだけです。

[root@localhost log]# snapper create
様子を確認します。

[root@localhost log]# snapper list
Type   | # | Pre # | Date                     | User | Cleanup | Description | Userdata
-------+---+-------+--------------------------+------+---------+-------------+---------
single | 0 |       |                          | root |         | current     |         
single | 9 |       | Mon May 18 18:15:10 2015 | root |         |             |         

[root@localhost log]# lvs
  LV             VG   Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00         rhel twi-aotz-- 12.00g               10.00  5.73                            
  root           rhel Vwi-aotz-- 12.00g pool00        10.00                                  
  root-snapshot9 rhel Vri---tz-k 12.00g pool00 root                                          
  swap           rhel -wi-ao----  2.00g
root-snapshot9 という名前のスナップショットが作成されています。

スナップショットのマウント

以下のようにスナップショット番号を指定して、readonlyでmountすることができます。
.snapshotディレクトリ以下に適当にmountされます。

[root@localhost ~]# snapper mount 10 

[root@localhost ~]# df

Filesystem                        1K-blocks    Used Available Use% Mounted on
/dev/mapper/rhel-root              12571648 1226516  11345132  10% /
devtmpfs                            1931348       0   1931348   0% /dev
tmpfs                               1941204       0   1941204   0% /dev/shm
tmpfs                               1941204    8580   1932624   1% /run
tmpfs                               1941204       0   1941204   0% /sys/fs/cgroup
/dev/sda1                            508588  168516    340072  34% /boot
/dev/mapper/rhel-root--snapshot10  12571648 1193528  11378120  10% /.snapshots/10/snapshot

snapshot間の差分

snapperではsnapshotを一時的なディレクトリにmountして、差分を取る仕組みがあります。
さらに通常のスナップショットの他に、管理に便利なようにpreとpostというタイプが導入されています。スナップショット自体は同じなのですが、なんらかの作業前にpreスナップショットを取得、作業後にpostスナップショットを取得してペアにしています。
今回は触れませんが、pre,postのスナップショットを各種の作業前後に自動的に作成して、特に差分がなければ自動的に消す仕組みも含まれています。
preスナップショット作成

[root@localhost ~]# snapper create -t pre
適当にファイル変更

[root@localhost ~]# ls
anaconda-ks.cfg  hoge  lvmdump-localhost.localdomain-20150515103428.tgz
[root@localhost ~]# rm hoge 
rm: remove regular empty file ‘hoge’? y
postスナップショット作成

[root@localhost ~]# snapper list
Type   | #  | Pre # | Date                     | User | Cleanup | Description | Userdata
-------+----+-------+--------------------------+------+---------+-------------+---------
single | 0  |       |                          | root |         | current     |         
single | 9  |       | Mon May 18 18:15:10 2015 | root |         |             |         
pre    | 10 |       | Mon May 18 18:18:32 2015 | root |         |             |         
[root@localhost ~]# snapper create -t post --pre-number=10
[root@localhost ~]# snapper list
Type   | #  | Pre # | Date                     | User | Cleanup | Description | Userdata
-------+----+-------+--------------------------+------+---------+-------------+---------
single | 0  |       |                          | root |         | current     |         
single | 9  |       | Mon May 18 18:15:10 2015 | root |         |             |         
pre    | 10 |       | Mon May 18 18:18:32 2015 | root |         |             |         
post   | 11 | 10    | Mon May 18 18:19:42 2015 | root |         |             |
差分の確認

[root@localhost ~]# snapper status 10..11
-..... /root/hoge
c..... /var/log/messages
c..... /var/log/snapper.log

差分対象の制限(フィルタ)

hogeファイルが消えているのと、/var/log以下のログが増えていることがわかります。
ログの差分をとってもあまり嬉しくないので、/etc/snapper/filters/ に、log.txtという名前で以下のようなファイルを作成します。このパターンにマッチするものは差分チェックの対象になりません。
差分対象の制限

/var/log/*
差分の確認ふたたび

[root@localhost ~]# snapper status 10..11
-..... /root/hoge

undo

差分がとれるので、patchコマンドの要領でundoができます。
ただこのundoをした時に一貫性があるのか、もろもろ大丈夫なのかなどは特に保証されていませんので注意が必要です。

[root@localhost ~]# snapper undochange 10..11 
create:1 modify:0 delete:0

TODO

snapperにはこの他にも定期的にsnapshotをとっておいて、過去数回分を残しておくなどかなり気のきいた機能があります。 裏で古いスナップショットを自動で消したり差分をしらべたりするので勝手に動くのが嫌なひとはオプションしらべてね(丸投げ)!