Red Hat Network ClassicからRed Hat Subscription Managementへ移行のおねがい

Red Hat Network Classicのサービス提供が2017年7月31日に終了します。この日より後には、RHN Classicはアップデート配信ができなくなります。もしRHN Classicを利用してシステムを登録している場合はこの日までに移行をおねがいいたします。

レッドハットの森若です。

みなさんがRed Hat Enterprise Linuxを利用してアップデートを行う時に、RHEL4までであればup2date、RHEL5以降のバージョンであればyumを利用しているかと思います。このアップデート配信時に利用されるサブスクリプション管理の仕組みが2016年現在は「Red Hat Network Classic(RHN Classic)」と「Red Hat Subscription Management(RHSM)」の2種類存在しています。

この2種類のうちRHN Classicのサービス提供が2017年7月31日に終了します。この日より後には、RHN Classicはアップデート配信ができなくなります。もしRHN Classicを利用してシステムを登録している場合はこの日までに移行をおねがいいたします。

これまでのサブスクリプション管理の変遷

RHN ClassicはRed Hat Enterprise Linuxより以前の2001年から提供されていました。15年ほどの非常に長い期間にわたって利用されていたため、特に仮想化環境への対応や、購入したサブスクリプションとシステムとの対応づけがされないなどの能力不足が目立つようになっています。

2011年から、RHSMという新しいサブスクリプション管理の仕組みの提供が始まりました。具体的にはRed Hat Enterprise Linux 6.1および5.7にsubscription-managerというパッケージが含まれ、新しいサブスクリプション管理の仕組みが利用できるようになりました。

2012年から2013年にかけて、RHSMがデフォルトに切り替えられていきました。RHEL 6.3、RHEL 5.9からは、インストーラで特に何も指定せずに登録した場合はRHN ClassicではなくRHSMを利用して登録されるようになっています。

2014年に出荷されたRHEL7では、(Red Hat Satellite 5を利用している例外的な場合をのぞいて)RHSMのみが利用できます。

Red Hat Subscription Manager とRed Hat Network Classicの比較

機能面で比較すると、RHSMはRHN Classicよりカバーする範囲が狭くなっています。RHN Classicでは、Smart Management アドオンを購入することで追加の管理機能が提供されましたが、RHSMではサブスクリプション管理とコンテンツ配信だけを行うことに特化しています。

RHN Classicをシステム登録だけでなく管理にも利用している場合は、管理ツールの移行もあわせてご検討ください。

Red Hat Subscription Managementと RHN Classicの機能比較

Red Hat Subscription Management

Red Hat Network Classic

システム登録

サブスクリプションの割り当て

コンテンツ配信

設定ファイルの管理

ローカルで実行する必要あり

システムスナップショットの作成

ローカルで実行する必要あり

システムのキックスタート

Satellite 6 または他の管理ツールが実行。

スクリプトの実行

Satellite 6 または他のツールが実行。

どのサブスクリプション管理を利用しているかの確認

現在利用しているシステムがどちらの仕組みで登録されているかを確認しましょう。

管理製品を利用している場合、その製品によりどちらの仕組みを利用しているかが決まります:

  • Red Hat Satellite 5をご利用中の場合、RHN Classicの仕組みで管理されていますがRed Hat Satellite 5のライフサイクル中は影響がありません。通常のサブスクリプションで2018年1月31日までご利用が可能です。

  • Red Hat Satellite 6 または Red Hat Subscription Asset Managerをご利用中の場合、RHSMの仕組みで管理されています。

RHELのバージョンにより決まる場合があります:

  • 「RHEL 4の全てのマイナーリリース、RHEL 5.0から5.6までのマイナーリリース、RHEL6.0」のいずれかを利用している場合はシステム登録にRHN Classicが利用されます。RHEL4にはRHSMへ移行する方法がありません。RHEL5およびRHEL6については最新バージョンへの更新をお勧めいたします。

  • RHEL7を利用している場合、RHSMで管理されています。

どちらも利用可能なRHEL6.2以降、RHEL5.7以降の場合、“yum repolist” のようにyumコマンドを実行します。RHN ClassicおよびRHSMはどちらもyumのプラグインとして呼びだされるので、どのyumプラグインが利用されているかによって判定が可能です。

  • RHN Classicの場合: rhnplugin

  • RHSMの場合: subscription-manager

詳しくは以下のナレッジベースをご確認ください

システムのアップデートに RHN Classic と RHSM のどちらを使用しているかを確認するhttps://access.redhat.com/ja/solutions/1350833

Red Hat Network ClassicからRed Hat Subscription Managementへの移行

現在RHN Classicで登録しているシステムをRHSMへ移行するためのツールを提供しています。詳しくは以下「第12章 RHN Classic からのシステム移行」をごらんください。

https://access.redhat.com/documentation/ja-JP/Red_Hat_Subscription_Management/1.0/html/Subscription_Management_Guide/rhn-migration.html

Red Hat Enterprise Linux for Virtual DatacenterのようなゲストOSとしてRHELを無制限に利用できるサブスクリプションを利用している場合、virt-whoによるハイパーバイザの登録が必要です

参考文献

Red Hat Satellite使いはじめガイド

Red Hat SatelliteはRed Hatの提供するRHEL運用管理ソフトウェアです。非常に多くの機能があり、ソフトウェアとしても規模が大きなものになっています。今回の記事ではRed Hat Satelliteをこれから利用しようと検討している方むけに Red Hat Satelliteを利用しはじめるにあたっての注意点や関連サービスをご紹介します。

レッドハットの森若です。今回はRed Hat Satelliteを利用しはじめるにあたっての注意点や関連サービスをご紹介します。

0. 各種サービスの確認

サブスクリプションには問い合わせ回数無制限のサポートサービスが含まれています。 基本的な利用方法、設定手順、製品障害対応などをおこないます。

電話: 0120 266 668

Web: https://access.redhat.com/support/cases/

製品をスムーズに利用できるよう、Red Hatトレーニングにて包括的なハンズオントレーニングを提供しております。Satelliteとその周辺について包括的な知識を得られるのでおすすめです。Satellite 6.x対応のコース RH403が2016年6月から提供開始しております。

Red Hat コンサルティングでは構築の支援やナレッジトランスファを中心とした有償コンサルティングサービスを提供しております。多くの実績があるコンサルタントが構築を支援します。

