yohgaki's blog

カテゴリー: Computer

  • Fedora42 + VMware Workstation

    Fedora42など、Kernelが新しいLinuxではVMware Workstationのカーネルモジュールがコンパイルできず使えません。古いカーネルを使えばコンパイルできるのですが、新しいカーネルでも使いたいので調べました。

    Fedora42からはカーネルモジュールへのサインも必須になっています。（無効にもできますが、サインするのは簡単）

    (さらに…)

  • docker runやdocker compose upで出来てしまう匿名ボリュームを作るコンテナを見つけるスクリプト

    Dockerfileの中で永続化が必要なディレクトリ（ボリューム）としてVOLUMEを指定すると、-vまたはvolume:で明示的にマウントしないと匿名ボリューム（名前なしのボリューム）が作られます。匿名ボリュームが起動する度に新しく作成されるので放っておくとどんどん溜まります。

    どのコンテナが匿名ボリュームを作っているのかはdocker inspectで判別出来るのですが、何度も、何度も、手動でやっているので今動作しているコンテナ全てのボリュームのマウント状態をダンプするスクリプトを作りました。（コンテナとDockerfileを見つけて明示的にマウントする方法もあるがこの方法は他人が書いたDockerfileだと探すのが面倒すぎる）

    (さらに…)

  • DockerコンテナのXアプリを利用する方法

    なんだかやけに長い説明ばかり検索に引っかかったので書きました。

    Linuxのローカル環境でDockerコンテナ内のXアプリ（GUIアプリ）を利用するには

    $ xhost localhost +

    を実行した後に

    $ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path

    とすれば良いです。

    (さらに…)

  • SELinuxを有効化したままDockerコンテナから/var/run/docker.sockを使用する

    必要になる度に調べているのでメモ。少なくともRHEL系はこれで動くようになるはずです。出来れば/var/run/docker.sockにアクセスが必要なコンテナだけにアクセス許可を与えたいのですが良い方法を思い付きません。それでもSELinuxを無効化するより/var/run/docker.sockだけアクセス可能のする方がホストの安全性は高くなります。そもそもボリューム（ファイル）にアクセスできないとアクセスできないので、ほとんどの環境※では、リスクは大きく増えないでしょう。

    ※ Dockerコンテナを作る人を信用できない場合、無視できないリスクがあります。コンテナ好き勝手に弄られる可能性があります。古いDockerがloopbackでコマンドを受け付けていた時に外部ユーザーから好き勝手にコンテナを弄られる脆弱性がありました。これと同じです。

    (さらに…)

  • Alpine Linux Dockerコンテナ ｰ initスクリプト（OpenRC）によるプロセス管理

    Alpine Linuxは軽量Linuxディストリビューションの一つでカスタムDockerコンテナのベースイメージに使っている人も多いと思います。Dockerコンテナで複数サービスを起動したい場合、プロセススーパーバイザーを使うのが常道です。DJBのdaemontoolsなら小さく軽量で良いのですが、Pythonで実装されたSupervisordは軽量コンテナにする意味を台無しにするくらいに色々インストールする必要があります。

    インストールするパッケージ／プログラム数と管理項目を最小限にしたいミニマリストなら、Alpine Linuxの起動プロセス管理ツールのOpenRC（昔ながらのSysV Initスタイル）を使いたいと思うハズです。私もその一人でしたが、検索してもどう構成すれば良いのかズバリ説明しているページを見つけられませんでした。

    ということで、Alpine Linuxなどに付属するOpenRCを使ったDockerの起動プロセス管理の基本を紹介します。

    (さらに…)

  • LibXMLのエンティティ変換とXXEと…

    今のlibxmlは意図しないエンティティ変換により意図しない情報漏洩などを防ぐ為にエンティティ変換をしない仕様になっています。libxml関数にLIBXML_NOENT（エンティティ変換を行わせる為のフラグ）を渡して処理しないとエンティティ変換が行われません。しかし、例外があります。

    (さらに…)

  • shellスクリプト文字列のエスケープ

    大抵のシェルスクリプトはセキュリティ対策を考慮する必要がないので与えられたパラメーターはそのまま利用されています。シェルスクリプトを利用して権限の無いユーザーが勝手なコマンドを実行できないようにするにはエスケープが必要になります。

    • setuid/setgidをしたシェルスクリプト
    • 信頼できない入力を処理するシェルスクリプト

    このようなスクリプトで

    • sshなどでリモートコマンドを実行するスクリプト
    • 処理を書き出して実行するスクリプト

    この場合はエスケープ（やバリデーション）が必要になります。

    (さらに…)

  • iPhone(iOS)のWi-Fi機能無効化バグ

    Gigagineで比較的珍しいバグが見つかったことを記事にしています。

    「％p％s％s％s％s％n」というSSIDのネットワークに接続すると、iPhoneのすべてのWi-Fi関連機能が無効になってしまう

    https://gigazine.net/news/20210620-specific-network-name-disable-wi-fi-iphone/

    「セキュリティって難しいんだな」と感じるニュースではなく「大手でも基本が出来てないんだな」と思えれば、似たような問題で困ることが無くなります。

    (さらに…)

  • 常識？非常識？プログラムは1文字でも間違えると正しく動作しない

    プログラムのコードを書く場合1文字でも間違えると致命的な問題になる事がよくあります。=< であるべき所を < で条件分岐すると困った事になります。何を当たり前の事を言っているのだ？と思うでしょう。プログラマには常識です。プログラマーは1文字も間違いがないコードを書くために懸命にコードを書いています。

    しかし、プログラムでデータを処理する場合1文字でも正しく取り扱うことができないモノが含まれると正しく動作できない、これは常識でしょうか？それとも非常識でしょうか？プログラマは自分が書いたコードに正しく処理可能なデータであることを保証するコードに（データを検証するコードを記述）しているでしょうか？入力データの検証はアプリケーションでは必須ですが検証できているでしょうか？

    (さらに…)

  • 出力時のフェイルセーフ対策が最も重要なセキュリティ対策であるはずがない

    コンピューターサイエンス・システムエンジニアリングに基づくソフトウェアセキュリティ対策は論理的に構築されており問題ないです。しかし、一般に広まっているソフトウェアセキュリティ対策には出鱈目が普通にまかり通っています。

    その最たる例はCWE-20の出鱈目な紹介や解釈です。

    https://blog.ohgaki.net/jvn-cwe-20

    Terminology

    The “input validation” term is extremely common, but it is used in many different ways. In some cases its usage can obscure the real underlying weakness or otherwise hide chaining and composite relationships.

    Some people use “input validation” as a general term that covers many different neutralization techniques for ensuring that input is appropriate, such as filtering, canonicalization, and escaping. Others use the term in a more narrow context to simply mean “checking if an input conforms to expectations without changing it.” CWE uses this more narrow interpretation.

    太字部分の訳

    他の人々はより狭いコンテクストで”変更しなくても入力が期待に沿うモノかチェックすること”の意味で使用する。CWEはこの狭い意味の解釈を採用している。

    このように現在の本家CWE-20の用語補足では「”変更しなくても入力が期待に沿うモノかチェックすること”の意味で使用」と明記されていますが、CWE-20にエスケープやフィルタリングが含まれる、とする驚くべき解説をする”セキュリティ専門家”が居たりします。（普通は「CWEはこの狭い意味の解釈を採用している」と注釈なくてもそれ以前に解説の文意で判る）

    (さらに…)

  • ユーザーや開発者はIPA・専門家の責任にしてWebアプリなどに”本物”のセキュアコーディングを適用する方がよい

    非エンジニアのユーザーに現在のほぼ全てのWebサーバーは送信されてくるデータが妥当かどうか確認していない、と説明すると驚きます、「そんな仕組みでマトモに動くソフトウェアが作れるのか？」と。当然の疑問でしょう。

    実際、コンピュータサイエンス・システムエンジニアリングの世界では一貫して入力データの妥当性検証を重要なセキュリティ対策として実装するように求めています。

    現在のISO 27000ではセキュアプログラミング技術の採用を要求しています。セキュアプログラミングで最も重要な事は入力データバリデーションです。2013年にISO 27000が改定されるまで、入力データバリデーションだけは具体的な仕様が解説されていました。2013年の改定で普及したので「セキュアプログラミングを採用する」と簡易にされました。（ハンドブックではないJIS Q 27000:2014の冒頭の改定の経緯解説に書かれています）

    (さらに…)

  • JVNのCWE-20の解説が間違っている件について

    以前から気になっては居たのですがJVNのCWE-20の解説ページが出鱈目です。用語の定義が間違っています。もう何年も前から修正されていません。Draftとは言え「セキュアコーディングの第一原則」（IPAは2017年からプログラミング原則としている）入力データバリデーション・入力妥当性チェックの用語定義が間違っているのは致命的な間違いです。

    追記：指摘通りに修正されました

    このブログ最後に記載の通り、メールにて誤りを指摘していました。最初のJVNへのメールから3週間かかりましたが指摘した通りに修正されました。

    標準的な入力バリデーション（入力の妥当性チェック）にはエスケープやフィルタリング、脆弱性を隠すという意味はありません。入力データが形式的に妥当であることを検証するのが入力データバリデーションです。これは70年代のFormal Verificationの頃からの定義です。

    近年になって乱用／誤解／拡大解釈により間違った意味で使われている場合があるので注意が必要です。

    (さらに…)

  • Pharファイルを利用したコード実行 – POP攻撃

    Pharファイルは複数のPHPスクリプトをアーカイブ＆パッケージ化して一つのファイルでアプリケーションとして実行する仕組みです。

    PharファイルはPHPプログラムその物なのでこれを実行してしまうとPHPで実行できることは何でもできてしまいます。そもそもPharファイルはプログラムなので信頼できないPharファイルを実行したらやりたい放題なのに、なぜPharのデシリアライズがセキュリティ問題になるのか？解説します。

    (さらに…)

  • Gnome40の横スライド仮想デスクトップを縦スライドに変更

    Fedora34になりGnome40になった事により、今まで縦スライドで仮想画面がスライドしていたの横スライドする仕様（WindowsやMacOSと同じ）になりました。

    これがどうにも使いづらい。今の横長モニターなら「これでしょ？！」と思います。

    (さらに…)

  • Linuxのネットワークプリンタに印刷できない

    Fedora 33にアップグレードした時にも直したのですが、Fedora 34でも同じように今まで使えていたネットワークプリンタがアップグレード後使えなくなりました。

    原因

    デフォルトのnsswitch.conf設定だとmDNSを参照しないで名前解決する事が原因。

    (さらに…)