• 検索結果がありません。

28 Docker Design and Implementation of Program Evaluation System Using Docker Virtualized Environment

N/A
N/A
Protected

Academic year: 2021

シェア "28 Docker Design and Implementation of Program Evaluation System Using Docker Virtualized Environment"

Copied!
40
0
0

読み込み中.... (全文を見る)

全文

(1)

平成

28

年度

学士学位論文

Docker

による仮想環境を用いた

プログラムのテストシステムの設計と実装

Design and Implementation of

Program Evaluation System

Using Docker Virtualized Environment

1170288

岩本 迪子

指導教員

鵜川 始陽

2017

2

28

(2)

要 旨

Docker

による仮想環境を用いた

プログラムのテストシステムの設計と実装

岩本 迪子

情報科学の授業では, 教師がプログラミングに関する課題を課すことがある. その課題に 対して, 生徒はプログラムを作成し,そのプログラムを教師に提出する. しかし悪意ある生徒 がマルウェアを提出した場合, 教師が評価のためにそのプログラムを実行すると, 教師のコ ンピュータはマルウェアに感染してしまう. 本研究では,提出されたプログラムが原因のマルウェア感染を防ぐため,仮想環境でプログ ラムをテストするシステムを作成した. 仮想環境でプログラムを実行させることにより, マ ルウェアを実行しても仮想環境以外に影響が及ばない. 仮想環境を構築するためにDocker を使用した. 本システムに必要な要件を検討するために, まずプロトタイプシステムを作成した. その プロトタイプシステムは仮想環境でプログラムをテストできるだけの機能を持つ. 作成した プロトタイプシステムを用いて, 実際の授業で提出されたプログラムをテストした. また, プ ロトタイプシステムを搭載した Webアプリケーションを作成し, その授業の受講生にその Webアプリケーションを使用してもらった. その後, アンケートによってシステムの実用性 や生徒が送信しうるマルウェアを調査した. これらの結果より, システムが必要とする機能 を検討した. これらの検討から, テスト対象のプログラムを仮想環境で実行するだけではなく, メモリ 使用量やCPU使用率, 実行時間などの計算リソースの制限, ネットワークアクセスの制限の 機能を備えたプログラムのシステムを開発した. それらが正しく機能しているかを確かめる

(3)

ために評価を行った. その結果,本システムを用いて計算リソースの制限やホストOSのファ イルの書き換え防止が可能であることを確認した. また本システムから外部のネットワーク へのアクセスができないことを確認した. さらに, 本システムと, ホストOS, 別の仮想環境 技術であるVirtualBoxでプログラムをテストし, その時間を比較した. その結果, 本システ ムはVirtualBoxを使用するよりも短時間で実行できた. しかしホスト OSと本システムで テストの実行時間を比較すると, 本システムの方が遅かった. キーワード Docker, 仮想環境, プログラムのテスト, セキュリティ

(4)

Abstract

Design and Implementation of

Program Evaluation System

Using Docker Virtualized Environment

Michiko IWAMOTO

Teachers often assign programming tasks to students in computer science classes. Students write programs and submit them to the teacher. However, if a student submits a malicious program to the teacher, the teacher’s computer infects the malicious program when the teacher execute the program to evaluate it.

In this research, in order to prevent teacher’s computers from infection of such ma-licious programs, we developed a program evaluation system that execute programs in virtualized environment. By executing programs in virtualized environment, we can en-close the effect of the malware in virtualized environment. We used Docker to construct the virtualized environment.

To make requirements to our program evaluation system clear, we developed a prototype system. This prototype system simply has a function to evaluate programs in a virtualized environment. Using this prototype, we evaluated programs that are submitted from students in a real class. We also developed a web application with this prototype system and provided it to the students of the class. Afterward, we surveyed by questioning the students usefulness of this system and malicious behaviors of programs that the students could submit.

(5)

evaluation system that does not only executes programs in a virtualized environment but also restricts usage of computational resources, namely memory and CPU and execution time, and restricts network access. We evaluated the system to make sure that these limiting functions work properly. As a result, we confirmed that the system limits resource usage, CPU, and execution time and prevents programs from rewriting files on the host. We also confirmed that the system prevented programs from accessing to the external network. In addition, we compared the elapsed time taken to evaluate programs using our system with the time taken to evaluate on VirtualBox and the time taken to evaluate directly on the host OS. We found that our system was faster than VirtualBox. However, our system was slower than the host OS.

(6)

目次

1章 はじめに 1 1.1 研究の背景と目的 . . . 1 1.2 研究の方針 . . . 2 第2Docker 3 2.1 Dockerの概要 . . . 3 2.2 Dockerの仕組み . . . 3 2.3 Dockerを用いた仮想環境の作成 . . . 4 第3章 システムの要件調査 7 3.1 プロトタイプシステムの作成 . . . 7 3.1.1 プロトタイプシステムの設計 . . . 7 3.1.2 テスト環境を作成するコマンドの実装 . . . 9 3.1.3 提出されたプログラムをテストするコマンドの実装 . . . 10 3.2 プロトタイプシステムを用いた要件調査. . . 11 3.2.1 調査方法 . . . 11 3.2.2 調査結果 . . . 12 3.3 システムに必要な要件 . . . 13 第4章 設計と実装 15 4.1 設計. . . 15 4.2 テスト環境を作成するコマンドの実装 . . . 16 4.3 プログラムのテストを行うコマンドの実装 . . . 17 第5章 評価 20

