Engineers

Vue関連の書籍を読んだ

最近、Vue関連の書籍を読みましたのでその紹介です。

Webサービスを作るにあたり、フロントエンドの処理のためにVueを採用することにしたので、 その勉強のために読みました。

読んだのは以下の3冊です。 どの本も2020年にリリースされたVue.js3に対応しています。

  • Vue.js3 超入門
  • これからはじめる人のJavascript/Vue.jsの教科書
  • みんなのVue.js

Vue.js3超入門はVue.jsについて一通り説明されていて、Vue.jsについて知るのに良いと思います。
これからはじめる人のJavascript/Vue.jsの教科書は、JavascriptとTypescriptについても説明があります。
Vue.js3超入門よりも薄いので、ボリュームは少な目ですが、広く浅くという感じで記載があります。
みんなのVue.jsはVue.jsを知っている人向けに、実装時の注意点や考え方などが記載されています。例えば、国際化対応についての記述があります。

read more
Engineers

VS Codeで利用するGoのバージョンを指定する方法

VS CodeのGo拡張機能を利用していると、新しいバージョンのgoがありますと良く言われます。 新しいバージョンを使うには以下の2通りの方法が考えられます。

  1. 古いバージョンを新しいバージョンで上書きする
  2. 古いバージョンを残したまま新しいバージョンを別名で用意する

後者の別名を用意する場合、どのバージョンを使うかをどこかで明示的に指定する必要があります。 プロジェクト毎にバージョンを指定する場合はgo build する際のコマンド指定で対応しても良いかもしれませんが、 一括で変更するには、VS Code側（Go拡張機能）で設定することもできます。 以下のようにsettings.jsonに記載することで使うバージョンを指定できます。

"go.alternateTools": {
    "go": "/home/user/go/bin/go1.16.2"
},

肝心の別名での用意の仕方は以下です。

go install golang.x/dl/go1.16.2
go1.16.2 download
read more
Engineers

Let's Encryptの証明書を使っているサーバにcURLで接続してもSEC_ERROR_UNKNOWN_ISSUERで失敗しません

body of this entry

以前書いた記事、Let’s Encryptの証明書を使っているサーバにcURLで接続するとSEC ERROR UNKNOWN_ISSUERで失敗するですが、Let’s Encryptは悪くなかったです。自分のWebサーバの設定が悪かったです。

Nginxを使っていて、サーバ証明書にcert.pemを指定していましたが、fullchain.pemを指定するのが正しいようです。証明書と同じフォルダにあるREADMEを見ても、cert.pemは古いので使われないということが書いてありました。 完全に動かないということではないようで気づきませんでした。

read more
Engineers

セキュリティガイドラインの一覧

最近、セキュリティの勉強をしているのですが、世の中にはセキュリティガイドライン（セキュリティ基準、参照すべきセキュリティ文書）がたくさんあって簡単には覚えられないので、自分で列挙しながら調べることにしました。 ただし、ガイドラインそのものは基本的に読めていません。 なお、本記事は随時更新します。

ISO/IEC 27000シリーズ

ISMSとしても知られるマネジメントについての規格。

ISO/IEC 27001

組織の ISMS を認証するための要求事項

ISO/IEC 27002

情報セキュリティ管理策の実践のための規範 ISO/IEC 27001に対して具体的な内容となっていて、27001は要求事項であり、27002は実践の要領などが記載されている。

ISO/IEC 27017

ISO/IEC 27002 に基づくクラウドサービスのための情報セキュリティ管理策の実践の規範 クラウドサービスの提供者側、利用者側に対するセキュリティ基準。

NIST SP 800シリーズ

NIST（米国国立標準技術研究所）が公開している情報セキュリティの文書群。

NIST SP 800-18

連邦情報システムのためのセキュリティ計画作成ガイド

NIST SP 800-30

リスクアセスメントの実施の手引き 数少ないらしい？リスクアセスメントに関する文書。

NIST SP 800-34

ITシステムのための緊急時対応計画ガイド

NIST SP 800-37