1. 利用するSatelliteのバージョンを決める

現在Red Hat Satelliteには、5.x系と6.x系の2系統の実装があります。主に管理対象とするRHELのバージョンとSatellite自身のライフサイクル、利用したい機能によりどちらを利用するかを選択します。 サブスクリプションはどちらのバージョンでも共通で、購入後に変更することも可能です。

Satellite 5.x

  • RHELの全バージョン(2.1から7.xまで)を管理可能

  • 通常サポートは2018年1月まで、延長サポートは2020年1月までで終了

Satellite 6.x

  • 管理対象はRHEL 5.7以降、RHEL 6.1以降、RHEL 7.0以降のみ

  • コマンドの実行はSatellite 6.2から搭載予定

2. Satelliteで利用したい機能を決める

Satelliteには非常に多くの機能があります。機能を全部使おうとすると評価や学習に時間を浪費することになってしまいます。利用する機能を、あらかじめ優先順位をつけて決めておくことが重要です。

現在の課題に対してSatelliteのどの機能が有効かを考えたい場合には営業窓口までご相談ください。

Red Hatトレーニングのハンズオントレーニングにて実際に機能を構築・試用しておくとスムーズに利用を開始できます。

(参考)よく利用される機能の例

  • 全てのRHELを登録してシステム台帳として利用する

  • Red HatのパッケージをSatelliteから取得することでアップデート作業時間を短縮する

  • Red Hatのパッケージとerrata情報から、脆弱性対応状況表として活用する

  • カスタムのチャネル/リポジトリを作成し、ISV製/内製ソフトウェアの配布に利用する

  • Satelliteから各ホストへのアップデート指示をおこなう

  • Satelliteから各ホストへコマンド実行の指示をおこなう (現在はSatellite 5.xのみ)

  • オフライン環境でのRHELアップデート実行を効率的に行う

3. Satelliteの構築をおこなう

ドキュメント Installation Guide を参照し、Satelliteのインストールをおこないます。

Red Hat コンサルティングによる有償での構築支援を提供しております。構築および導入を手早く行いたい場合におすすめです。Satellite 5.x, 6.xのいずれでも対応可能です。

事前に評価したい場合には評価用サブスクリプションをご用意しておりますので営業窓口までご相談ください。

4. 管理対象RHELをSatelliteへ登録

利用したい機能にあわせて、登録時にSatelliteからどの操作を許すか、エージェントなどの関連パッケージをインストールするか等を決定します。

管理対象RHELをSatelliteへ登録します。手順については関連するドキュメントをご確認ください。

  • 5.x系ではClient Configuration Guide

  • 6.x系ではProvisioning Guide

5. 機能をテストする

あらかじめ決めた利用したい機能をテスト的に実行し、思ったように利用できているか確認します。場合によっては3や4に戻って必要な機能のための設定の追加などをおこないます。

6. 手順書を作成し、運用に組込む

Satelliteの機能を含んだ運用手順を作成し、通常の運用に組込みます。

コンサルティングサービスにてお客様作成の手順書のレビューなども承っております。

7. Satellite運用を評価し、改善していく

ある程度運用が安定したら、Satelliteの機能を利用してどの程度管理工数や各種の待ち時間などが改善されたか評価します。徐々にSatelliteの機能を活用していく範囲をひろげていきましょう。

RHELセキュリティ情報の入手と対応

レッドハットではソフトウェアの修正をerrataというデータベースで公開しています。errataで公開されている修正を適用して既知の問題を避けることはRHELを利用したシステム管理の基本です。この記事ではRHELのセキュリティ情報の入手と対応方法についてご紹介します。

レッドハットの森若です。今回はRHELのセキュリティ情報を入手し、対応をおこなうまでの手順を見てみましょう。

修正が作成されるまで

一般にプログラムに問題があるときは、プログラムのソースコードを修正して対応します。RHELのほどんとのパッケージではアップストリームのソースコードを直接変更せずそのままにしておき、修正は複数の「パッチ(修正用の差分情報)」を追加することでおこなっています。

RHELで利用されているrpm(RPM Package Manager)では、元のソースコードとパッチ、さらにそれらを処理して実際に実行されるプログラムに変換するための情報を「ソースrpm」とよばれるパッケージにまとめます。

ソースrpmから「バイナリrpm」を作成します。これは実際に実行できるプログラムなどが入ったパッケージで、通常「rpmパッケージ」という場合にはこのバイナリrpmのことをさしています。

通常1つのソースrpmから、複数のバイナリrpmが作成されます。動作するCPUアーキテクチャや利用するライブラリ、オプションなどによって、同じソースrpmから異なるバイナリrpmが作成されます。

errataとアドバイザリ

このように作成されたソースrpmおよびバイナリrpmを公開するデータベースがerrataです。

errataに含まれている、修正を公開する単位が「アドバイザリ」です。アドバイザリは、1つまたは複数のソースrpmの修正に対応したアナウンスで、以下のような情報を含みます。

  • アドバイザリのID (RH?A-XXXX:YYYY というフォーマットです。 ?はS,B,Eのいずれか、XXXX,YYYYは数字です)

  • 修正された問題の要約

  • 発行日、最終更新日

  • (セキュリティ修正のみ)重要度

  • (セキュリティ修正のみ)関連する脆弱性情報

  • 影響をうける製品

  • 更新されたパッケージとそのバージョン

  • 関連するbugzillaエントリ(通常は複数の修正が含まれています)

errataはそれぞれのアドバイザリがレコードとしてならんだデータベースになっています。

重要な特徴として、errataではそれぞれのアドバイザリに順序関係があり、同じ製品であれば新しいアドバイザリには、それ以前のアドバイザリで提供された修正が全て反映されています。

たとえばfirefoxがアドバイザリ A, B, Cの順に3回修正されたとすると、Aに含まれている修正は全てB,C にも含まれ、Bに含まれている修正はCにも含まれています。

つまり、常に最新のパッケージを適用することで、全ての既知の問題に対応できます。「Bで修正された部分は利用するがAとCの問題はそのまま放置する」というような選択肢をなくすことで、管理がシンプルになっています。

アドバイザリの種類は?

アドバイザリには3種類の分類があり、それぞれIDが以下の4文字ではじまります。

  • RHSA セキュリティ上の脆弱性を修正したアドバイザリ

  • RHBA バグを修正したアドバイザリ

  • RHEA 機能拡張したアドバイザリ