(7)

目次 5.1 安全性の評価 . . . 21 5.1.1 ホストOS上のファイルの保護 . . . 21 5.1.2 実行時間の制限 . . . 21 5.1.3 メモリ使用量の制限 . . . 22 5.1.4 CPU使用率の制限 . . . 22 5.1.5 外部のネットワークへのアクセス制限 . . . 23 5.2 効率の評価 . . . 24 第6章 関連研究 27 6.1 仮想環境を用いたマルウェア解析 . . . 27 6.2 Javaによるテスト支援システムの開発 . . . 27 6.3 Dockerを用いたプログラムテストアプリケーション . . . 28 第7章 おわりに 29 7.1 まとめ . . . 29 7.2 今後の課題 . . . 29 謝辞 30 参考文献 31

(8)

図目次

2.1 Dockerでコンテナの作成, 実行の例 . . . 5

2.2 Dockerfileの例 . . . 5

3.1 プロトタイプシステムの構成 . . . 9

(9)

表目次

3.1 質問5に関するアンケート調査結果 . . . 12 5.1 評価環境 . . . 20 5.2 実行時間の制限の有無による実行時間の比較 . . . 21 5.3 メモリ使用量の制限の有無によるメモリ使用量の比較 . . . 22 5.4 CPU制限の有無によるCPU使用率の比較 . . . 23 5.5 ネットワークアクセスの評価実験の結果 . . . 23 5.6 本システムに関するテストの実行時間 . . . 25 5.7 ホストOSに関する計測時間 . . . 25 5.8 VirtualBoxに関するテストの実行時間 . . . 25

(10)

1

はじめに

1.1

研究の背景と目的

情報科学の授業では, 教師がプログラミングの課題を課すことがある. このとき教師は課 題を提示し, 生徒がその課題の解答プログラムを作成して教師に提出する. そして教師は, 提 出されたプログラムを評価するために教師のコンピュータ上でプログラムを実行する. しか し生徒が悪意あるプログラムを提出した場合は, 教師がそのプログラムを実行することで被 害に遭ってしまう. 悪意あるプログラムの例として, 教師のコンピュータ上にあるファイルを外部に流出させ るプログラムが挙げられる. 教師がそのプログラムを実行すると, 正答のプログラムや成績 などといった重要な情報が流出してしまう可能性がある. この問題を解決するために, 本研究では教師が解答プログラムを安全かつ効率よくテスト するためのシステムを作成する. 本論文における効率とは, 短時間でプログラムのテストが 行えることを意味する. 本研究では, プログラムの安全なテストを次のように定義する. メモリ使用量やCPU使用率などの計算リソースを過剰に使用されない 教師のコンピュータのファイルが教師の意図に反して書き換えられたり削除されたりし ない 教師のコンピュータのファイルの内容が教師のコンピュータの外に持ち出されない ネットワークを介したアクセスをしない

(11)

1.2 研究の方針

1.2

研究の方針

プログラムを安全に実行するため, プログラムを仮想環境で実行する. 悪意あるプログラ ムを仮想環境で実行しても, 仮想環境以外にプログラムの影響が及ばないために安全である. 仮想環境として, コンテナ型仮想化の技術であるDockerを使用する. Dockerで用意される 仮想環境は軽量である[1]. またDockerには, 仮想環境の起動時間が短く, メモリ消費が少 ないという特徴がある. これらの特徴は効率よくプログラムをテストすることに貢献する. 本研究では, まずプロトタイプシステムを作成してシステムに必要な要件を調査した. そ れをもとにプログラムを安全かつ効率よくテストできるシステムを設計し, 実装した. そし てこのシステムを安全性と効率の観点から評価して, 本システムの有用性を確認した.

(12)

2

Docker

本章では, 提案するシステムの要となるDockerについての説明を行う.

2.1

Docker

の概要

Dockerはコンテナ型仮想化技術のひとつである. コンテナとはホストOSから分離され た領域を指し, コンテナ型仮想化とはコンテナ内でプロセスを実行するための技術である. 他の仮想化技術であるハイパーバイザ型仮想化とホストOS型仮想化と比較すると, ゲスト OSを新たに導入する必要がないために少ない容量で稼働できる.

2.2

Docker

の仕組み

Dockerは仮想環境であるコンテナを作成する. そのコンテナの作成や実行をするために 以下の機能を使用する[2]. • namespace • cgroups

• Union File System

namespaceは, ファイルシステムやネットワーク等をコンテナ外の部分から分離する機能 である. この機能はLinuxカーネルの機能であり, ホストOSからコンテナを独立させるた めに使用する.

(13)

2.3 Dockerを用いた仮想環境の作成

cgroups は, CPU やメモリといったリソースの管理を行う機能である. cgroups は namespaceと同様に Linuxカーネルの機能であり, コンテナのリソースを管理するために 使用する.

Union File Systemとは, 複数あるレイヤのファイルシステムをオーバレイすることによ り, ひとつのファイルシステムとして扱うことが可能になる機能である[1].

2.3

Docker

を用いた仮想環境の作成