連邦政府情報システムに対するリスクマネジメントフレームワーク適用ガイド： セキュリティライフサイクルによるアプローチ 同様の文書として、COSOの「Enterprise Risk management - Integrated Framework」というものがある。

NIST SP 800-53

連邦政府情報システムおよび連邦組織のためのセキュリティ管理策とプライバシー管理策

NIST SP 800-57

鍵管理における推奨事項

NIST SP 800-61

コンピュータインシデント対応ガイド

NIST SP 800-63

電子的認証に関するガイドライン 上位ポリシーとして、OMB M-04-04がある。

NIST SP 800-64

システム開発ライフサイクルにおけるセキュリティの考慮事項

read more
Engineers

GoのEchoフレームワークのsessionの無効化

GoのWebフレームワークのEchoを使っています。Echoにはミドルウェアとしてsessionというものがあり、これを使ってセッション管理を行うことができるようになっています。 このsessionミドルウェアはバックエンドとして、gorilla/sessionsを使っています。

この仕組みを使ってセッションを実装したときに、クライアントのクッキーにセッション情報が記録されます。 これをサーバ側で無効にしたい場合等に、セッションキーをサーバ側で変えてしまうということができます。 セッションキーを変更した後で、クライアントが接続すると古いセッション情報を使うために、これは無効と判定されます。 このとき、実現したい挙動としては、古いセッション情報をクッキーから削除して新しいセッション情報を作成できるようにすることです。

Echoでは、以下のような書き方でセッション情報を取得することができます。 しかし、Getに対応するDeleteというような関数は用意されていません。

sess, err = session.Get("session", c)

セッションが存在しない場合（新規の場合）は、session.Get()でセッションが新規作成されますが、無効なセッション情報である場合には、session.Get()の結果エラーとなり有効なセッション情報が得られません。 そのため、無効なセッション情報は削除してからsession.Get()を実行する必要があります。 session.Get()がエラーになった場合に削除するということも考えましたが、処理を継続したい場合はsession.Get()より前に削除してある必要があります。 処理を継続できなくて良い場合は、削除後に再度HTTPリクエストを出してもらうように促すことで対処できます。

削除の方法として、HTTPレスポンスを返す以外に、JavaScriptで削除する方法も考えられますが、HTTP Only属性を有効にすべき種類のものなのでこれはできません。 そのため、HTTPレスポンスとしてクッキー削除のヘッダを返すことで削除する方法を採用します。 このとき注意が必要なのが、HTTPレスポンスのキャッシュです。 キャッシュが有効になっていると、HTTPクライアントはコンテンツのみをキャッシュから読み込み、HTTPヘッダによるクッキー削除が行われません。 そのため、クッキー削除のヘッダを付ける可能性のあるURLはキャッシュ無効のヘッダも併せて返す必要があります。

つまり、以下のようなヘッダを返す必要があるということです。 もちろん、動的に生成するページの場合はCache-Controlヘッダを付けなくてもキャッシュされないので、Cache-Controlヘッダは不要です。

Cache-Control: no-store Set-Cookie: session=; Path=/; Max-Age=0

もし、ほかに良いやり方があるようでしたら教えてもらえると嬉しいです。

read more
Engineers

Let's Encryptの証明書を使っているサーバにcURLで接続するとSEC_ERROR_UNKNOWN_ISSUERで失敗する

Let’s Encryptの証明書を使っているサーバにcURLで接続するとSEC ERROR UNKNOWN_ISSUERで失敗する場合がありました。 ROOT CAは信頼済みになっていますが、中間証明書を信頼できずに失敗していました。 なお、Widows上のGoogle Chromeからは問題ありませんでした。

curl -vの結果は以下のようになっていました。

* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: cacert.pem
CApath: none
* Server certificate:
*       subject: CN=www.sei-yo.jp
*       start date: Jul 25 15:26:52 2020 GMT
*       expire date: Oct 23 15:26:52 2020 GMT
*       common name: www.sei-yo.jp
*       issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
* NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER)
* Peer's Certificate issuer is not recognized.

中間証明書は以下にあります。

https://letsencrypt.org/ja/certificates/

https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt

read more
Engineers