RHEAはマイナーリリース(7.1から7.2など)のタイミングで行われます。機能拡張と同時にバグやセキュリティ上の問題の修正が含まれる場合があるため、RHBA, RHSAも機能拡張を含んでいることがあります。

errata情報の入手

errataの情報は公開されており、以下のwebページから参照することができます。

https://access.redhat.com/security/updates/active/

また、通知を受ける方法としてRHELでは3通りの方法を提供しています。

1. yum-updatesd によるメール送信、log出力

RHELに同梱されている yum-updatesd は定期的にカスタマーポータルに接続して更新情報を取得し、更新パッケージがあれば通知します。

通知方法にはe-mail, log出力, dbusが選択でき、デフォルト設定ではdbusによる通知を利用して、GUI環境でアップデートの通知を画面表示させます。この設定を変更することでメールやログの形でアップデートの通知を受けとることができます。

詳しくは、「man yum-updatesd.conf」としてマニュアルを参照してください。

2. Red Hat カスタマーポータルからのメールによる通知

カスタマーポータルのErrata notifications設定により、errata出荷時にメールで通知を受けとることができます。

https://www.redhat.com/wapps/ugc/protected/notif.html

3. メーリングリスト、RSSフィードによる通知

errataの更新についての通知を、RSSフィードおよびメーリングリストでおこなっています。

 

脆弱性のCVE numberから対応するerrataアドバイザリを確認

RHSAには、Common Vulnerabilities and Exposures (CVE)の関連する脆弱性情報へのリンクが含まれています。以下のサイトで、CVE numberからerrataのアドバイザリを逆引きすることができます。ニュースサイト等で見た脆弱性が製品への影響しているかの確認や、既に出荷されていればerrataのIDを確認することができます。

https://access.redhat.com/security/cve/

yumコマンドによるセキュリティ修正の確認・対応

インターネット接続が可能であるか、Red Hat Satelliteが利用可能な環境では、yumコマンドによりセキュリティ対応をおこなうことが可能です。

サマリの表示

# yum updateinfo
Loaded plugins: langpacks, product-id, subscription-manager
Updates Information Summary: available
    3 Security notice(s)
        2 Critical Security notice(s)
        1 Important Security notice(s)
    2 Bugfix notice(s)
    2 Enhancement notice(s)
updateinfo summary done

適用可能なerrataの一覧

# yum updateinfo list available
Loaded plugins: langpacks, product-id, subscription-manager
RHSA-2015:1443 Important/Sec. bind-32:9.9.4-18.el7_1.2.x86_64
RHSA-2015:1443 Important/Sec. bind-libs-32:9.9.4-18.el7_1.2.x86_64
RHSA-2015:1443 Important/Sec. bind-libs-lite-32:9.9.4-18.el7_1.2.x86_64
RHSA-2015:1443 Important/Sec. bind-license-32:9.9.4-18.el7_1.2.noarch
RHSA-2015:1443 Important/Sec. bind-utils-32:9.9.4-18.el7_1.2.x86_64
RHSA-2015:1207 Critical/Sec.  firefox-38.1.0-1.el7_1.x86_64
RHSA-2015:1229 Critical/Sec.  java-1.7.0-openjdk-1:1.7.0.85-2.6.1.2.el7_1.x86_64
RHSA-2015:1229 Critical/Sec.  java-1.7.0-openjdk-devel-1:1.7.0.85-2.6.1.2.el7_1.x86_64
RHSA-2015:1229 Critical/Sec.  java-1.7.0-openjdk-headless-1:1.7.0.85-2.6.1.2.el7_1.x86_64
RHBA-2015:1192 bugfix         openssl-1:1.0.1e-42.el7_1.9.x86_64
RHBA-2015:1192 bugfix         openssl-libs-1:1.0.1e-42.el7_1.9.x86_64
RHBA-2015:1474 bugfix         python-chardet-2.2.1-1.el7_1.noarch
RHEA-2015:1473 enhancement    python-urllib3-1.10.2-1.el7_1.noarch
RHEA-2015:1476 enhancement    redhat-access-insights-1.0.4-0.el7_1.noarch
updateinfo list done

アドバイザリ詳細の確認

# yum info-sec --advisory RHSA-2015:1443
Loaded plugins: langpacks, product-id, subscription-manager

===============================================================================
  Important: bind security update
===============================================================================
  Update ID : RHSA-2015:1443
    Release :
       Type : security
     Status : final
     Issued : 2015-07-20 00:00:00
       Bugs : 1237258 - CVE-2015-4620 bind: abort DoS caused by uninitialized value use in isselfsigned()
       CVEs : CVE-2015-4620
Description : The Berkeley Internet Name Domain (BIND) is an implementation of
            : the Domain Name System (DNS) protocols. BIND
            : includes a DNS server (named); a resolver library
            : (routines for applications to use when interfacing
            : with DNS); and tools for verifying that the DNS
            : server is operating correctly.
            :
            : A flaw was found in the way BIND performed DNSSEC
            : validation. An attacker able to make BIND
            : (functioning as a DNS resolver with DNSSEC
            : validation enabled) resolve a name in an
            : attacker-controlled domain could cause named to
            : exit unexpectedly with an assertion failure.
            : (CVE-2015-4620)
            :
            : Red Hat would like to thank ISC for reporting this
            : issue.
            :
            : All bind users are advised to upgrade to these
            : updated packages, which contain a backported patch
            : to correct this issue. After installing the
            : update, the BIND daemon (named) will be restarted
            : automatically.
   Severity : Important
updateinfo info done

CVE IDを指定してのアップデート

# yum update --cve CVE-2015-4620

アドバイザリIDを指定してのアップデート

# yum update --advisory RHSA-2015:1443

RHELのバージョンによりyumコマンドで利用するオプションが変わります。以下のナレッジベースでRHELの5,6,7それぞれでの操作をご案内しています。

https://access.redhat.com/solutions/10021

参考情報

セキュリティガイド 第3章 システムを最新の状態に保つ

ABRTで障害時の情報収集とレポートを自動化しよう

Red Hat Enteprise Linux 6から、ABRT(Automatic Bug Reporting Tool)が同梱されています。RHELを運用していて、ABRTからのレポートメール「[abrt] full crash report」を受信したことがある方もいるかと思います。今回はRHEL7でのABRTについて見てみましょう。