Dockerの仮想環境であるコンテナは, イメージと呼ばれるシステムやファイルシステム のスナップショットから作成する. コンテナを作成する手順を以下に示す. 手順1. コンテナ内でもととなるイメージや実行するコマンド等をDockerfileに記述する. 手順2. Dockerfileをもとにイメージを作成する. 手順3. イメージからコンテナを作成, 実行する. Dockerfileはイメージを作成するためのテキストファイルであり, そのファイルにはイ メージを構築する手順やコンテナで行う動作を記述する. イメージは一般公開されているも のを使用でき, イメージを取得するためには, Docker Hub[3]で公開されているイメージ名 を指定してDockerfileに記述する. Docker Hubには公式や個人が作成したイメージが公開

されており, イメージをダウンロードして使用することができる[4].

Dockerの使用例として,ホストOS上に存在するテキストファイルtest.txtの内容を表示 するという動作を Dockerのコンテナで実行する. test.txtにはHelloWorld!と記述されて いる. 上記の手順1, 手順2, 手順3の一連の流れを図2.1に示す.

まず図2.2のようなDockerfileを作成する. 1行目はもととなるUbuntuイメージを取得 する. 2行目ではホストOS上のファイルtest.txtをイメージの中にコピーする. 3行目には コンテナで実行するコマンドを記述している. 図2.1より, test.txtの内容を表示するコマン ドを実行するように記述する.

(14)

2.3 Dockerを用いた仮想環境の作成 図2.1 Dockerでコンテナの作成,実行の例 F R O M u b u n t u : l a t e s t C O P Y ./ t e x t . txt . CMD cat t e s t . txt 図2.2 Dockerfileの例 次にこのDockerfileをもとにイメージを作成する. このイメージを作成するためには以下 のコマンドを使用する. $docker build このコマンドを実行する際にイメージに名前を付ける. そしてイメージからコンテナを作成, 実行する. 以下のコマンドを実行すると, Dockerfile の3行目に記述されているコマンドが実行され, test.txtの内容が表示される. $docker run Hello World!

(15)

2.3 Dockerを用いた仮想環境の作成

このコマンドを実行する際にもととなるイメージの名前を指定することで, 指定されたイ

(16)

3

システムの要件調査

本章では, プロトタイプシステムを作成して, プログラムのテストを行う. それによりシス テムの要件を調査する.

3.1

プロトタイプシステムの作成

プロトタイプシステムに必要な機能は以下の2つである. 仮想環境でプログラムを実行する機能 最低限の手動による作業でプログラムのテストが可能な機能 これらの機能は, プログラムを安全かつ効率的に実行するために必要な最低限の機能で ある.

3.1.1

プロトタイプシステムの設計

プロトタイプシステムで作成したコンテナ内で行う手順を以下に示す. 手順1. プログラムのコンパイル 手順2. プログラムの実行 手順3. 実行結果の出力 手順4. プログラムの正誤判定

(17)

3.1 プロトタイプシステムの作成 これらの手順をコンテナ内で行う理由としては, 安全性の向上が挙げられる. ホストOS上 でコンパイルすると, コンパイルによって作成された実行ファイルがホスト OSに残ってし まい, 誤って実行してしまう恐れがあるためである. 作成するプロトタイプでは, これらの手順を以下に示す2つのコマンドで実現する. テスト環境を作成するコマンド 提出されたプログラムをテストするコマンド プロトタイプシステムの構成を図3.1に示す. テスト環境を作成するコマンドは, プログラ ムのテストをするための環境を, 課題ごとにイメージとして用意するためのコマンドである. また提出されたプログラムをテストするコマンドは, プログラムをテストするために必要な イメージやコンテナを作成するためのコマンドである. ユーザが事前に用意するファイルを以下に示す. 提出されたプログラム プログラムの実行に必要なファイル テストスクリプト – compileコマンド プログラムをコンパイルするためのコマンド – prepareコマンド プログラムを実行するために必要なファイルを別のディレクトリから用意するため のコマンド – runコマンド プログラムを実行するコマンド – validateコマンド プログラムの正誤判定を行うコマンド

(18)

3.1 プロトタイプシステムの作成

図3.1 プロトタイプシステムの構成

上記の4種類のコマンドには, ユーザがコマンドごとに動作を記述する. 上記のcompile コマンド, prepareコマンド, runコマンド, validateコマンドの4種類はテストを行うため のコマンドであり, 図3.1のコンテナで実行する. 図3.1より, テスト環境を用意するコマンドで作成するイメージには, ユーザが用意した ファイルの中でライブラリやテスト用のデータなどのプログラムの実行に必要なファイル と, テストスクリプトを含ませる. そして提出されたプログラムをテストするコマンドで作 成するイメージには,提出されたプログラムを含ませる.

3.1.2

テスト環境を作成するコマンドの実装

テスト環境を作成するコマンドは, プログラムテストに必要なファイルを含んだイメージ を作成するためのコマンドである. このイメージに含まれるファイルを以下に示す. テストスクリプト プログラムの実行に必要なファイル これらのファイルはシステムのユーザがあらかじめ用意する. テスト環境を作成するコマン ドで行う処理を以下に示す.

(19)

3.1 プロトタイプシステムの作成 手順1. Dockerfileを作成する. 手順2. ユーザが用意した, テストスクリプトを一括実行するためのコマンドを作成する. 手順3. 提出されたプログラムをコンパイルするための言語処理系のイメージをもとに, 新 しいイメージを作成する. 手順4. 手順1で作成したDockerfileを削除する. これらの手順を実装することで, プログラムをテストするための環境を用意できる. 手順 1 で作成するDockerfileでは, もととなるイメージと, イメージにコピーするディレクトリを 指定する. もととなるイメージはテストするプログラムのプログラミング言語によって異な り, テストするプログラムを実行できるイメージを指定する.

