学校コーディング割り当て用サーバー
私たちの大学では、入門的なC++コースが毎年提供されています。学生がC++でコーディングして課題を提出するために、Linuxサーバーへのシェルアクセスを学生に与えます。彼らはsshを使用して自分のアカウントでサーバーにログインし、コーディングを行い、コンパイルされたコードをホームディレクトリに保存します。ただし、シェルアクセスを許可すると、シェルに多数の脆弱性がもたらされます。私の質問は、シェルに学生にアクセス権を与える以外に、上記の目的を達成する方法はありますか？サーバーのセキュリティを損なうことなくc ++の割り当てを行うためのインターフェースを学生に提供できるサーバー側のツール/アプリケーションはありますか？
必要なものは比較的単純です。学生の特権のないアカウントが適切に制限されていることを確認する必要があります。グラフィカル環境が関与していない場合、状況は比較的単純です。まず、次のアクションを実装する必要があります。
- ユーザーが管理者権限なしで作成されていることを確認します（
Sudo、admin、またはwheelグループなし） - ログイン画面を偽装するためにユーザーがログイン画面をエミュレートできないことを確認します（これは私が見た大学のクラシックです）
- ユーザーがホストを一時停止/シャットダウンできないようにする適切な
polkitdポリシーを確認します - ホストで脆弱な/古い
suid/sgidサービスを実行しないようにしてください（ それらのリスト方法を参照 ） - 個々のユーザーがシステムのリソースを使い果たすことができないことを確認します（各ユーザーのセッション全体にリソース使用制限を課すために Systemd.cgroup を構成することにより）
- sELinuxをインストールして適切に構成することで必須のアクセス制御を強化しますSELinux（学生が自分の家と/ tmpにのみ書き込むことができる学生の役割に制限するため）
- 必要に応じてアカウントを期限切れにして、最終的にパスワードが侵害されたアカウントを長引かせないようにします（ nixサイトでこの質問を参照 ）
- Linuxd名前空間 を使用して、完全に機能するシステムを互いに独立して実行するように設計された Systemd.nspawn を使用して、学生のセッションを別のコンテナーで実行することもできます。これは、
chrootではなく、セッションをjailする適切な方法です。
次に、生徒が許可された以外の目的でマシンを使用していることに気付くでしょう。 pam_time を使用して、マシンへのアクセスを特定の時間に制限することができますが、これは学生が仕事をするのを邪魔する可能性があり、それが提供する利点とバランスを取る必要があります。また、ネットワーク管理者が望ましくないトラフィックを検出できるように、このホストで予期されるトラフィックを知っていることを確認してください。
これらすべてが言われていますが、特定のバイナリをホワイトリストに登録することには意味がありません（学生が独自のコードをコンパイルして実行できるため役に立たない）。代替コンパイラ、ビルドツールチェーン、コード分析ツール、コードバージョン管理ツールなど.
ユーザーが害を及ぼすことができるのは自分自身であり、それが確実に保証されている限り、仕事は完了です。とにかく、これは長期的な生産システムではなく、学生は教育用コードをいじるのにのみ使用しています。
はい、あります。はじめに、SSHを使用することは悪い考えではありませんが、セキュリティを向上させるために、次のことを実行できます。
- Chroot刑務所を使用して、SSH経由で限られた環境にログインするすべての「学生」ユーザーをロックします。
- それらにSudoアクセスを与えないでください。代わりに、sudoersリストの特定のスクリプト/コマンドを使用して、管理コマンドの限定されたサブセットを許可してください。
- 1024を超えるポートではサーバーをパブリックにアクセスできないようにします（スクリプトキディアクセスを防ぐために、大きなポート番号でsshを実行します）。
- その間、sshキーを使用してログインすることをお勧めします。これらは、セキュリティの観点から、ユーザー名/パスワードアクセスよりもはるかに優れています（パスワードで暗号化されている場合）。
- 代わりに、これにgitおよび継続的な統合を使用できます。 （たとえば、GitlabとJenkinsのコンボ）これには、安全なWeb環境を介してのみアクセスを許可できるという追加のボーナスがあります（TLS設定を使用する場合は「https」、適切な証明書を使用してください）。すべてのアクセスは監査可能です。
はい、代替アプローチがあります。しかし、あなたの質問は欠陥のある仮定に基づいていると思います。より多くの人にシェルログインを許可すると、明らかにセキュリティに影響が出ますが、結果として得られるシステムのセキュリティを効果的に管理できないことは、定義上必ずしも意味するわけではありません。これらのシステムはマルチユーザーシステムとして設計されており、セキュリティを危険にさらさない方法でこのアクセスを管理する機能を備えています（または、少なくとも許容レベルまでリスクのレベルを管理します）。これらの環境での実際の課題は、通常、これを行うためのリソースがないことです。たとえば、単一の学生のプロファイルで十分である可能性は低く、さまざまなニーズを反映するプロファイルが必要になります。入門プログラミングコースは、おそらくネットワークプログラミングまたはシステムプログラミングのコースと同じアクセスを必要としません。次に、問題は、これらすべての異なるプロファイルを管理し、それらが適切であることを確認するのに十分な時間を持つことになります。
そうは言っても、この時代には、より管理しやすく、より適切である可能性が高い代替のアプローチがあると思います。たとえば、仮想マシンの使用は非常に生産的です。これらは、各生徒が互いに分離されるようにセットアップでき、仮想環境を既知の「良好な状態」に「リフレッシュ」できるように設定できます。次に、DockerやVagrantのようなものに基づいたソリューションがあり、学生が自分のマシンで標準的で一貫した環境を作成できるようにするために使用できます。サーバーは、生徒が作業を行うためにログインするプラットフォームではなく、生徒が自分で実行できる作業環境をダウンロードできる配布メカニズムになります。これにより、特定のコースの要件に合わせて調整されたカスタマイズされた環境を作成することもできます。