レッドハットの森若です。Red Hat Enteprise Linux 6から、ABRT(Automatic Bug Reporting Tool)が同梱されています。RHELを運用していて、ABRTからのレポートメール「[abrt] full crash report」を受信したことがある方もいるかと思います。今回はRHEL7でのABRTについて見てみましょう。

ABRTとは何か?

RHELに含まれるソフトウェアに何かしらの問題があり、クラッシュしたとしましょう。
レッドハットのサポートへ相談をするときに何をするでしょうか? 問題の再現と情報収集ですね。

問題の解析をする際には、問題発生時にそのソフトウェアが何をしようとしていたか、どのような環境で動作していたか、前後のログはどうであったか、コマンドラインはどうなっていたか、ファイルやメモリをどう使用していたかなどの多数の情報が必要になります。再現して収集するのではなく、これらの情報を最初から収集することができれば、問題解析の初動が非常に早くできます。

ABRTは、ユーザがアプリケーションのクラッシュを発見し、報告する時に必要になる作業を自動化するための仕組みです。ABRTは各種の問題を検出するabrtdと、検出した問題に関連した情報を収集し報告するためのプログラム群でできています。

ABRTのおおまかな動作は以下のようになっています。

  1. 起動時にabrtdを起動。ログの監視や、各種クラッシュの検出設定を仕込む
  2. 問題が発生。abrtが問題を検出
  3. 検出した問題の関連情報をできるだけ収集してファイルに保存
  4. 管理者へのメール送信などで問題があったことを通知
  5. レポート送信

ABRTはどのような問題を検出するか?

問題にはいろいろな種類がありますが、現在ABRTが対応する問題は以下のものです。クラッシュなどが発生せず意図しない動作をするような場合には対応できません。

  • C/C++, Python, Ruby, Java で作成されたプログラムのクラッシュ
  • linux kernel が”OOPS”メッセージを出力した場合
  • linux kernel がクラッシュしkdumpを出力した場合
  • Xサーバがクラッシュした場合

問題時の情報収集

ABRTが具体的にどのような情報を収集するかは、対応する問題によっても変わりますが、典型的には問題が発見されたプロセスがどのような状態であったかが収集されます。

収集した情報は/var/spool/abrt以下に保存されます。abrt-cliコマンドでその一覧を見ることができます。

# abrt-cli list
id cb36e53c4f8d61a7b93520735df0448349ee8936
reason:         systemd-logind killed by SIGABRT
time:           Tue 24 May 2016 10:43:23 AM JST
cmdline:        /usr/lib/systemd/systemd-logind
package:        systemd-219-19.el7_2.9
uid:            0 (root)
count:          2
Directory:      /var/spool/abrt/ccpp-2016-05-24-10:43:23-679
Run 'abrt-cli report /var/spool/abrt/ccpp-2016-05-24-10:43:23-679' for creating a case in Red Hat Customer Portal

この中のDirectoryが対応するディレクトリで、この中に問題に関連する情報が含まれています。

# ls /var/spool/abrt/ccpp-2016-05-24-10 
abrt_version    dso_list     machineid   pkg_name           type
analyzer    environ         maps         pkg_release       uid
architecture    event_log     open_fds    pkg_version       ureports_counter
cgroup        executable     os_info     proc_pid_status   username
cmdline        global_pid     os_release  pwd           uuid
component    hostname     package     reason           var_log_messages
core_backtrace    kernel         pid         runlevel
coredump    last_occurrence  pkg_arch    sosreport.tar.xz
count        limits         pkg_epoch   time

これらの定義については以下のナレッジベースに記載があります。
https://access.redhat.com/articles/2134281

収集した情報をレポート送信

ABRTではレポート送信がlibreportとしてモジュール化されており、レッドハットのカスタマーサポートに送信する他にもメールでの送信やbugzillaへ送信するなどいくつかの処理ができるようになっています。冒頭の「[abrt] full crash report」というメールはABRTがrootユーザ宛にこのレポートを送信したメールです。

RHELのデフォルトでは以下のコマンドにより、レッドハットのカスタマーサポートへレポートを送信できます。このふるまいは /etc/libreport/report_event.conf の設定により変更できます。

# abrt-cli report /var/spool/abrt/ccpp-2016-05-24-10:43:23-679

上記のようにコマンド入力すると、カスタマーポータルヘ接続可能であればアカウント情報を求められたのち、viでレポート入力をおこなってその場でレポートを送信できます。

ABRTの注意点

以上のようにABRTは問題解析を手助けしてくれる強力なツールなのですが、自分でプログラムを開発している場合はABRTの仕組みが邪魔になってしまうことがあります。たとえば同じ問題が繰り返し発生することを想定して、ABRTでは同じプログラムの同じような問題が繰り返されていれば一旦保存したダンプを削除しますが、開発中はこのような動作は望ましくありません。

このような場合には  /etc/abrt/abrt-action-save-package-data.conf でABRTの対象外となるパッケージや、ディレクトリ名を指定することで通常のパッケージについてはABRTを利用しつつ自分の作業についてはABRTを使わないような工夫ができるようになっています。

関連ドキュメント

Red Hat Enterprise Linux 7 システム管理者のガイド 「第20章 自動バグ報告ツール (ABRT)」 https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-abrt.html

Red Hat Enterprise Linux 7、使ってますか?

Red Hat Enterprise Linux 6のライフサイクルがあと5年を切りました。これから5年間の稼働が必要なシステムはRHEL7を利用する必要がでてきます。RHEL7をご利用になるお客様も増えてきました。本稿ではこれからRed Hat Enterprise Linux 7を使いはじめようという人におすすめのリソースをおしらせします。

2016年はRHEL7の年

レッドハットの森若です。

2015年11月末で、Red Hat Enterprise Linux 6のライフサイクルがあと5年を切りました。

現在RHEL 5をご利用の場合には、2017年3月でProduction 3が終了します。修正が必要な場合はELSによるサポート期間の延長が有用ですが、2020年中にはELSも終了予定です。

これらを踏まえて考えると、2016年から新規に「5年間の稼働が必要なシステム」を構築する場合はRHEL7を利用する必要がでてきます。

https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux より引用・改変