3.1.3

提出されたプログラムをテストするコマンドの実装

提出されたプログラムをテストするコマンドは, コンテナを作成して, そのコンテナで提 出されたプログラムのテストを行うためのコマンドである. このコマンドで作成されるイ メージに含まれるファイルは, テストするプログラムである. このコマンドで行う動作の手 順を以下に示す. 手順1. Dockerfileを作成する. 手順2. テスト環境を作成するコマンドで作成したイメージをもとに, 新しいイメージを作 成する. 手順3. コンテナを作成して実行する. 手順4. プログラムのテストを行うコマンドで作成したイメージを削除する. 手順5. 手順1で作成したDockerfileを削除する.

(20)

3.2 プロトタイプシステムを用いた要件調査

3.2

プロトタイプシステムを用いた要件調査

3.2.1

調査方法

作成したプロトタイプシステムを使って, 実際の授業で提示された3つの課題に対して生 徒が作成した解答をテストした. そのうちひとつの課題に関しては, 作成したプログラムの テストが可能なWebアプリケーションを作成し, 課題の締め切りまで生徒が自由に使える ようにした. それ以外の課題に関しては, 著者がプロトタイプシステムを使ってテストした. 作成したWebアプリケーションを使用した生徒に対してアンケートを作成した. アンケー トの対象は本大学の情報学群に所属する生徒19人である. アンケートに記載した質問を以 下に述べる. 質問1. Webアプリケーションを使用したか 質問2. 悪意あるプログラムを送信したか 質問3. 送信した場合, どのような実行内容のプログラムを送信したか 選択肢 • CGIプログラムの書き換えまたは削除 テスト用プログラムの書き換えまたは削除 無限ループ システムのクラッシュ 怪しいサイトへのアクセス プライバシー情報の入手 その他 質問4. 送信した悪意あるプログラムは正しく実行されたか 質問5. 仮に悪意のあるプログラムを送信するならばどのような実行内容のプログラムか 選択肢 質問3と同様の選択肢

(21)

3.2 プロトタイプシステムを用いた要件調査 表3.1 質問5に関するアンケート調査結果 悪意あるプログラムの内容 人数(人) CGIプログラムの書き換えまたは削除 3 テスト用プログラムの書き換えまたは削除 3 無限ループ 8 システムのクラッシュ 9 怪しいサイトへのアクセス 6 プライバシー情報の入手 8 その他 0 質問1, 質問2, 質問4における選択肢は, はい, いいえの2択とする. 上記からプロトタイ プに機能を追加するために参考にした質問は, 質問2, 質問3, 質問 4, 質問 5である. また, 質問3, 質問4,質問5に関しては複数回答を可能とする.

3.2.2

調査結果

プロトタイプシステムを用いて2つの課題のテストを行った結果を以下に示す. コンテナ内で正常に動作が行われなかった場合, 正誤判定結果が表示されなかった. プログラム自体は正答だが, 文字化けが原因でコンパイルの時点でエラーが発生し, 誤 答と判断されてしまうことがあった. またアンケートを集計した結果, Webアプリケーションに対して悪意のあるプログラムを 実際に送信した生徒はいなかった. 仮に悪意のあるプログラムを送信するならばどのような 実行内容のプログラムにするか, という質問に対しての集計結果は, 表3.1のようになった. 票の多い順に述べると, システムのクラッシュ,無限ループ, プライバシー情報の入手の3つ の項目が特に票を集めた.

(22)

3.3 システムに必要な要件

3.3

システムに必要な要件

3.2節の調査より, 本研究で提案するシステムには, プロトタイプシステムで作成した機能 に加えて以下に示す機能が必要であることが分かった. 項目1. コマンドが強制終了した場合にコマンドを実行する機能 項目2. 一定時間後にコンテナを強制終了させる機能 項目3. メモリ使用量やCPU使用率といったリソースの制限をする機能 項目4. 外部のネットワークへの接続を制限する機能 エラーの発生によりコンテナを実行するコマンドが終了した場合, コンテナ内の動作が正 しく行われないために出力がなく, そのテストでエラーが発生したことを一目で確認するこ とができない. そこで項目1の機能を追加し, テストでエラーが発生したことを確認できる ようにする. 表3.1のアンケートの集計結果より, システムのクラッシュや無限ループ, プライバシー情 報の入手の3点を重点的に対策する. システムをクラッシュさせるプログラムの例として挙 げられるのが, 高速に大量のプロセスを作成するプログラムがある. 高速に大量のプロセス を作成するプログラムを実行してもシステムがクラッシュしないよう, 項目2の機能を追加 する. またプロセスだけではなく, CPUやメモリを大量に消費させるプログラムもシステム のクラッシュを引き起こす可能性があるため, 項目 3の機能を追加し対策を行う. 無限ルー プの対策として, システムのクラッシュと同様に対策するために項目2を使用する. プライ バシー情報の不正入手をするためにはネットワークを経由する必要がある. そのためプライ バシー情報の不正入手を防ぐためには, ネットワークの設定をする必要がある. 項目4の機 能を追加することで外部ネットワークへ接続しないよう設定し, プライバシー情報の入手を 防ぐ. またプログラムを作成した環境とプログラムをテストする環境の文字コードの違いが原 因で, 提出されたプログラムによってはコンパイルの時点でエラーが発生してしまうことが

(23)

