fdpl_memo0009
の編集
https://k.osask.jp/klog/?fdpl_memo0009
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
2012_0001
2013_0001
2013_0002
2013_0003
2014_0001
2015_0001
2016_07
2016_08
2016_09
2016_10
2016_11
2017_01
2017_02
2017_03
2017_04
2017_05
2018_01
2019_01
BracketName
FormattingRules
FrontPage
Help
InterWiki
InterWikiName
InterWikiSandBox
K
KH_SARC_00
KH_dha8
MenuBar
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SandBox
VC_install
WikiEngines
WikiName
WikiWikiWeb
YukiWiki
fdpl_memo0001
fdpl_memo0002
fdpl_memo0003
fdpl_memo0004
fdpl_memo0005
fdpl_memo0006
fdpl_memo0007
fdpl_memo0008
fdpl_memo0009
fdpl_memo0010
gg02_0004
gg02_0005
gg02_0006
gg02_0007
gg02_0008
gg02_0009
https
impressions
memo0001
memo0002
oisix01
osaskology
osaskology0
osecpu_0001
osecpu_0002
p20200229a
p20200303a
p20200310a
p20200321a
p20200401a
p20200730a
p20201230a
p20220628a
p20220701a
populars
prog_0001
prog_0002
prog_0003
prog_0004
prog_0005
* KH-FDPL に関するメモ-0009 -(by [[K]], 2015.02.17) ** KH-FDPLの特徴(5) - セキュリティ --KH-FDPLではなんでもかんでも書き換え自由で、つまり一歩間違えればシステムは簡単にクラッシュさせられます。だからKH-FDPLはセキュリティにも気を配ります。 -(5-1) 名前空間によるセキュリティ。 --まず第一に、どの関数も渡されたオブジェクト以外にはアクセスできません。つまり引数にaとbというオブジェクトを渡されたら、aやbの中身はどれだけでもアクセスできますが、それ以外に手出しする方法はありません。もちろん新規にオブジェクトを作ることはできますので、自分が作ったオブジェクトに対してあれこれといじることはできると思いますが、でもそれはシステムをダウンさせることにはならないでしょう。 --この「渡されたオブジェクト」というのは、引数などで明示的に渡されたオブジェクトだけではなく、暗黙で渡されているオブジェクトも含みます。何が明示的に渡させるオブジェクトで、何が暗黙で渡されるオブジェクトなのかについては言語によって異なると思うので、残念ながらここで明記することはできません。 --だからルートオブジェクトとかを渡さない限り、プログラムができる破壊行為は限定されます。 -(5-2) リードオンリー。 --関数にオブジェクトを渡すときには、リードオンリーとして渡すこともできます。当初はセキュリティ機能の単純化のためにこれをサポートしないことも検討したのですが、壊されたくないものを渡すたびにコピーを作ってそちらを渡すようにするのは明らかに処理速度面で悪そうだったので、やはり既存オブジェクトをリードオンリーのもとで渡す機能は付けることにしました。 -(5-3) CopyOnWrite。 --似た内容のオブジェクトをたくさん作る場合を想定して、共通部分をメモリ内で共有できるCopyOnWriteな仕組みも導入予定です。これはセキュリティというよりもメモリ節約目的ですが、ついでなので紹介しました。 -(5-4) シンプルなセキュリティ。 --オブジェクトに対して可能な操作はたくさんあって、それぞれについて許すか許さないかを決めていくと、それはとても複雑になります。オブジェクトは作ってもいいのか?書き換えないけど書き足すのはいいのか?内容を変更しないでただ消すのはいいのか?オブジェクト名を変更するのはいいのか?・・・などなど、微妙な操作はいくらでも思いつきます。 --これらすべてに対してそれぞれ許可・不許可を管理していたら、KH-FDPLはあっという間に複雑化してしまいます。それは望ましいことではありません。・・・それで、そもそもセキュリティによって何がしたいのかということを考え直してみました。 --その結果、名前空間でのセキュリティとリードオンリーでのアクセスモードがあれば、あとは何とでもなりそうだと思いました。 -(5-5) バッファオーバーランは起きません。 --KH-FDPLでは、配列などで大きな添え字を指定して攻撃しようと思っても、それはできません。エラーにもならず、普通に記憶されます。その添え字を再び使用すれば、設定した値が返ってきます。 --この状況下での有効な攻撃手法は、とにかく値をたくさん詰め込んで、メモリをあふれさせることくらいしかないと思います。それについては、何か適当なメモリ消費上限リミッタがあれば、それで問題なさそうな気がします。リミッタを超えたら実行は停止されます。ユーザはリミッタを上げてから再開してもいいですし、悪意ある行為として停止させてもいいです。 -(5-6) セキュリティとデバッグ支援。 --これは以前からの[[K]]の持論ですが、セキュリティーホールはプログラマの意志に反する動作に由来するもので、つまりはバグの一種です。ということでKH-FDPLとしてはデバック支援を充実させれば、セキュリティ対策にもなっているはずだと考えます。またデバッグ支援だけではなく、そもそもバグが起きにくくなる仕様というのも目指しています。 --(3)に書いたオブジェクトの寿命管理についても、まさにバグが起こりにくくなる仕組みの一つです。 --変数や関数の一覧を表示させることもできます。これはディレクトリに対してlsするような感じです。デバッグの助けになるかもしれません。 -(5-7) 不正なポインタの検出力。 --KH-FDPLはポインタを扱うことができます。そしてもしポインタが差している先のオブジェクトが先に寿命を迎えてしまい、ポインタはあらぬところを指しているとします。そんなとき、このポインタを使ってオブジェクトにアクセスしようとしたらどうなるでしょうか?・・・はい、ちゃんとエラーで止まります。そのメモリが既にほかのオブジェクトに使われていたとしても、問題なく検出できます。 --ということで、ポインタに関する深刻でめんどくさいバグとは永久におさらばできます。 * こめんと欄 #comment
タイムスタンプを変更しない
* KH-FDPL に関するメモ-0009 -(by [[K]], 2015.02.17) ** KH-FDPLの特徴(5) - セキュリティ --KH-FDPLではなんでもかんでも書き換え自由で、つまり一歩間違えればシステムは簡単にクラッシュさせられます。だからKH-FDPLはセキュリティにも気を配ります。 -(5-1) 名前空間によるセキュリティ。 --まず第一に、どの関数も渡されたオブジェクト以外にはアクセスできません。つまり引数にaとbというオブジェクトを渡されたら、aやbの中身はどれだけでもアクセスできますが、それ以外に手出しする方法はありません。もちろん新規にオブジェクトを作ることはできますので、自分が作ったオブジェクトに対してあれこれといじることはできると思いますが、でもそれはシステムをダウンさせることにはならないでしょう。 --この「渡されたオブジェクト」というのは、引数などで明示的に渡されたオブジェクトだけではなく、暗黙で渡されているオブジェクトも含みます。何が明示的に渡させるオブジェクトで、何が暗黙で渡されるオブジェクトなのかについては言語によって異なると思うので、残念ながらここで明記することはできません。 --だからルートオブジェクトとかを渡さない限り、プログラムができる破壊行為は限定されます。 -(5-2) リードオンリー。 --関数にオブジェクトを渡すときには、リードオンリーとして渡すこともできます。当初はセキュリティ機能の単純化のためにこれをサポートしないことも検討したのですが、壊されたくないものを渡すたびにコピーを作ってそちらを渡すようにするのは明らかに処理速度面で悪そうだったので、やはり既存オブジェクトをリードオンリーのもとで渡す機能は付けることにしました。 -(5-3) CopyOnWrite。 --似た内容のオブジェクトをたくさん作る場合を想定して、共通部分をメモリ内で共有できるCopyOnWriteな仕組みも導入予定です。これはセキュリティというよりもメモリ節約目的ですが、ついでなので紹介しました。 -(5-4) シンプルなセキュリティ。 --オブジェクトに対して可能な操作はたくさんあって、それぞれについて許すか許さないかを決めていくと、それはとても複雑になります。オブジェクトは作ってもいいのか?書き換えないけど書き足すのはいいのか?内容を変更しないでただ消すのはいいのか?オブジェクト名を変更するのはいいのか?・・・などなど、微妙な操作はいくらでも思いつきます。 --これらすべてに対してそれぞれ許可・不許可を管理していたら、KH-FDPLはあっという間に複雑化してしまいます。それは望ましいことではありません。・・・それで、そもそもセキュリティによって何がしたいのかということを考え直してみました。 --その結果、名前空間でのセキュリティとリードオンリーでのアクセスモードがあれば、あとは何とでもなりそうだと思いました。 -(5-5) バッファオーバーランは起きません。 --KH-FDPLでは、配列などで大きな添え字を指定して攻撃しようと思っても、それはできません。エラーにもならず、普通に記憶されます。その添え字を再び使用すれば、設定した値が返ってきます。 --この状況下での有効な攻撃手法は、とにかく値をたくさん詰め込んで、メモリをあふれさせることくらいしかないと思います。それについては、何か適当なメモリ消費上限リミッタがあれば、それで問題なさそうな気がします。リミッタを超えたら実行は停止されます。ユーザはリミッタを上げてから再開してもいいですし、悪意ある行為として停止させてもいいです。 -(5-6) セキュリティとデバッグ支援。 --これは以前からの[[K]]の持論ですが、セキュリティーホールはプログラマの意志に反する動作に由来するもので、つまりはバグの一種です。ということでKH-FDPLとしてはデバック支援を充実させれば、セキュリティ対策にもなっているはずだと考えます。またデバッグ支援だけではなく、そもそもバグが起きにくくなる仕様というのも目指しています。 --(3)に書いたオブジェクトの寿命管理についても、まさにバグが起こりにくくなる仕組みの一つです。 --変数や関数の一覧を表示させることもできます。これはディレクトリに対してlsするような感じです。デバッグの助けになるかもしれません。 -(5-7) 不正なポインタの検出力。 --KH-FDPLはポインタを扱うことができます。そしてもしポインタが差している先のオブジェクトが先に寿命を迎えてしまい、ポインタはあらぬところを指しているとします。そんなとき、このポインタを使ってオブジェクトにアクセスしようとしたらどうなるでしょうか?・・・はい、ちゃんとエラーで止まります。そのメモリが既にほかのオブジェクトに使われていたとしても、問題なく検出できます。 --ということで、ポインタに関する深刻でめんどくさいバグとは永久におさらばできます。 * こめんと欄 #comment
テキスト整形のルールを表示する