私自身の感触としても本番環境でRHEL7をご利用になるお客様が増えています。これからRed Hat Enterprise Linux 7を使いはじめようという方におすすめのドキュメントや記事をおしらせします。

RHEL6とRHEL7の差分は?

まずはこの移行計画ガイドです。Red Hat Enteprise Linux 6から7へ移行する際にあたって注意するべきポイントが網羅的にまとまっています。

RHEL7では、RHEL6の最新版からのアップグレードをサポートしています。そのための専用ツール Preupgrade Assistant および Red Hat Upgrade Tool の説明もこのドキュメントから参照できます。

RHEL6をスキップしてRHEL5からRHEL7へと移行するお客様むけに、RHEL5とRHEL7の大きな違いをまとめたナレッジベースの記事です。

この記事ではRHELの各メジャーバージョンごとの技術上の制限を列挙しています。

RHEL7のインストール

RHEL7ではインストーラが大きくかわりました。今までのRHELに慣れている方もインストールガイドを確認しましょう。

RHEL7の基本的な使い方

Chapter I, III にsystemdやchronyなど新規に登場したソフトウェアの基本的な操作方法がまとまっています。

上記で紹介した以外にもいろいろなドキュメントやナレッジベースがあります。ぜひカスタマーポータルを見てください。

RHEL7関連記事

RHEL 7関連記事をいくつかご紹介します。

Red Hat公式トレーニング

Red Hatの公式トレーニングのうち、以下のものはRHEL7対応が完了しています。

  • システム管理I
  • システム管理 II
  • システム管理 III
  • パフォーマンスチューニング
  • Managing Containers with RHEL Atomic Host

それぞれのコースはハンズオンで2日ないし4日でみっちりRHEL7について学習できます。個人的にはこのトレーニングを受講するのが一番早くRHEL7に慣れることができるのではないかと思っています。

終日4日間にわたるトレーニングへの参加や、東京・大阪の教室への移動がむずかしい方もいらっしゃると思います。このような場合には、90日間利用可能なオンライントレーニングも販売しています。専用の環境にブラウザからリモートアクセスして実習をおこなう形式のトレーニングです。

さらに1年契約で多数のコースを利用可能なRed Hat Learning Subscriptionの販売も開始しました。

パートナー向けトレーニング

会社がRed Hatのビジネスパートナーやテクノロジパートナーになっていると、英語のみですがパートナーむけのオンライントレーニングを受講できます。営業向け、エンジニア向けなどいくつかのコースに分かれています。エンジニア向けコースはRHEL7に対応しています。

ぜひ パートナー向けサイト http://partner.redhat.com/ からアクセスしてみてください。

ということで。。。

まずは手元に仮想マシンなどで1台RHEL7をインストールしてみましょう。RHEL5やRHEL6のXenやKVM上にもRHEL7をインストールできます。

ソフトウェアの移植作業などであればRed Hat Developer Programで提供される開発者用サブスクリプションも利用できます。

差分を手早く学習するにはドキュメントやトレーニングが便利です。使っていて不思議なことがあればサポートもご活用ください 🙂

Red Hat Developer Programに参加して開発者用サブスクリプションを入手しよう

今回は開発者むけプログラムの拡充により、無償で開発目的のサブスクリプションが入手できるようになったのでご紹介します。

レッドハットの森若です。Red Hat Enterprise Linuxに興味があるけどなかなか手が出せないな、という方は多くいるかと思います。比較的安価なRed Hat Enterprise Linux Workstationでも定価で4万円弱しますのでお小遣いで買うのは厳しいですね。今回は開発者むけプログラムの拡充により、無償で開発者向けのサブスクリプションが入手できるようになったのでご紹介します。

Red Hat Enterprise Linux Developer Suite

従来から開発者向けのRed Hat Enterprise Linux Developer Suite という製品があり、Red Hatのオンライン販売サイトから99 USDで販売されています(日本からもクレジットカードがあれば購入できますが、直販や代理店経由での取り扱いはありません)。

利用目的は開発目的に制限され、サポートへの問いあわせもできませんが、RHELを1台のハードウェア上で、仮想マシン数の制限なく利用できます。カスタマーポータルも利用できるのでナレッジベースの利用も可能です。

「開発目的」がどこまでの範囲かよくわからないという方がいるかもしれませんが、これは契約書内で具体的に定義されており、以下3種類のユースケースのみです。複数ユーザで共用するような場合には利用できません。

Enterprise Agreementの参考和訳より:

  • ソフトウェアコードを作成するシングルデベロッパー
  • シングルユーザー プロトタイピング、品質保証またはテスト
  • 本ソフトウェアとともにもしくは本ソフトウェア上で動作、稼動するソフトウェアやハードウェアの実演

利用可能なユースケースの例:

  • 手元で開発作業に利用するノートPCにインストールし、一人でおこなう開発作業の範囲内で利用
  • 動作確認
  • デモンストレーション

利用不可能なユースケースの例:

  • (サーバ用途に限らず)開発用に複数人で利用するシステム全般。
    •   ソースコードリポジトリ、Issue Tracker、ビルドサーバなど複数人で利用するもの
  • 開発、プロトタイピング、品質保証、テスト、実演にあたらない目的全般。
    • 維持環境の構築
    • トレーニングや学習用
    • CADなどでのデザイン業務用 (ソフトウェアコードの作成ではない)

Red Hat Developer Program

Red Hat Developer Programとは、ソフトウェア開発者にRed Hat製品を使って開発をしてもらうことを目的としたプログラムです。 JBossをはじめとするミドルウェアや、コンテナ上で動作するアプリケーションの開発などをトピックとしてblogやチュートリアル、ライブビデオなどで情報発信をしています。このDeveloper Programの特典としてRed Hat Enterprise Linux Developer Suiteが無償で1本提供されます。

1ユーザ登録ごとに1本提供されるので、たとえば10人開発者がいてそれぞれがDeveloper Programに登録すれば10本のRed Hat Developer Suiteが無償提供されます。

申し込みの流れ

ざっと申し込みの流れをみてみましょう。

  1. http://developers.redhat.com/ へアクセス

  2. 右上の「REGISTER」をクリックして登録開始

  3. 登録がおわったら「DOWNLOADS」タブをおして……

  4. 必要な製品をダウンロードします。最初のダウンロード時にはDeveloper Programの参加にともなう契約の確認が行われます。