3.3 システムに必要な要件

(24)

4

設計と実装

本章では, 第3章で行われた要件の調査をもとに, 本システムの設計と実装を行う.

4.1

設計

本システムの構成は, プロトタイプシステムと同様に図3.1の通りである. また本システ ムは, プロトタイプシステムと同様に2つのコマンドから成り立つ. テスト環境を作成するコマンド 提出されたプログラムをテストするコマンド 3.3節より, プロトタイプに追加する機能を以下に示す. 項目1. コマンドが強制終了した場合にコマンドを実行する機能 項目2. 一定時間後にコンテナを強制終了させる機能 項目3. メモリ使用量やCPU使用率といったリソースの制限をする機能 項目4. 外部のネットワークへの接続を制限する機能 項目 1の機能を実装するにあたり, errorコマンドを作成する. errorコマンドは, ユーザが 事前に用意するコマンドのひとつであり, コンテナを実行したコマンドが正常に終了しな かった場合に実行する. また項目2, 項目3, 項目4の機能を実装するため, 本システムで作成するコンテナに対し て設定を行うことができる機能を追加する. 本システムで設定できる項目を以下に述べる.

(25)

4.2 テスト環境を作成するコマンドの実装 項目1. コンテナを実行したコマンドが終了するまでの時間  設定された時間後にコンテナを実行したコマンドが終了する. 項目2. 使用できるメモリの最大値 メモリの使用量が設定した値を超えるとプロセスが終了する. 項目3. CPUの周期 下記のCPUの周期に対してコンテナに割り当てる時間とあわせて設定する. 項目4. CPUの周期に対してコンテナに割り当てる時間 上記のCPUの周期とあわせて設定する. これらの2つを設定することでCPU使 用率を制限できる. CPU使用率を設定するためには以下の式を使用する. CP U 使用率= CP U の周期に対してコンテナに割り当てる時間 CP U の周期 × 100 項目5. 接続するネットワーク 本システムでコンテナを作成する際に, コンテナで使用するネットワークを指定 する. ユーザがこれらの設定をするためには, プログラムをテストするコマンドの実行時にオプ ションを使用する.

4.2

テスト環境を作成するコマンドの実装

テスト環境を作成するコマンドではプロトタイプシステムと同様の役割を持ち, またイ メージに追加するファイルも同様である. このコマンドでユーザは, 引数として以下の項目 を設定する. 項目1. 提出されたプログラムをテストする回数 項目2. プログラムの実行に必要なファイルがあるディレクトリ 項目3. もととなるプログラムを実行する言語処理系のイメージ

(26)

4.3 プログラムのテストを行うコマンドの実装 手順1. Dockerfileを作成する. Dockerfileでは, もととなるプログラムを実行する言語処理系のイメージを指定し て, 必要なファイルを追加することを記述する. 手順2. テストスクリプトを一括実行するコマンドを作成する. このコマンドはプログラムのテストを行うコマンドで使用する. 手順3. 新しいイメージを作成する. このイメージはプログラムのテストを行うコマンドで使用するためのイメージであ るため, このイメージはコンテナに変換しない. 手順4. 手順1で作成したDockerfileを削除する. このDockerfileは不要となったため削除する. 手順5. ネットワークの作成 外部のネットワークに接続不可能なネットワークを作成する.

4.3

プログラムのテストを行うコマンドの実装

プログラムのテストを行うコマンドではプロトタイプシステムと同様の役割を持ち, また イメージに追加するファイルも同様である. このコマンド実行時にユーザはオプションを使 用することで以下の項目を設定できる. 項目1. コンテナを実行したコマンドが終了するまでの時間 デフォルトでは10秒に設定する. 項目2. 使用できるメモリの最大値 デフォルトでは50MBに設定する. 項目3. CPUの周期 デフォルトでは0に設定する. 項目4. CPUの周期に対してコンテナに割り当てる時間 デフォルトでは0に設定する.

(27)

4.3 プログラムのテストを行うコマンドの実装 項目5. 接続するネットワーク デフォルトではテスト環境を作成するコマンドで作成した, 外部のネットワークに 接続不可能なネットワークに設定する. 項目6. テストするプログラムがあるディレクトリ, ファイル名の指定 デフォルトではカレントディレクトリに設定する. 項目7. テストを行うコマンドを一括実行するコマンドの引数 デフォルトでは何も設定しない. 項目8. テストを行うコマンドを一括実行するコマンドの引数 項目7と同様に, デフォルトでは何も設定しない. 上記の項目は必要に応じて設定をする. 項目 6と項目 7, 項目 8はerrorコマンドの引数と しても使用する. プログラムのテストを行うコマンドで実行する動作とその詳細を以下に記 述する. 手順1. Dockerfileを作成する. Dockerfileでは, テスト環境を作成するコマンドで作成したイメージを指定して, 実行するプログラムを追加することを記述する. 手順2. テスト環境を作成するコマンドで作成したイメージをもとに, 新しいイメージを作 成する. テスト環境を作成するコマンドで作成したイメージをもとにすることで, テストす るごとにテスト環境を何度でも再利用できる. 手順3. コンテナを作成して実行する. このコンテナで実行するコマンドは, テスト環境を作成するコマンドで作成したコ マンドである. このコマンドを実行することで,プログラムのコンパイルや実行, 評 価といったプログラムのテストのためのコマンドを実行できる. 手順4. 手順2で作成したイメージを削除する. このイメージは不要となったため削除する.

