サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
blog.mono0x.net
Linuxのセキュリティ周りを拡張するフレームワークであるLinux Security Modules(LSM)を作ってみます。LSMはSELinuxやTOMOYO Linuxの実装に使われており、LSMを利用することでシステムのさまざまな部分をフックしてアクセス制御などの処理を実現することができるようになります。 とりあえず以下の記事にあったLSMのスケルトンを実際にUbuntuに組み込んでみたのでメモしておきます。 Writing a Skeleton Linux Security Module | recluze インストール カーネル構築の準備 必要なツールとカーネルのソースコードをインストールしておきます。 cd /usr/src sudo apt-get install -y build-essential libncurses-dev ncurses-dev kernel-p
nginx 1.9.1の紹介記事を読んでいて、昔悩んでいたThundering Herdの話を思い出したので書いてみます。 Thundering Herdというのは、ひとつのソケットに対してselectやepollのような通信可能になるのを待つシステムコールを利用して複数のプロセス (またはスレッド) が待機していると、通信可能になったときに本来ならひとつのプロセスだけが起きればいいところを、待機していたすべてのプロセスが起こされてしまうという問題です。この場合、実際に通信できるのはたまたま最も早く通信を開始したプロセスのみで、他のプロセスが起きたことは無駄になってしまいます。 SO_REUSEPORTを使うと、ひとつのソケットに対してひとつのプロセスだけが通信可能になるのを待つことができ、カーネルは同じポートを見ているソケットの中からひとつだけを選択してくれるようになります。これにより、
ポケモン界隈で使われる用語が英語だとどうなるのか調べてみました。 変数名などを決めるときにどうぞ。 ステータス 日本語English
XSSやクリックジャッキングなどの攻撃を軽減するContent Seucrity Policy (CSP)を紹介します。Google Chromeの拡張機能でもそろそろ有効化されそうですし、学ぶにはよいタイミングなのではないでしょうか。 Content Security Policyでは、読み込み可能なリソースをホワイトリストで制限することで、悪意ある攻撃者によって予期しないリソースを読み込まされることを防ぎます。従来は、scriptタグを挿入することで外部のスクリプトを自由に実行できてしまうなんでもありの状態でしたが。Content Security Policyを利用すると細かなアクセス制御が可能になり、許可したスクリプトだけを実行できます。攻撃者が用意したスクリプトをできなくなれば、攻撃の幅は大きく狭まります。 Content Security PolicyはFirefox 4以降や
最近、個人的に数百MBから数GBクラスのテキストファイルを扱う機会が増えています。これくらいのサイズだと、手元のマシンだけで十分対応可能な範囲ではあるのですが、扱いを間違えると時間が掛かってつらいことになります。結論から言うと、とにかく LC_ALL=C を指定しようというのと、OS X であれば初めから入っているコマンドではなく最新の coreutils を使おうという2点なのですが、それだけ終わってしまうとあんまりなので、手元の環境で計測した数字を出しつつ紹介したいと思います。 なお、この記事中の速度計測はクアッドコアの Core i7 (2.2GHz) を搭載した MacBook Pro 15インチ (Mid 2014) で行いました。OS は OS X El Capitan です。テスト用のデータは以下のようなコマンドで生成しました。 % perl -e 'for (1..2**2
Java 8ではラムダ式、Stream、Optional、インタフェースのデフォルト実装などなど、大量の新機能が追加されました。新機能を知らないという方は以下が参考になるかと思います。 JDK 8の新機能 大刷新リリース Java 8の新機能 こうした情報を見て、少なくとも私はJavaの時代が来たんじゃないかという印象を持ちました。もちろん、私の大好きなC#や人気のScalaと比べてしまうと、言語仕様の強力さ、記述の美しさでは劣ります。しかし、少なくとも現状ではWindows以外で使うならC#よりJavaですし、Scalaは一部の人が盛り上がっているという印象で、言語仕様以外の部分ではJavaに分があると思うのです。言語仕様の差が以前より縮まった現在、総合的に見ればJavaは選択肢に入るどころか、最強と言ってもいいのではないでしょうか。 とはいえ、使わずにどうこう言っても仕方ないので、実際
ついに Let’s Encrypt の Public Beta が始まりましたね。私は Closed Beta の時から参加していて、このサイトも HTTP からのリダイレクトはしないけど HTTPS でも見れるという状態にはしてあったのですが、Public Beta になったということで、リダイレクトするようにして HSTS も設定してみました。 ということで、Let’s Encrypt を導入してサイトを HTTPS 化する中でわかったことを書いておきます。 証明書の発行・更新 手順に沿ってやれば証明書を発行してもらうこと自体は簡単です。しかし、Let’s Encrypt の証明書は有効期限が3ヶ月しかありません。これは beta だからというわけではなく、自動更新することを前提としているためだそうです。手動で頑張れなくも無い間隔ではありますが、面倒ですし、忘れる可能性もあるので自動化
SO_REUSEPORTが盛り上がっているみたいですね。 私はコミットログを読んで性能向上のための機能だと認識していて、親プロセスが開いたソケットのfdを子プロセスが使うpreforkのモデルに代わって、子プロセスがそれぞれソケットを開いて使うものだと思い込んでいました。そのため、まったく関係のないプロセスがbindしているポートに対して追加でbindできてしまうというのはなかなか驚きでした。 ただ、何も制限なしにbindできてしまったら、悪意のある何者かが同じ計算機内のすでに使われているポートにbindすることで、一定確率で外部からの通信を奪い取ることができてしまいます。何か制限があるはずだと思い、ソースコードを眺めてみました。 真面目に追い掛けたわけではありませんが、ざっと見たところ、おそらくこの関数で判定しているはず。 int inet_csk_bind_conflict(const
先日、Greasemonkey 2.0がリリースされました。 このバージョンには、2つの後方互換性のない変更が存在します。 1つ目に、@grant noneモードがデフォルトになりました。以前のバージョンでは、GM_プレフィックスのAPIは何もしなくても利用可能になっていましたが、2.0ではすべてのAPIがデフォルトでは使用できません。 使用したい場合には、Metadata Blockに@grantを記述し、APIの使用許可を得る必要があります。 2つ目に、Webページ (Content Page) のJavaScriptとUserScriptの実行コンテキストが分離されました。UserScriptからunsafeWindowを利用してContent Pageにアクセスすることは従来通り可能ですが、Content PageからUserScriptにはアクセスできません (2014-07-2
前回の記事のはてブのコメントでrack-protectionについての言及がないというご指摘をいただきました。恥ずかしながらrack-protectionについては知らなかったので、少し調べてみました。 rack-protectionは、CSRFやXSSをはじめとした攻撃に対処するためのRack middlewareです。アプリケーションを起動する前にuse Rack::Protectionを呼び出して組み込むことですべての機能を簡単に利用できます。 require 'rack/protection' use Rack::Protection run App ただ、rack-protectionが何をしているのか把握していないとはまりそうな部分もいくつかあるので、導入前に各機能の概要を理解しておいたほうがよいでしょう。 rack-protectionが実現している機能は以下の通りです。 C
RubyでWebアプリケーションを作るときにセキュリティ関連でやっておくべきことのメモです。 以下の4つの問題について、Sinatra・Hamlを使っている環境(うちの環境)での対策方法を説明しています。それぞれの問題についての詳細はここでは触れないので、徳丸本を読むとよいと思います。 XSS CSRF クリックジャッキング IEのsniffing XSS対策 エスケープ漏れを防ぐ きちんとエスケープをする、というのは言葉にすると簡単ですが手作業で実現するのは極めて困難です。まともなテンプレートエンジンにはエスケープを自動で行う機能が付いているのでそれを利用しましょう。エスケープを自動化することで、デフォルトでエスケープを行い、指定があった場合のみエスケープしないようにすることができ、エスケープ漏れを最小限に抑えられます。 app.rb class App < Sinatra::Base
更新しました。 JavaScriptで一時的にスクロールを禁止する その2 Lightbox的なものを表示しているときに、Lightboxの中身をスクロールさせると端に到達したときスクロールが親要素に伝搬してしまう問題があります。小さな点ですが、どこまで読んでいたのか見失ってしまうので結構鬱陶しいですね。 そこで、Lightbox的なものを表示している間一時的に親要素のスクロールを防止する方法を調べてみました。 何を言っているのか分からないと思うので、デモを用意しました。まずはこちらをご覧ください。 デモ 実現方法 スクロールを禁止させるときはこんな感じ。スクロールバーを残したまま画面に固定し、スクロールしていた量だけ表示位置をずらして辻褄を合わせています。例ではスタイルの設定はクラスの付け外しで済ませています。 var scrollTop; scrollTop = $(window).s
私が運用しているWebアプリ (Perfume Headlineとかこのブログとか) で使っているライブラリなどを紹介します。つまり、最近とは最近流行りという意味ではなく、あくまで最近私が使っているという意味に過ぎません。あしからず。 紹介するのは以下のものです。こうやって並べるとほんとにたくさんのソフトウェアに支えられていることがわかりますね。感謝しながら使いたいですね。 Webアプリケーションフレームワーク Sinatra データベース SQLite DataMapper テンプレートエンジン Haml Sass Compass アセット管理 sprockets sprockets-sass sprockets-helpers 管理用コマンド Thor バッチ rufus-scheduler プロセス起動 foreman 死活監視 daemontools デプロイ Git Webサーバ
netfilterは、LinuxカーネルのネットワークスタックのいろいろをフックしてあれこれするためのAPIです。身近なところだと、iptablesやnftablesの実装に利用されています。カーネル内のAPIなので敷居が高そうに思われるかもしれませんが、簡単なLoadable Kernel Module (LKM) を書くだけで利用でき、カーネルに直接変更を加える必要がないので、かなりお手軽です。それでいて、iptablesやnftablesでも利用されているだけあってできることの範囲は広く、パケットの監視やファイアウォールを始めとしてパケットを読み書きするような処理なら割と何でもできます。 この記事では、netfilterを使うカーネルモジュールの基本的な書き方を紹介します。なお、動作確認はKernel 3.14で行いました。カーネルのバージョンによってメンバや定数の名称が変化している
ここのところ、PCでメモリ不足を感じることもすっかりなくなりましたね。 しかし、安価なVPSやIaaSを使おうとすると、メモリ不足に悩まされることが少なくありません。 CPUやストレージが有り余っている状態で安易にスペックを上げるのは負けた気がするので、zramを導入して状況の緩和を図ることにしました。 zramは、メモリ上に圧縮された仮想ブロックデバイスを構築するLinuxカーネルの機能です。 zramのデバイスをswap領域に設定することで、スワップアウト時にデータが圧縮され、実際のメモリの大きさよりも多くの情報をメモリ上に置けるようになります。 データを圧縮、展開するコストは発生しますが、ディスクI/Oのコストと比べれば微々たるものなので、性能向上が見込めるというわけです。 zramを導入する前の私のサーバはこんな状態でした。 メモリを1GBしか搭載していないにもかかわらず、メモリ使
このページを最初にブックマークしてみませんか?
『monolithic kernel』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く