アカウント名を押してパスワード設定やユーザ名の確認をおこないましょう。このUsernameとパスワードでカスタマーポータル(https://access.redhat.com/) にもアクセスできます。

関連リンク

Relax and Recoverでのシステム回復

RHEL 7.2から同梱されるようになったRelax and Recoverにより、システム回復時のパーティションや、LVM構成、ファイルシステム構成の回復が簡単になります。

レッドハットの森若です。RHEL 7.2から同梱されるようになったRelax and Recover(ReaR)により、システム回復時のパーティションや、LVM構成、ファイルシステム構成の回復が簡単になりました。今回はこのRelax and Recoverをご紹介します。

バックアップからの回復

従来からRHELでは、インストーラをrescue modeというモードで動作させ、回復処理をおこなうことができました。

インスールガイド「インストーラーレスキューモード」

rescue modeは/mnt/sysimageに本来のシステムツリーをマウントし、各種の操作をおこないます。バックアップやリストアに使えるだけでなく、多くの障害においても非常に役に立つものです。

ディスク交換などでパーティションやLVMなどのディスク構成がなくなっている場合には、以下のようなステップで回復処理をおこないます。

1. 元のディスク構成を回復する。物理的なRAID設定、ディスクのパーティション、LVM、ソフトウェアRAID、ファイルシステム、Swap領域などを元と同じに設定する。

2. バックアップしていたデータをファイルシステム上に回復する。

Relax and Recoverは、1の部分を自動化するところに重点を置いています。また、ReaRが対応している形式であればバックアップデータがどこにあるかを設定しておくことで、データ復旧についても自動化することが可能です。

Relax and Recoverの利用手順

Relax and Recoverの利用は比較的簡単におこなえます。USBメモリを回復用メディアおよびバックアップメディアに利用する場合のおおまかな手順を以下にしめします。

1. yum install rear genisoimage syslinux  として関連パッケージを導入

2. rear format <デバイス名 /dev/sdc> コマンドでUSBメモリをフォーマット。その後USBメモリを一旦抜いて刺しなおす。

3. /etc/rear/site.conf に回復用メディアの種類と場所、バックアップ方法を指定(ReaRに内蔵されるtarによる素朴な実装を選択しています。)

OUTPUT=USB
USB_DEVICE=/dev/disk/by-label/REAR-000
BACKUP=NETFS

4. rear mkbackup コマンドにてレスキュー用メディア作成
バックアップを別途dump/restoreや他のシステムで行う場合はmkbackupをmkrescueコマンドにすることで、ディスク構成だけを回復させるためのメディアを作成できます。

バックアップもReaRでいいの?

ReaRのドキュメント内にも記載がありますが、ReaR内蔵の仕組みでは定期的なバックアップ取得や容量の管理の仕組みがありません。そのため、ある程度の規模がある場合はバックアップ用の各種ソリューションをおすすめします。NETFSやRSYNCといったrear内蔵 の仕組みを利用する場合は管理者が古いデータの定期的な削除を行う必要があります。

rearは複数のバックアップシステムに対応しており、そのデータを利用した復旧が可能です。http://relax-and-recover.org/about/

RHEL同梱のものではamandaがこのような管理をおこないます。RHELには含まれませんが、個人的にはduplicity http://duplicity.nongnu.org/ を利用しています。ReaRのドキュメントでは rsync backup made easy https://github.com/schlomo/rbme が紹介されています。

参考資料

 

Red Hat Insightsとは

既存のRed Hat Enterprise Linux環境について、「特に問題がでていないので」塩漬けにしてしまっているケースが多くあるかと思います。このような環境でも既知の脆弱性や問題が含まれていることがあります。 Red Hat Insightsは既知の脆弱性や問題を自動的に検出し、実際に障害が発生する前に対策することを目的としたサービスです。

Red Hat Insights とは

レッドハットの森若です。

Red Hat InsightsはRed Hat Enterprise Linux について、重要な問題の発見、調査、解決を支援するためのサービスです。執筆時点ではRHELを使っているお客様ごとにそれぞれ10台まで無償で登録することができます。11台以上の登録については、現在はEarly Access Programとして一部のお客様に試していただいている段階ですが、将来的には有償サービスとして一般へ展開予定です。

Red Hat Insights はRHEL 6以降で提供される redhat-access-insights パッケージと、Red Hatカスタマーポータル内のサービスの組み合わせで実現されています。

各RHELにredhat-access-insights パッケージを導入し、定期的に構成情報や現在動作しているサービスなどの情報をRed Hatカスタマーポータルへ送付します。送付された情報はルールに基いて自動的に評価され、レポートを表示します。このルールは、サポートへのお問い合わせが多い問題や、重大な脆弱性についての情報を元に作成されていています。

https://access.redhat.com/insights/ にアクセスしてレポートを確認できます。

レポートには発見された問題(らしきもの)のカテゴリと重大度による分類が表示され、それぞれの問題について詳細が確認できます。既知の脆弱性、複数の設定間の齟齬、既知の問題がある設定などを検出します。それぞれの問題について、問題の説明、対応方法、関連するナレッジベースの記事を確認できます。

Red Hatでは継続的にルールを開発・更新しています。Red Hat Insightのレポートをメールで送信する設定があり、有効にすると週次で新規に発見された問題や、登録されたシステムの更新状況を受信できます。

筆者も実際に古いRHEL6の仮想マシンを登録してみたところ、208.5日問題をはじめとしていくつかの問題の指摘を確認できました。

インターネット接続が許されていない環境のRHELについても、Red Hat Satelliteをプロキシーとして動作させることで多くの場合に対応が可能です。この場合Red Hat Satelliteはカスタマーポータルへの接続が必要です。

参考資料

 https://access.redhat.com/insights/getting-started/ 「Red Hat Insights はじめに」

Identity Manager (IdM)とは?

Red Hat Enterprise Linux に付属するID管理ソフトウェアIdentity Manager (IdM)を紹介します

Identity Manager (IdM)とは?

Red Hat Enterprise Linux に付属するID管理ソフトウェアです。upstreamプロジェクトはfreeipaです。

できること:

  • Red Hat Enterprise Linux上でのユーザ、ホスト、サービスの認証をおこない、シングルサインオン環境を構築できます。

  • Active DirectoryとCross realm trustを構成してWindows – Linuxにまたがるシングルサインオンが構成できます。

  • 一般的なプロトコル(LDAP, Kerberos, DNS)を利用しているので他社製品や古いRHELでの認証にも利用できます

  • sudo, automount, sshの公開鍵なども一緒に管理します

  • RHEL 7.1同梱版からはHOTP、TOTPによる2要素認証にも対応しています
  • サーバへのログインだけでなくアプリケーションの認証にも利用できます。PAMによる認証、mod_auth_mellonによるSAML認証、Kerberosによる認証などへ対応しています。Red Hatの各製品においてもIdMへの対応が徐々に進んでいます。

 

できないこと:

  • 汎用的なLDAPサーバではありません。認証に特化しています。

  • 他社製品のクライアント側についてのサポートはされません。

  • WindowsのID管理を統合するものではありません

Identity Manager 実装上の特徴

  • 標準技術の組み合わせにより実装されています

    • そのため特に「IdMに対応」していない古いRHELやUnix系OSからも利用することができます

  • 非常にセキュア側に機能を制限しています。具体的には:

    • パスワード再発行時には管理者が発行したあと必ずユーザー自身による再設定が強制される

    • パスワードのハッシュ値そのものは管理者であっても通常のクエリでは参照できないし、設定もできない

    • パスワードはハッシュ値のみしか保持しない

  • Active Directoryとの連携も用意しています

    • Active DirectoryからIdMへパスワード更新をレプリケーションすることができます

    • IdMからActive Directoryへはレプリケーションできません。これはIdMではハッシュ値でしかパスワードを保持しないためです。

    • Cross realm trustにより、ADで発行したチケットを利用してIdMで認証、またはその逆が可能です。これによりWindows環境とLinux環境をまたいだシングルサインオンを実現します(RHEL7.0以降に同梱されるIdMから。クライアントはRHEL6.4以降)

  • 既存環境からの移行を想定しています

    • NISやLDAPからの移行をサポートするスクリプトとドキュメントが同梱されています

  • UI

    • WebとコマンドラインでのUIが用意されています

  • 可用性

    • 20マルチマスタまでサポートし、高可用性はマルチマスタ構成と、

    • SSSDのキャッシュ機能により実現します。

  • identity managerはいろいろなOSSを組みあわせて実装されています。

    • NTPd, 389DirectoryServer (LDAPサーバ), MIT Kerberos, bind (DNSサーバ)など既存のもの 

    • freeipa, dogtag, ipa-otpdなど新規に作成されたもの

  • Identity ManagerではActive Directoryに似た「ドメイン」の概念を導入しています。

    • 基本的にIdentity Managerは1ドメインの管理しかおこないません。

    • クライアント側はSSSDにより複数のドメインに参加することができます。クライアント数に制限はありません。

費用に関連する特徴

  • RHEL Serverに同梱されていて追加費用はかかりません

  • アカウント数や接続数が増えても特に追加費用はかかりません

  • 直接ADに問いあわせる場合と比べてCALを減らせます。Cross realm trustによる連携をおこなう場合, ADと連携してシングルサインオンが可能でありつつもIdMで管理されているのでADのCALが不要です。

FAQ

  • IdMをつかわずにActive Directoryに直接といあわせたらいいのでは?

    • はい。そうやって構成することもできます(Direct Integrationと呼ばれています)。この場合はRHELに同梱されるSSSDを利用してActive Directoryに接続すると設定が容易です。

    • 台数が少ない場合(30台くらいまで)ならいいかもしれません。多いとADのCAL費用が気になります。

    • https://msdn.microsoft.com/en-us/library/cc731178.aspx によると、Identity Management for Unix はdeprecatedになりましたのでMSからサポートされる手順がなくなってしましました。この点については自己責任で利用することになります。

  • IdMをRHELでつかうときに注意することは?

    • 管理される側のRHELバージョンによりIdMのどの機能をサポートしているかなどの詳細が変わります。以下はADとのTrustがどの機能で有効かの対応表です。

  • サーバの前提条件は以下にまとまっています

  • IdMに全てを集約して、Windowsクライアントの認証も統合できますか?

    • サポートされませんし推奨もされませんが、WindowsにMIT Kerberosのクライアントを入れればできなくはないとおもわれます。

    • WindowsについてはADで管理し、Linux, UnixについてはIdMでというのが現実的なIdMの利用モデルです。

ドキュメント

(レッドハット ソリューションアーキテクト 森若和雄)

RHEL7でpingをreniceしようとすると失敗する話

Red Hat Enterprise Linux 7では、linuxのcapabilityを利用してsetuidの利用を少なくしています。capabilityについてあまり馴染みがない方も多いかと思います。トラブルシュート形式で、capabilityの利用時の特徴的なふるまいを見てみましょう。

レッドハットの森若です。今回は昔から存在するのですがあまり利用されていなかったCapabilityについて、RHEL7で活用されているという話です。

謎のエラー

以下の操作は、RHEL6では問題なく動作するのですがRHEL7では失敗します。

$ ping localhost &>/dev/null &  #バックグラウンドでping
$ renice 15 $!  # nice値を設定して優先度を下げる

今回はなぜこのような違いが発生するのか、その背景を見ていきましょう。

RHEL7でこの操作をすると、以下のようなエラーが出力されます。

$ renice 15 $!
renice: failed to set priority for 4609 (process ID): Operation not permitted

権限管理を追跡

rootでreniceをやってみます。

# renice 15 4609
4609 (process ID) old priority 0, new priority 15

今度は成功しました。エラーメッセージも「Operation not permitted(操作が許可されていない)」というものでしたが、renice処理そのものが何かの理由でできなくなっているわけではなく、なにか権限の問題で失敗しているようです。

もう一度同じことをしてpingプロセスの状態を見てみます。

$ ping localhost &> /dev/null &
[2] 2850
$ cat /proc/$!/status
Name:    ping
State:    S (sleeping)
Tgid:    2850
Ngid:    0
Pid:    2850
PPid:    2693
TracerPid:    0
Uid:    1000    1000    1000    1000
Gid:    1000    1000    1000    1000
FDSize:    256
Groups:    10 1000
VmPeak:      116500 kB
VmSize:      116476 kB
VmLck:           0 kB
VmPin:           0 kB
VmHWM:         996 kB
VmRSS:         996 kB
VmData:         264 kB
VmStk:         136 kB
VmExe:          40 kB
VmLib:        2160 kB
VmPTE:          60 kB
VmSwap:           0 kB
Threads:    1
SigQ:    0/15086
SigPnd:    0000000000000000
ShdPnd:    0000000000000000
SigBlk:    0000000000000000
SigIgn:    0000000000000000
SigCgt:    0000000000002006
CapInh:    0000000000000000
CapPrm:    0000000000003000
CapEff:    0000000000000000
CapBnd:    0000001fffffffff
Seccomp:    0
Cpus_allowed:    f
Cpus_allowed_list:    0-3
Mems_allowed:    00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:    0
voluntary_ctxt_switches:    15
nonvoluntary_ctxt_switches:    1

reniceはPermission deniedと出て失敗するので権限の問題らしいですが、uid, gidは自分のもの(1000)のままです。特に変なところがありません。これは通常のuid, gidから独立した権限管理が影響していそうです。

statで/usr/bin/pingの状態を確認してみましょう。

$ stat /usr/bin/ping
File: ‘/usr/bin/ping’
 Size: 44896         Blocks: 88         IO Block: 4096   regular file
Device: fd04h/64772d    Inode: 21449341    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:ping_exec_t:s0
Access: 2015-08-28 19:40:27.213100343 +0900
Modify: 2015-06-08 15:42:30.000000000 +0900
Change: 2015-07-24 12:37:03.285137514 +0900
Birth: -

setuidはついていませんね。uid, gidが同じであっても有効な権限管理としては、ファイルシステムのattribute, SELinux, ACL, Capability があります。

ファイルシステムのattributeは、ファイルの操作を(uid, gid, パーミッションの設定が同一であっても)制限することができます。今回はファイルのアクセスについての話ではないので影響しなさそうです。念のためlsattrコマンドでattributeを確認すると、どのフラグも立っていないので何も設定されていないことがわかります。

$ lsattr /usr/bin/ping
---------------- /usr/bin/ping

SELinuxの場合、特別に記録を禁止されていなければ/var/log/audit/audit.log にログが残ります。またRHEL7ではシステムログにもSELinuxでアクセスが禁止された旨の出力がおこなわれますが、reniceが失敗したような記録はありません。念のため setenforce 0 としてSELinuxをPermissiveにして実験しても同じようにreniceが失敗します。

ACLでしょうか? これもファイルシステムのattributeと同様ファイルの操作にひもづくので望み薄ですが一応確認しましょう。getfaclコマンドで確認してみると、通常のパーミッション以上の設定は行われていないことがわかります。

$ getfacl /usr/bin/ping
getfacl: Removing leading '/' from absolute path names
# file: usr/bin/ping
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Capabilityはどうでしょう? これは追加の権限を与えるものです。getcapコマンドでファイルのCapabilityを確認すると、cap_net_admin, cap_net_rawという権限が付与されていました。これがあやしいですね。

$ getcap /usr/bin/ping
/usr/bin/ping = cap_net_admin,cap_net_raw+p

Capabilityとは?

Capability とは何でしょう? rootユーザの権限を細かく分割したものだと考えることができます。rootユーザは一般ユーザでは禁止されている様々な操作が可能ですが、それぞれを分類し、名前をつけて個別に付与するなどの管理ができるようにしたものがCapabilityです。詳しくはman capabilities(7)を確認してみましょう。rootが持っている特権的な操作が列挙・分類されているので、capabilityを利用する予定がない人にも面白いとおもいます。

RHEL6ではpingにsetuidを使ってroot権限を利用していました。RHEL7ではcapabilityにより最小限の権限を付与しています。

  • RHEL6ではsetuidを使い、実行ファイルpingのownerがrootユーザなのでpingを実行するとrootユーザの権限が自動的に与えられます。root権限が必要な処理をしたあとsetuid(),setgid()によりpingプロセス自身を元のユーザの権限に制限しています。

  • RHEL7ではcapabilityを使い、ネットワーク管理に必要な操作を行う権限と、RAWソケットをopenして任意のパケットを送信する権限が与えられます。

この変更はセキュリティを改善するために導入されました。

pingの実装にセキュリティ上の問題があり、任意のコマンド実行が可能だと仮定してみましょう。この時rootユーザ権限で動作していると、/etc/shadowを一般ユーザが覗き見したり、/bin/bashを書き替えて何か悪いことをすることができてしまいます。

一方RHEL7のCapabilityでは、ネットワーク設定の変更やパケットの送信までは可能ですがファイルへのアクセスなどは元のユーザの権限のままです。このため、pingに未知の問題があったとしても被害が限定されます。

さきほどの/proc/$!/status での出力をよくみると、以下のような行があってCapabilityが追加されていることがわかります。

CapPrm:    0000000000003000

なぜreniceに失敗するのか?

さてRHEL7のpingはCapabilityで権限が追加されていることがわかりました。ではなぜreniceに失敗するのでしょうか?

該当するソースコードをlinux kernelのsecurity/commoncap.c から引用します。__task_cred(p)がreniceの対象になるプロセス(今回の例ではping)、current_cred() がreniceを実行しているプロセス(今回の例ではrenice)です。この2つの権限を比較して、サブセットになっていなければ失敗するようになっています。

/*
* Rationale: code calling task_setscheduler, task_setioprio, and
* task_setnice, assumes that
*   . if capable(cap_sys_nice), then those actions should be allowed
*   . if not capable(cap_sys_nice), but acting on your own processes,
*      then those actions should be allowed
* This is insufficient now since you can call code without suid, but
* yet with increased caps.
* So we check for increased caps on the target process.
*/
static int cap_safe_nice(struct task_struct *p)
{
       int is_subset;

       rcu_read_lock();
       is_subset = cap_issubset(__task_cred(p)->cap_permitted,
                                current_cred()->cap_permitted);
       rcu_read_unlock();

       if (!is_subset && !capable(CAP_SYS_NICE))
               return -EPERM;
       return 0;
}

一方のRHEL6では、一旦root権限を得るものの(この時はreniceできません)、その後setuid(), setgid()にて権限を元のユーザのものに戻すため、reniceをすることができます。

関連資料

ということでpingをreniceできないという謎の裏にはセキュリティを強化するための仕組みが隠れていました。あまり馴染みのない権限管理の仕組みがでてきたと思います。関連するドキュメントを記載しておきます。

man capabilities , (和訳)

man acl(和訳)

man chattr(和訳)