(28)

4.3 プログラムのテストを行うコマンドの実装 手順5. 手順1で作成したDockerfileを削除する. このDockerfileは不要となったため削除する. 4.1節で示した項目1の機能は, コンテナを実行したコマンドを終了させるための機能で あり, この機能のみではコンテナは終了しない. そのため, 上記の手順3が正しく動作しな かった場合に行う手順を以下に示す. 手順1. コンテナを停止させる. 手順2. コンテナを強制的に削除する. 手順3. errorコマンドを実行する. 手順4. 提出されたプログラムのテストを行うコマンドで作成したイメージを削除する. 手順5. 提出されたプログラムのテストを行うコマンドで作成したDockerfileを削除する.

(29)

5

評価

本章では, 本研究で開発したシステムの安全性や効率を次の観点から評価する. ホストOS上に存在するファイルの保護が可能か 実行時間の制限が可能か メモリ使用量の制限が可能か • CPU使用率の制限が可能か 外部のネットワークへのアクセス制限が可能か 他の仮想環境化技術を使うよりも短時間でテストできるか これらの評価において, 実装した機能が正確に動作するかを確かめるため, 本システムで作 成するコンテナに対する設定の中で, 評価に必要のない機能は使用しない. 評価を行う環境を表5.1に示す. 表5.1 評価環境 バージョン Ubuntu 16.04 Docker 1.12.1 VirtualBox 5.1.12 javac 1.8.0 111

(30)

5.1 安全性の評価 表5.2 実行時間の制限の有無による実行時間の比較 実行時間の設定 1回目(s) 2回目(s) 3回目(s) 制限あり 14.84 14.25 15.05 制限なし 180以上 180以上 180以上

5.1

安全性の評価

本システムを使ってプログラムをテストするときの安全性を評価するために, 悪意あるプ ログラムの動作を模倣したプログラムを, 本システムを使って実行した.

5.1.1

ホスト

OS

上のファイルの保護

ホスト上に存在するファイルの保護ができているかを確認するため, あるホスト上のファ イルファイルの内容に適当な文字列を追加するプログラムを本システムを使って実行した. 比較のために, 本システムを使わずにプログラムを実行した場合を想定して, 同じプログラ ムをホストOS上でも実行した. ホスト OSでこのプログラムを実行した結果, ホスト上の ファイルの最終行に文字列が追加されていた. しかし本システムを使用してコンテナでこの プログラムを実行した場合は, ホストOS上のファイルの最終行にプログラムで決められた 文字列は追加されなかった. このことから, 本システムはホスト上のファイルを保護できて いると言える.

5.1.2

実行時間の制限

実行時間の制限が可能かを確認するため, 無限ループのプログラムを本システムで実行す る. 設定されたテストの実行時間である10秒後に正しくコンテナが終了するかを確認する. そのために, 本システムから実行時間の制限をなくしたシステムを作成して, 2つのシステム で上記のプログラムを実行した. 実行結果を表5.2に示す. 制限のあるシステムで無限ループのプログラムを実行したところ, 本システムで作成した コンテナが終了したことを確認した. また実行結果より, 制限を行っていない場合は180秒

(31)

5.1 安全性の評価 表5.3 メモリ使用量の制限の有無によるメモリ使用量の比較 メモリの設定 1回目(MB) 2回目(MB) 3回目(MB) 制限あり 40.53 49.12 43.16 制限なし 51.99 52.23 56.01 を超えてもコンテナが終了しなかったこと, 制限を行っている場合は平均で約14.7秒程度の 実行時間であり, 設定が正しく反映されていることを確認した.

5.1.3

メモリ使用量の制限

メモリ使用量の制限が可能かを確認するため, 文字列をファイルに書き込み続けるプログ ラムを本システムで実行する. 本システムで作成したコンテナのメモリ使用量が, あらかじ め設定した制限を超えるかを確認した. そのために, 本システムからメモリ使用量の制限を なくしたシステムを作成して, 2つのシステムで上記のプログラムを実行した. 実行結果を 表5.3に示す. 実行結果より, 制限を行っていない場合は本システムの課す制限である50MB以上のメモ リ使用量でであること, 制限を行っている場合は50MB以下のメモリ使用量であることを確 認した. また制限を行っている本システムを実行した場合, プロセスが終了することを確認 した.

5.1.4

CPU

使用率の制限

CPU使用率の制限が可能かを確認するため, 文字列をファイルに書き込み続けるプログ ラムを本システムで実行する. 評価をするにあたり, CPU使用率が20%になるようにCPU の周期とそのCPUの周期に対してコンテナに割り当てる時間を設定した. 本システムで作 成したコンテナのCPU使用率が, あらかじめ設定した制限を超えるかを確認した. 比較を するために, 本システムからCPUの制限をなくしたシステムを作成して, 2つのシステムで 上記のプログラムを実行した. 実行結果を表5.4に示す.

(32)

5.1 安全性の評価 表5.4 CPU制限の有無によるCPU使用率の比較 CPUの設定 1回目(%) 2回目(%) 3回目(%) 制限あり 19.86 20.29 20.00 制限なし 108.83 131.38 118.38 表5.5 ネットワークアクセスの評価実験の結果 システム ネットワーク 返答 使用 制限あり 無 未使用 制限あり 有 使用 制限なし 有 未使用 制限なし 有 実行結果より, 制限を行っていない場合は本システムの課す制限である 20%を超える CPU使用率であること, 制限を行っている場合は20%を大きく上回らないCPU使用率で あることを確認した.

