懇親会
そして、懇親会へ移動。
特にお世話になった人に対して、id:haradatsさんから一人一人、
捻りの聞いたお礼の言葉と共に感謝状を贈っていた。
会場では、日本SELinuxユーザ会の草創期に活躍されていた懐かしい人にもお会いする。
そしてまぁ、次にメインライン化すべき大物と言えばもちろん、SE-PostgreSQLだよな。。。
と、決意も新たに帰宅の途へ。
帰り道、挽き肉と玉ネギとデミソースを購入して明日の食材の準備。
そして、懇親会へ移動。
特にお世話になった人に対して、id:haradatsさんから一人一人、
捻りの聞いたお礼の言葉と共に感謝状を贈っていた。
会場では、日本SELinuxユーザ会の草創期に活躍されていた懐かしい人にもお会いする。
そしてまぁ、次にメインライン化すべき大物と言えばもちろん、SE-PostgreSQLだよな。。。
と、決意も新たに帰宅の途へ。
帰り道、挽き肉と玉ネギとデミソースを購入して明日の食材の準備。
本日は恵比寿のSGIホールでTOMOYO Linuxメインライン化記念勉強会&懇親会。
まっちゃだいふくさんから、本日の進行についての説明と、
日本各地のセキュリティ勉強会コミュニティの紹介
ちなみに、タイムテーブルはこんな感じ。
平日の16:00〜というアグレッシブな時間設定にも関わらず、
ざっと100名以上は参加して頂けたように思える。
続いて、某社の小崎さんによる基調講演。
高橋メソッド初挑戦とのことだが、相変わらずテンポのよい喋り。
続いて、本日の主役、TOMOYO Linux Projectの原田さん。
プロジェクトの歴史を振り返りつつ、カーネル2.6.30でのメインライン化に至るまでの道程を
振り返る。やっぱ、メインライン化を決意してから2年以上の歳月が流れてて、オタワや
カリフォルニアやホバートに飛んでTOMOYO Linuxをアピールし続けてきて、やっと認められる
までの長い道程は一つの歴史だね。
TOMOYO Linuxコングラチュレーションの寄せ書き。
本日の勉強会&懇親会に参加の皆さんに書いてもらいました。
続いて、同じくv2.6.30でマージされたNILFSの発表。
サーセン、いい写真が撮れなかったw
3年前のOSDL(当時)のBoFでAndrew Mortonの前で発表してたのを俺も覚えてる。
こっちも長かったなぁ…。
もう一つ、v2.6.30でマージされたLIM/IMAの紹介を宗籐さんから。
これは、プログラムの改ざん検知機能で、TPMと連携してTrusted Chainを作るためのモノ
続いて、俺の発表。(当然、写真はない)
資料は近々TOMOYO Linuxのwikiで公開されると思うので、しばし待たれい。
タイトルは「強敵よ!〜SELinuxとの比較〜」となっているが、「強敵よ!」の部分の
読み方は、当然「ともよ!」です。反論は認めません。
内容自体は、SELinuxとTOMOYO Linuxの比較、、、よりもむしろ、互いのバックボーンと
なっているリファレンスモニタの考え方を紹介するのが中心に。
それと、セキュリティポリシーに対する考え方を突き詰めていくと
みたいになってそれはそれで面白いという結論に。
タイムキーパーをお願いしていたid:hshinjiさんが「1分」というのを掲げるのとほぼ同時に
喋りは終了。最近の俺、時間ぴったり行きすぎじゃね?
勉強会の締めは吉岡さん。
by Jeronimo Zucco (jczucco@gmail.com) at July 01, 2009 02:57 PM
数日前にTOASTメカニズムで書いたように、PostgreSQLの現在のLargeObjectの実装とTOASTメカニズムの仕組みは非常に似通っている。
まず、テーブル定義。TOASTテーブルとpg_largeobjectは非常に似通った構造を持っている。
pg_toast_%u (
chunk_id oid,
chunk_seq int4,
chunk_data bytea,
unique(chunk_id, chunk_seq)
)
pg_largeobject(
loid oid,
pageno int4,
data bytea,
unique(loid, pageno)
)
データ構造が似ているという事はやっている事も似通っており、利用者から長大なデータが渡されると、これを固定長のチャンク/ページに分割してこれを保存する。
ラージオブジェクトの場合、loread()やlowrite()を通じて、分割されたページ群の一部だけを参照/更新する事ができる。しかし、TOASTデータを参照/更新する場合には、分割されたチャンクを一度オンメモリで再構成してから利用者に返すため、1Gとか非常に大きなデータをBYTEA型で保持する事は現実的でない。
ラージオブジェクトのように、TOASTデータの一部だけを参照/更新するインターフェースを持つことは非常に有用な事である。
一方、TOASTデータの格納には幾つかモードがあり、単純にラージオブジェクトのインターフェースを持ってくるわけには行かない事情がある。
一つは、データの圧縮。TOASTデータをDBに書き込む場合、TEXT型やBYTEA型の場合は内部的に圧縮処理を行ってから書き込むため、ディスク消費を抑えられる反面、オフセット値からどのチャンクを参照すればよいのか特定できない。
もう一つは、TOASTデータのインライン化。TEXTやBYTEAを含むテーブルであっても、タプルの長さが十分に小さい時は、TOASTテーブルを利用せず、可変長データをタプルに押し込んでDBへと書き込みを行う。その場合、TOASTデータの一部を更新することは(タプル全体を再構成しなければ)不可能である。
従って、ラージオブジェクト風のインターフェースをTOASTデータに適用する場合には、データ型が以下の条件を満たしている必要がある。
このような戦略はまだ実装されていないので、データのTOAST化を行う際に『常に非圧縮でTOASTテーブルを利用する』という戦略を用いるデータ型BLOBを提供するという方針で開発をすすめる。
ざっくり見た感じ、inv_read()相当の処理は既にTOASTの実装にあるので、あとはinv_write(), inv_truncate()相当の処理を入れて、ラージオブジェクトのディスクリプタとの関連付けをやるようにすれば、結構、簡単にできるように思える。
The next openSUSE version is in the queue, milestone 3 of 11.2 was already released during LinuxTag last week.
We try to make 11.2 more SELinux-enabled than before. When you watch the security:SELinux (account needed) repository you may have recognized some changes during the last days. What did we changed so far:
So far it is still needed to install the packages, adding the boot-parameters (selinux=1 enforcing=0), and to make the directory /selinux (we don't want to pack this dir in a package - FHS).
What is on our TODO list:
by Dominick "domg472" Grift (noreply@blogger.com) at June 29, 2009 08:15 AM
When you use our open build service (OBS) and build packages on your local machine, code from the network is executed as root. This is ok as long as you trust the packages.
If you do not want the code to be executed with full access to your local files then you can use KVM.
Add the following lines to you ~/.oscrc:
[general]
build-type=kvm
build-device=/tmp/KVM.root
build-swap=/tmp/KVM.swap
build-memory=254
> dd if=/dev/zero of=/tmp/KVM.swap bs=1024 count=300000
> qemu-img create /tmp/KVM.root 6G
> su -c "mkfs.ext3 -c /tmp/KVM.root "
Now you can use osc build without caring too much about your local security.
Thanks to Adrian to bringing this up.
PostgreSQL雑記―透過的なデータ暗号化 (案)についてコメント。
少し長くなるので、別個にエントリーを作ってみた。
セキュリティ、監査、改竄防止、アクセス制御、情報漏洩防止、暗号化……この辺りはデータベースでどうすれば良いかを聞かれることは多いものの、「そもそも何を守りたいのか?」と突っ込むと、いまいち明確な答えが得られないので後回しになっていました。
この辺は、各々のセキュリティ機能が保護すべき対象、脅威、およびその前提条件を明確化して、それが以下のどの特性にマッピングされるかという事を考えるとクリアになるように思える。
では、PostgreSQLに暗号化タイプを導入するという事は、何を意味するのだろうか?
保護すべき対象は、明らかにDBに格納される情報資産であり、機密性を守ろうとしている。
(このプロポーザルでは完全性の保護は対象ではないようだ)
では、何からそれを守りたいのか?その前提条件は何なのか?
通常、利用者があるオブジェクトにアクセスするには、オブジェクトマネージャにリクエストを発行する。
オブジェクトがDB上のレコードである場合、利用者はPostgreSQL(オブジェクトマネージャ)にSQL(リクエスト)を発行するし、ファイル(OSの管理下)にアクセスする時はシステムコールを利用する。
一方、このような正当な手段を介さないアクセス方法も存在する。
例えば、PostgreSQLが作成したファイルはOSのファイルシステム経由で読み書きできるし、OSのファイルはHDDを抜いてバイナリダンプすれば誰にでも読むことができる。
暗号化を用いる場合、こういった非正規なアクセス方法であっても情報の機密性を守れるという特性がある。
その一方で、アクセス制御とは異なり、開示範囲を柔軟に定めるという用途には向いていない。
例えば、利用者Xは情報A,Bを参照可能であり、かつ、利用者Yは情報B,Cを参照可能であるといった用途には不向き。
したがって、暗号化の利用に関しては、オブジェクトマネージャの提供する正規の方法以外でのオブジェクトへの参照という事で位置付けを明確化すれば良いように思う。
単純にディスク(物理層)を攻撃された場合だけでなく、あるアプリが保持すべきデータの永続的ストレージとしてDBを利用している場合に、当該アプリを介さない参照を防ぐというような利用シーンまで広げると良いかと思う。
(ディスクの問題であれば、OSの暗号化ディスク機能を使えば済む話だし…。)
I’ve just filed Debian bug report #534534 about Valgrind/Helgrind reporting “Possible data race during write” [1]. I included a patch that seems to fix that problem (by checking whether a variable is not zero before setting it to zero). But on further testing with Valgrind 3.4.1 (backported from Debian/Unstable) it seems that my patch is not worth using, I expect that Valgrind related patches won’t be accepted into the Lenny version of OpenSSL.
I would appreciate suggestions on how to fix this, the problem is basically having a single static variable that is initialised to the value 1 but set to 0 the first time one of the malloc functions is called. Using a lock for this is not desirable as it will add overhead to every malloc operation. However without the lock it does seem possible to have a race condition if one thread calls CRYPTO_set_mem_functions() and then before that operation is finished a time slice is given to a thread that is allocating memory. So in spite of the overhead I guess that using a lock is the right thing to do.
deb http://www.coker.com.au lenny gcc
For the convenience of anyone who is testing these things on Debian and wants to use the latest valgrind, the above Debian repository has Valgrind 3.4.1 and a build of GCC to fix the problem I mentioned in my previous blog post about Valgrind [2].
if (default_RSA_meth == NULL)
default_RSA_meth=RSA_PKCS1_SSLeay();
I have also filed bug #534656 about another reported race condition in the OpenSSL libraries [3]. Above is the code in question (with some C preprocessor stuff removed). This seems likely to be a problem on an architecture for which assignment of a pointer is not an atomic operation, I don’t know if we even have any architectures that work in such a way.
static void impl_check(void) {
CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA);
if(!impl)
impl = &impl_default;
CRYPTO_w_unlock(CRYPTO_LOCK_EX_DATA);
}
#define IMPL_CHECK if(!impl) impl_check();
A similar issue is my bug report bug #534683 [4] which is due to a similar issue with the above code. If the macro is changed to just call impl_check() then the problem will go away, but at some performance cost.
I filed bug report #534685 about a similar issue with the EX_DATA_CHECK macro [5].
I filed bug report #534687 about some code that has CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA); before it [6], so it seems that the code may be safe and it may be an issue with how Valgrind recognises problems (maybe a Valgrind bug or an issue with how Valgrind interprets what the OpenSSL code is doing). Valgrind 3.3.1 reported many more issues that were similar to this, so it appears that version 3.4.1 improved the analysis of this but didn’t do quite enough.
I filed bug report #534706 about the cleanse_ctr global variable that is used as a source of pseudo-randomness for the OPENSSL_cleanse() function without locking [7]. It seems that they have the idea that memset() is not adequate for clearing memory. Does anyone know of a good research paper about recovering the contents of memory after memset()? I doubt that we need such things.
I filed bug report #534699 about what appears to be a potential race condition in int_new_ex_data() [8]. The def_get_class() function obtains a lock before returning a pointer to a member of a hash table. It seems possible for an item to be deleted from the hash table (and it’s memory freed) after def_get_class() has returned the pointed but before int_new_ex_data() accesses the memory in question.
I filed bug report #534889 about int_free_ex_data() and int_new_ex_data() which call def_get_class() before obtaining a lock and then use the data returned from that function in a locked area[9] (it seems that obtaining the lock earlier would solve this).
I filed bug report #534892 about another piece of code which would have a race condition if pointer assignment isn’t atomic, this time in err_fns_check() [10]. In my first pass I didn’t bother filing bug reports about most of the issues helgrind raised with the error handling code (there were so many that I just hoped that there was some subtle locking involved that eluded helgrind and my brief scan of the source). But a new entry in my core file collection suggests that this may be a problem area for my code.
I think that it is fairly important to get security related libraries to be clean for use with valgrind and other debugging tools – if only to allow better debugging of the code that calls them. I would appreciate any assistance that people can offer in terms of fixing these problems. I know that there are security risks in terms of changing code in such important libraries, but there are also risks in leaving potential race conditions in such code.
As an aside, I’ve filed a wishlist bug report #534695 requesting that valgrind would have a feature to automatically add entries to the suppressions file [11]. As a function that is considered to be unsafe can be called from different contexts, and code that is considered unsafe can be in a macro that is called from multiple functions there can be many different suppressions needed. Pasting them all into the suppressions file is tedious.
optional_policy(`
sudo_role_template(mystaff, mystaff_r, mystaff_t)
')
# Available privileged roles
# Test
optional_policy(`
webadm_role_change(mystaff_r)
')
In that case one may also want to rename the mystaff to something more appropriate. One can simply modify this policy to add or remove privileges.by Dominick "domg472" Grift (noreply@blogger.com) at June 28, 2009 08:08 AM
by Dominick "domg472" Grift (noreply@blogger.com) at June 28, 2009 06:02 AM
by Dominick "domg472" Grift (noreply@blogger.com) at June 27, 2009 10:20 AM
by Dominick "domg472" Grift (noreply@blogger.com) at June 27, 2009 05:06 AM
by Dominick "domg472" Grift (noreply@blogger.com) at June 27, 2009 04:22 AM