Linux Kernelが対応していないUSBデバイスを使用する方法

ここで言うLinux Kernelが対応していないUSBデバイスというのは、デバイスのベンダーID（VID）とプロダクトID（PID）がカーネルのドライバが知らないために、ドライバはあるのにデバイスを認識しないということになってしまうデバイスのことを指します。 つまり、ドライバが知らないVID、PIDのUSBデバイスを使用する方法ということです。 以下の二つがあります。一つ目しか知らなかったのですが二つ目を知って便利になったのでここに書きます。

  • ドライバをコンパイル
  • ドライバに/sys のnew_idを使ってIDを伝える

ドライバをコンパイル

私の知る限り、USBデバイス用のドライバは通常、いくつかの（と言っても多数の）VIDとPIDの組み合わせを知っています。そしてその情報はソースコードに埋め込まれています。そのため新しいUSBデバイスに対応するためにはソースコードの修正を行って、コンパイルして利用する必要があります。 Linux Kernelに付属のドライバを使う場合には、以下の記事にあるような方法でコンパイルして利用する必要があります。しかし、Linux Kernelに付属のドライバはKernelバージョン毎にあるためKernelのアップデートをする度にドライバのコンパイルが必要になってしまいます。

WLI-UC-GNでhostapd 使ってAP化に成功

Kernel アップデートの度にコンパイルするのはかなりの手間なのでこれを防ぐには、Kernelのアップストリームに取り込んでもらう手があります。修正内容としてはVIDとPIDが列挙されている個所に1つ追加するだけなので軽微ですが、Linux Kernelの修正の流儀がわかっておらず依頼していません。

ドライバに/sys のnew_idを使ってIDを伝える

ドライバに動的にVID PIDを伝えることでデバイスを使えるようにする方法があります。 /sys/bus/usb/drivers/の下にドライバ名のディレクトリがあればその下のnew_idにVID PIDを書き込みます。 するとドライバがそのデバイスを利用可能にしてくれます。 ドライバ名のディレクトリがない場合は該当のドライバが読み込まれていないのでmodprobeコマンドで読み込む必要があります。

echo "0411 014F" > /sys/bus/usb/drivers/rt2800usb/new_id

modprobeコマンドで読み込むのを自動で行うには/etc/modulesファイルにドライバ名を書きます。 また、/etc/modprobe.d/の下に拡張子を.confにしたファイルを置いて以下のように書くとOS起動時に上記コマンドまで実施してくれて便利です。

install rt2800usb /sbin/modprobe -i rt2800usb; echo "0411 014F" > /sys/bus/usb/drivers/rt2800usb/new_id
read more
Engineers

Nginxでのレスポンスボディの書き換え

Nginxでのレスポンスボディの書き換え方法を調べていたら、HTTP Substitutions Filterというのがあったので、Nginx Plusで使うかモジュールコンパイルして使うしかないのかと思っていたら、sub_moduleというモジュールがsub_filterディレクティブを提供していてこれで実現可能でした。

ちなみにApache2の場合にはExtFilterというのがあって、ここで好きなプログラムを使って自由にレスポンスを書き換え可能です。 Nginxのsub_moduleの場合は変数は利用可能であるものの単純な文字列の置換しかできないようです。HTTP Substitutions Filterの場合は、正規表現も使えるようです。 外部コマンドを使った書き換えを簡単に定義するものはないのでしょうか。

read more
Engineers

vagrant failed with "`chmod': Operation not permitted @ chmod_internal - /home/user/.vagrant.d/insecure_private_key (Errno::EPERM)"

vagrant コマンドを実行すると以下のエラーが出て失敗しました。

/usr/lib/ruby/vendor_ruby/vagrant/environment.rb:858:in `chmod': Operation not permitted @ chmod_internal - /home/user/.vagrant.d/insecure_private_key (Errno::EPERM)
        from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:858:in `chmod'
        from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:858:in `copy_insecure_private_key'
        from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:152:in `initialize'
        from /usr/bin/vagrant:169:in `new'
        from /usr/bin/vagrant:169:in `<main>'