5.1.5

外部のネットワークへのアクセス制限

外部のネットワークへのアクセス制限が可能かを確認するため, コンテナに外部のネット ワークの制限をかける. そして特定のIPアドレスにpingを送信し, 返答の有無を確認する. 外部のネットワークへのアクセス制限をかける場合, 外部のネットワークにアクセスできな いネットワークを作成し, 作成するコンテナはこのネットワークに接続させる. 実行結果を 表5.5に示す. 実行した結果, 外部のネットワークへのアクセス制限がされた本システムのみにおいて pingの返答が確認できなかった. この結果より, 外部のネットワークへのアクセス制限を行 うと, 制限されたシステムのみにおいて外部のネットワークへのアクセスが不可能であるこ とを確認した.

(33)

5.2 効率の評価

5.2

効率の評価

効率の評価を行うため,同じプログラムをホストOS, VirtualBox[5],本システムでそれぞ れ実行し,実行時間を比較した. VurtualBoxはホスト型仮想化技術によって仮想環境を作成 する技術である. 実行するプログラムは, 実際の授業で提示された課題に対して生徒が作成 した解答のプログラムを使用する. テストでは5人分のプログラムの正誤判定を行う. この評価のために行った手順を以下に示す. 手順1. 仮想環境の起動 手順2. 提出プログラムのテスト 手順3. 仮想環境の終了 悪意あるプログラムを実行した場合に, 他の提出プログラムに影響が及ぶことを防ぐため, 1つの仮想環境ごとに1つのプログラムをテストする. そのため, 手順1から手順3を提出 プログラムの数だけ繰り返す. 本システムを用いてテストする際に, 時間を計測した手順を以下に示す. 手順1. イメージの作成 手順2. コンテナの作成・起動 手順3. プログラムのテスト 手順4. コンテナの削除 Dockerで作成されるコンテナは仮想環境であるため, 手順2と手順4でそれぞれ仮想環 境の起動と削除を行う. 本システムにおいては, 手順1から手順4までをテストを行う回数 だけ繰り返す. また, 同様に VirtualBoxを用いてテストする際に, 時間を計測した手順を以下に示す. VirtualBoxに関しては, ゲストOSから起動する場合とあらかじめ用意したスナップショッ トから起動する場合の 2通りを計測する. 使用するスナップショットは, 可能な限り手作業

(34)

5.2 効率の評価 表5.6 本システムに関するテストの実行時間 計測内容 実行時間(s) イメージの作成からテストの実行完了までの時間 22.15 表5.7 ホストOSに関する計測時間 計測内容 実行時間(s) テスト実行から完了までの時間 3.88 手順1. 仮想環境の起動 手順2. プログラムのテスト 手順3. 仮想環境の終了 VirtualBoxにおいては, 本システムと同様の条件下で比較を行うため, 手順1から手順3 までをテストするプログラムの数だけ繰り返した. この方法ではテストが自動化されていな いため, 仮想環境を起動してからテストを実行するまでの動作は手動で行う. ホストOSで仮想環境を使用せずにテストする際に, 時間を計測した手順を以下に示す. 手順1. プログラムのテスト 表5.6, 5.8, 5.7はそれぞれの起動やテスト実行時間を表す. また図5.1は表5.6, 5.8, 5.7 の結果を可視化したものである. 図5.1に示したVirtualBoxの時間とは,仮想環境の起動時 表5.8 VirtualBoxに関するテストの実行時間 プログラム 起動時間(s) テスト時間(s) 終了時間(s) OSから起動 スナップショット OSから起動 スナップショット OSから起動 スナップショット 1 62.45 3.9 134.53 43.41 18.02 14.37 2 49.19 3.71 109.92 36.51 17.20 23.87 3 49.73 3.88 82.69 41.99 15.49 14.41 4 46.75 3.88 100.91 37.88 15.50 26.33 5 46.60 3.92 57.88 36.24 18.88 23.68

(35)

5.2 効率の評価 図5.1 テストにかかる時間の比較 間から終了時間までの手順をプログラムごとに行い, それが合計の時間である. この結果よ り, VirtualBoxと本システムで実行時間を比較すると, 仮想環境の起動方法に関わらず本シ ステムの方が4分以上も短いことを確認した. またホストOSと本システムで実行時間を比 較すると, ホストOSの方が約18秒短いということも確認した.

(36)

6

関連研究

本章では本研究の関連研究について記述する.

6.1

仮想環境を用いたマルウェア解析

田辺らは, Linux上で実行されるマルウェアを解析するための通信制御方式に関する研究 を行った[6]. マルウェアを実行する仮想環境と, この仮想環境を制御するための仮想環境の 2種類を使用した. マルウェアの感染防止のため, マルウェアを実行するホストから発生する 通信のうち, 危険と判断された通信はすべて遮断する. 本システムでは行われる通信に対す る観測や制御は行っていないが, 外部のネットワークへの通信ができないよう設定すること でマルウェアの外部への感染を防止する.

6.2

Java

によるテスト支援システムの開発

高野らは, プログラミング試験の提出物を採点するためのシステムをJavaで開発した[7]. このシステムに実装された機能は, 提出されたプログラムのコンパイルやテストだけではな く, 評価の参考としてエラーメッセージをAPIから取得する機能や, テストを行う際にスペ ルミスが発覚した場合はリフレクションを用いる機能が実装されている. セキュリティ面に おいては, 実行する際にJavaVMで実行環境の制限をかけることで安全に実行できる. 本研究で作成したシステムと高野らのシステムは, 双方ともに生徒から提出されたプログ ラムをテストするという機能を持つ. 高野らの開発したシステムは, Javaのプログラムをテ ストするためのシステムであるが, 本研究で作成したシステムでは, 言語処理系のイメージ

(37)

6.3 Dockerを用いたプログラムテストアプリケーション を取得すればJava以外のプログラムでもプログラムの実行やテストが可能になる.

6.3

Docker

を用いたプログラムテストアプリケーション

paiza.IO[9]は, 使用者がブラウザ上のエディタに入力した任意のプログラムを実行でき る. JavaやC言語をはじめとする26種類のプログラミング言語に対応しており, 作成した プログラムをネットワークを通して公開することも可能である. このpaiza.IOでは本研究で作成したシステムと同様にDockerを使用しており, コンテナ でプログラムを実行する[8]. paiza.IOでは本システムのようにコマンドプロンプトにコマ ンドを入力してDockerが動いていることを目にすることがないため, Dockerの存在を意識 せずにプログラムを実行できる. しかし本研究で作成したシステムでは, CPUやメモリ, 実 行時間といったコンテナに関する設定を行うことができ, 比較的柔軟性があるといえる.

(38)

7

おわりに

7.1

まとめ

本研究では,コンテナを用いて仮想環境化が可能であるDockerを使用し, プログラムテス トシステムを作成した. はじめにプロトタイプシステムを作成し, そのプロトタイプシステ ムでプログラムを実行した. その結果から改善点を挙げ, 実行時間やメモリ使用量, CPU使 用率, ネットワークの制限ができる機能を追加した. 作成したシステムの有用性を確かめる ため, 安全性や効率における評価を行った. 結果, 安全性に関しては本システムの有用性を確 認できた. 効率においては, 本システムの実行時間が実用的な長さであることを確認したが, ホストOSでの実行時間と比較すると遅いという結果になった.

7.2

今後の課題

今後の課題としては, 安全面と効率, 双方においての機能の充実が課題として挙げられる. 本研究で作成したシステムでは, メモリ使用量やCPU使用率の制限は達成できたが, ハー ドディスクの制限に関してはまだ未実装である. また本システムとホストOSでの実行時間 を比較すると本システムの方が長かったため, できる限り実行時間をホストOSの時間に近 づけるよう改良し, 仮想環境で実行していないかのように振る舞えることが理想だと考える.

(39)

謝辞

本研究を遂行するにあたり, 多大なる御指導や御助言を戴きました鵜川始陽先生に心より

御礼申し上げます. またご多忙の中, 副査として御指導や御助言を戴きました福本昌弘先生,

横山和俊先生に心より感謝申し上げます. プログラミング言語研究室の皆様, アンケート調

(40)

参考文献

[1] 西島 剛. ”はじめてのDocker”, 株式会社工学社, 2016.

[2] Adrian Mouat. ”Docker”, 株式会社オライリー・ジャパン, 2016. [3] Docker Hub, https://hub.docker.com/(2017/2/10閲覧).

[4] 阿佐志保. ”プログラマのためのDocker教科書 インフラの基礎知識&コードによる環 境構築の自動化”,株式会社翔泳社, 2016.

[5] Oracle VM VirtualBox, https://www.virtualbox.org/(2017/1/27閲覧).

[6] 田辺 瑠偉, 筒見 拓也, 小出 駿, 牧田 大佑, 吉岡 克成, 松本 勉. ”Linux上で動作するマ ルウェアを安全に観測可能なマルウェア動的解析手法の提案”, コンピュータセキュリ ティシンポジウム2014論文集, pp. 1007-1014, 2014. [7] 高野 辰之, 宮川 治, 小濱 隆司. ”オブジェクト指向プログラミング教育における採点支 援システムの開発とその評価”, 情報処理学会研究報告コンピュータと教育(CE), pp. 41-45, 2008. [8] 吉岡恒夫. ”Docker実践活用ガイド”, 株式会社マイナビ出版, 2016. [9] ブ ラ ウ ザ で プ ロ グ ラ ミ ン グ・実 行 が で き る「 オ ン ラ イ ン 環 境 」—paiza.IO, https://paiza.io/(2017/1/12閲覧).

図 3.1 プロトタイプシステムの構成

参照

関連したドキュメント

To mimic RAGE-dependent tumor malignant behaviors and assess the inhibitory effects of papaverine, the present study used an established human fibro- sarcoma cell line HT1080

To solve this drawback, we developed a new system capable of detecting the accident in the washing place together with the pulse and respiration rate using a bath mat type

interaction abstract machine token passing on fixed graph. call

An example of a database state in the lextensive category of finite sets, for the EA sketch of our school data specification is provided by any database which models the

By con- structing a single cone P in the product space C[0, 1] × C[0, 1] and applying fixed point theorem in cones, we establish the existence of positive solutions for a system

The general context for a symmetry- based analysis of pattern formation in equivariant dynamical systems is sym- metric (or equivariant) bifurcation theory.. This is surveyed

著者 Zhou Chunhong, Sun Minghua, Zhao Tianliang,

Section 3 is first devoted to the study of a-priori bounds for positive solutions to problem (D) and then to prove our main theorem by using Leray Schauder degree arguments.. To show