environment.rbを見てみると、chmod で 0600 にしようとして失敗しているようです。 /home/user/.vagrant.d/insecure_private_key はvagrantコマンドを実行するユーザのオーナーになっていなかったために失敗していたので、オーナーを変更することでエラーなく実行できるようになりました。

read more
Engineers

SELinuxの使い方の概要（RHEL7のガイドの要約）

RHEL7のドキュメントである、「SELINUX ユーザーおよび管理者のガイド」を読んでSELinuxを勉強しながら、今後使いそうな部分の内容を整理したものです。

はじめに

  • SELinuxによるアクセス制御は、Mandatory Access Control（MAC）を実装したもの。ほかに、従来からあるユーザとグループとディレクトリやファイルのモードによるものはDiscretionary Access Controlがある。
  • SELinuxのポリシールールは、DACの後に適用されるため、DACで拒否するものにはSELinuxのポリシールールは適用されず、SELinuxのログにも残らない。
  • SELinuxのポリシールールは、SELinuxコンテキストというラベルを使って記述する。SELinuxコンテキストは、それぞれのプロセスやシステムリソースに割り当てられる。
  • SELinuxコンテキストには、次のフィールドがある。：ユーザー、ロール、タイプ、セキュリティーレベル
  • このうち、タイプの利用頻度が高い。タイプは、通常_tで終わる名前を持つ。なお、タイプのことをタイプコンテキストと呼ぶ。ほかにドメインと呼ぶ場合もある。

SELINUX コンテキスト

  • SELinuxステータスの確認方法：sestatus
  • ロールの定義はプロセスのみ有効で、ファイルに対しては無効。

ターゲットポリシー

  • SELINUX を使った作業 ====================

SELinuxを使った作業

  • ブール値の一覧出力：getsebool -a semanageコマンドをインストールしておくと、説明付きで表示できたりするので便利。 ブール値は特定の用途毎にonかoffかの設定があり、これを変更するだけでSELinuxのポリシーを変更できる。
  • ブール値の設定：setsebool -P パラメータ名 {on|off} -Pは恒久設定にするためのオプション。-Pがない場合は再起動後は変更前の状態になる。
  • 一時的なファイルコンテキストの変更：chcon -t タイプ ファイル名 一時的な変更として変更可能。-Rはrecursive。
  • ターゲットポリシーによるファイルコンテキストの変更：restorecon -v ファイル名 /etc/selinux/targeted/contexts/files/にあるファイルに従ってコンテキストを復元する。-vはverbose。
  • ターゲットポリシーの変更：semanage fcontext -a -t タイプ ファイルのフルパスまたは"正規表現" ターゲットポリシーを変更するだけで、ファイルのコンテキストは変更しない。restoreconで適用する。-aはコンテキストの新規追加。 なお、ファイルのコンテキストは基本的に親ディレクトリのコンテキストを引き継ぐ。
  • ターゲットポリシーからの削除：semanage fcontext -d パスまたは"正規表現" なお、semanageはsetfilesコマンド等を利用している。
  • コンテキストのマウント：mount -o context=SELinux_user:role:type:level ここで指定したコンテキストはファイルシステムに対して変更されず、一時的なものとして利用できる。 拡張属性（EA）に対応していない（コンテキストの記録ができない）場合にも利用可能。 この場合は、chconによるコンテキスト変更はできない。
  • コンテキストを含めてファイルをコピー：cp –preserve=context オプションがない場合は、通常のターゲットポリシーに基づき設定。通常は親ディレクトリを継承。
  • コンテキストを指定してファイルをコピー：cp –context=system u:object r:samba share t:s0
  • ファイル、ディレクトリの移動：mv 移動時はコンテキストが維持される。そのため、ターゲットポリシーに合わずアクセスできない場合が多い。
  • ターゲットポリシーと実際のファイルの比較：matchpathcon -V ファイル 差分を表示する。適用する場合はrestoreconを使う。
  • コンテキストを維持してtarする：tar –selinux オプションがない場合はコンテキスト情報は失う。
  • tarの展開時にターゲットポリシーを適用する：tar -xvf archive.tar | restorecon -f -
read more