Toolbox: 開発中のコードのバグやマルウェアを防ぐための分離された開発環境

/ homeのない永続的なユーザーコンテナが必要ですか？ 要件/ユースケースをよりよく理解しようとしているだけです。 -標準の使い捨てFedoraコンテナを実行するのと比較して言いますか？

自宅と職場の両方で使用されるUnixアカウントについて考えてみます。 作業コンテナの場合、作業ディレクトリのみをコンテナにマウントすることをお勧めします。

信頼できないGUIアプリを考えてみましょう。 ファイルをロード/保存するために特定のフォルダにアクセスするだけでよい場合があります。 .sshフォルダーやその他の無関係なファイルにアクセスする必要はありません。

セキュリティを向上させるために、ChromeOSはデフォルトでホストからコンテナにフォルダを共有しません。 そこで、ホームディレクトリまたはUSBドライブからコンテナにデータを提供する場合は、明示的に共有します。

信頼できないコンテナにデフォルトですべてのデータを与えると、セキュリティ機能としてのコンテナ化は大きな価値を失います。

@juhp私はあなたがHaskellパッケージでかなり働いているのを見ます。 リモートでインストールしているHaskellパッケージの1つが危険にさらされていると想定します。 Haskellパッケージは.sshフォルダーまたはビットコインウォレットにアクセスする必要がありますか？ なぜデフォルトですべてをHaskell開発環境に共有するのですか？

ごく最近、インストールされた場合でもビットコインをローカル化できるNPMモジュールがありました。
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets

このモジュールは人気があり、実際、私のチームはそれをツリーにインストールしました。 ビットコインの盗難を引き起こす他の基準を満たしていませんでしたが、開発環境がデフォルトでホームディレクトリに完全にアクセスできなければ、そのリスクは完全に軽減されていたでしょう。 この開発環境でビットコインウォレットを共有することを選択した従業員はいませんでした。

これは完全に有効ですが、難しいでしょう。

実際には、ツールボックスを個別のユーザーとして簡単に実行できるようにするのが最善の方法だと思い/home持つ新しいuidを一時的に作成します）。これを行うには、特権システムサービスが必要です。

読み取り専用など、いくつかのファイルを共有したい場合は、面倒になります。

ディレクトリbind-mountからファイル/ディレクトリを除外することは可能ですか？

課題を確実に理解するために、ホームディレクトリのマウントは1行のコードで行われることがわかり

    --volume "$HOME":"$HOME":rslave

しかし、ここでの課題は、GUIアプリやその他の機能を機能させることです。これらの機能は、コンテナーの内側と外側のユーザーが同じであることを期待しているからです。

これは実際にはかなり重要な機能です。 デフォルトでホームにマウントするのは問題ないと思いますが、信頼できない方法でコンテナを使用することは可能であるはずです。 家をコンテナにマウントすることは、あなたがそのコンテナを信頼していることを前提としていますが、使い捨てのコンテナではそうではないことがよくあります。 一部のNPMモジュールをテストするような単純な場合でも、ホームフォルダが破壊されないという安心感があります。

@markstosおそらく、ホームマウントなしで何ができるか、または特定のディレクトリ（cwd）をマウントするだけで何ができるかをテストできますか？

@juhp実際、これは私にとって目を見張るものでした。この不足している機能に遭遇すると、Silverblueの評価を停止しました。 これに対処する場合は、Silverblueをもう一度見てみましょう。 また、以前使っていたOSであるUbuntuコンテナの実行方法がわかりにくいことに失望しました。

Fedoraが他のLinuxディストリビューションからのユーザーを歓迎したい場合は、古いディストリビューションをコンテナーで簡単に実行できるようにすることから始めるのがよいでしょう。

@markstosありがとう-私はもう一人のToolboxユーザーです。 :-)
より多くのOSをサポートするためにToolboxを拡張することは、確かに非常に役立つだろうということに完全に同意します。
ToolboxはSilverblueなしでも（つまり他のFedoraエディションで）動作することに注意してください。

@juhp実際、これは私にとって目を見張るものでした-この不足している機能に遭遇すると、Silverblueの評価をやめました

以前は何をしましたか？ Silverblueで機能しなかった、使用していた他のツール/アプローチはありますか？

たとえば、使い捨てVM（QubesOSのような）を使用したり、このスレッドからの提案の一部を実装するカスタムスクリプトを使用したりすることを妨げるものは何もありません。 間違いなく、私たちはもっと意見を述べ、QubesOSのような機能をSilverblueに組み込む必要があります。

しかし、とにかく既存のVMとコンテナテクノロジーはそこにあります。 実際、今日のtoolboxは、実際にはpodmanホストpodman run ...から始めることができます。これがデフォルトです。

@cgwalters個人のラップトップでCrostiniプロジェクトを通じてVM内のコンテナー内で開発環境（およびその他のほぼすべて）を実行することのセキュリティを高く評価するように
URL
代わりに、仕事用のラップトップで使用する同様のソリューションを評価してきました。 1つのオプションは、NeverwareのCloudready（PCハードウェア用のオープンソースChrome OS）です。 Crostiniがクラッシュし、データが失われ、最初からやり直す必要があるポートがある場合があります。 そのため、ChromeOS / Crostiniを2倍にすることを躊躇しています。

Silverblueは、Ubuntuコンテナーをすぐにサポートしていないように見え、信頼するつもりのないコンテナーと個人データを過剰に共有するまで、説得力があるように見えました。 ClearLinuxも調べました。 ほぼすべてをコンテナで実行するという同じ概念があります。 私はIntelとx86との緊密な関係にわくわくしていません。 また、主にデスクトップOSではありません。 最後の（デフォルト？）オプションは、デスクトップとしてUbuntuを使い続け、ChromeのCrostiniが使用しているLXDコンテナーに開発作業をさらに移動することです。 ホストOSが異なっていても、仕事用のラップトップと個人用のラップトップの間でLXDコンテナーをコピーできるはずです。 LXDテンプレートを使用して、Waylandサポート用のコンテナーに十分なマウントを共有するテンプレートをセットアップできるはずです。

補足：Rhythmboxを維持してくれたすべての年に感謝します！

おそらく私はtoolboxの使命を誤解しています。 READMEから：

..これらのシステムの目的は、ホストへのソフトウェアのインストールを阻止することです。

どうして？ デフォルトでは、すべての個人データをコンテナに共有することがデフォルトであり、セキュリティの向上を主張できるとは思いません。

残りの潜在的な利点は分離されるため、競合するバージョンのソフトウェアを並べてインストールできます。

常に共有する動作が残っている場合は、ドキュメントを更新して、 toolboxがホームディレクトリ全体をコンテナに共有していること、動作を無効にできないこと、信頼できないものと一緒に使用しないことを明確にすることが役立つ場合があります。コンテナ。

podmanを直接使用できるようになりましたが、GUIを統合したコンテナーソリューションに興味がありました。 podmanでそれを達成する方法を検索するときtoolboxを使用することをお勧めします。

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

@markstos興味があれば、Ubuntu 19.04イメージをビルドするPR＃298を作成しました。

ここには混乱があると思います。

私たちのREADME.mdは、数か月の間に少し成長して変化し、おそらく把握するのが少し難しいでしょう。 以前は、OSTreeベースのFedoraでハッキングと言っ

Silverblue（またはその他のOSTreeベースのOS）をインストールすると、OSのデバッグや開発環境のセットアップの難しさがすぐに明らかになります。 その問題を解決するためのツールボックスが存在します。

..これらのシステムの目的は、ホストへのソフトウェアのインストールを阻止することです。

どうして？ デフォルトでは、すべての個人データをデフォルトでコンテナに共有します。
セキュリティの向上を主張できるとは思わないでください。

セキュリティは過負荷の言葉です。 Toolboxはそれについて何の主張もしません。

何十年もの間、UIDとして実行されているプロセスは、秘密の暗号化キー、ドキュメント、写真などを調べ、知らないうちに地球の半分まで送信する可能性がありました。 これは、自由ソフトウェアクライアントOSの現状です。

Flatpakは、各グラフィカルアプリケーションとオペレーティングシステムを独自のセキュリティドメインに分離することで、

ただし、冒頭で述べたように、このロックダウンされたOSイメージには独自の問題があります。 それらをどのように解決するかは、利便性とセキュリティの間のトレードオフです。 ソリューションが根本的であればあるほど、既存のLinuxユーザーがSilverblueを採用するのは難しくなります。

現時点では、Toolboxはセキュリティよりも採用に傾いています。 Toolboxを使用しているかどうかに関係なく、SilverblueはフリーソフトウェアクライアントOSの状態を大幅に改善し、それをユーザーの手に渡すことは前向きなステップになるからです。

さらに、それはセキュリティだけではありません。 安定性も重要です。

従来のLinuxディストリビューションをテストすることは非常に困難です。 パッケージとミラーは、世界中のランダムミラーのランダムな寄稿者によって常に更新されています。組み合わせ爆発は、精巧なフリーズシステムによってのみ管理できます。 問題が発生した場合、ユーザーが更新を元に戻すことも非常に困難であり、更新の途中で停電が発生すると、システムが回復不能になる可能性があります。

OSTreeベースのOSはそれをすべて変えます。

podmanを直接使用できるようになりましたが、GUIを使用したコンテナソリューションに興味がありました
統合。 podmanでそれを達成する方法を検索するとき、ツールボックスを使用することは
推奨されるアプローチ：

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

問題は、なぜPodmanを使用してグラフィカルアプリケーションを実行したいのかということです。 :)

一般に、Podman（またはOCIコンテナー）はGUIアプリを実行するための悪いオプションです。 それがFlatpakが存在し、Toolboxがそれと競合しない理由です。

ただし、Toolboxコンテナーにはデスクトップが統合されているという意味で重複があり、Flatpaked以外のGUIアプリを実行する機能が短期的に非常に役立つ場合があります。 必要なアプリケーションがまだFlatpakedされていないか、Flatpakedバージョンにいくつかの機能が不足している可能性があります。 グラフィカルアプリケーションで使用されるライブラリで作業していて、1回限りのテストプログラムをすばやく実行して、ライブラリが期待どおりに機能しているかどうかを確認したい場合があります。

Toolboxは確かにそのような場合に役立ちますが、それはToolboxの主な目的がグラフィカルアプリケーションをコンテナ化することであると言うこととは異なります。 Toolboxの主な目的は、OSTreeベースのOSでハッキングを実行できるようにすることです。

これで、Flatpakとして出荷されるGNOME BuilderのようなコンテナーネイティブIDEを使用していて、作業中のソフトウェアをビルドして実行するためのコンテナーを自動的にセットアップする場合、Toolboxはまったく必要ありません。

ただし、すべての人がGNOME Builderを使用しているわけではなく、Visual StudioCodeなどの最も人気のあるIDEはそのようなコンテナネイティブではありません。 したがって、ツールボックス。

@debarshiray思慮深く徹底的な対応に感謝します。 上記の例は、Flatpakでカバーされる可能性のあるグラフィカルアプリ用ではありませんでした。 Node.js開発を行う例を示しました。 最近、Node.js依存関係チェーンに、ローカルの暗号ウォレットから盗む可能性のある実際のマルウェアがありました。 SSHキーも同じように簡単に盗まれる可能性があります。 READMEによると、プロジェクトは開発者を対象としていますが、デフォルトでは、share-with-containersは、開発者をその種の攻撃から保護するものではありません。

Toolboxは、信頼できない依存関係でCLI開発を行う場合、個人ファイルの盗難からの安全性を提供しません。 最新のオープンソースソフトウェアの複雑さを考えると、信頼されるべきではない依存関係ツリーのいくつかの部分が必ずあります。

現在のREADMEは誤解を招くと思います。「コンテナ内で完全に非特権」を実行することはセキュリティのように聞こえますが、それはセキュリティシアターにすぎません。すべての個人ファイルは、コンテナ内でアクセスできます。 上記で、Toolboxがセキュリティについて主張しないことを意図していることを明確にします。 これは、コンテナを使用しているにもかかわらず、これはセキュリティではなく利便性のためのツールであることを明確にするために、READMEに含めるのに役立つステートメントだと思います。

@debarshiray思慮深く徹底的な対応に感謝します。 私が与えた例
上記は、Flatpakでカバーされる可能性のあるグラフィカルアプリ用ではありませんでした。 私は
Node.js開発を行う例。 最近、Node.jsに実際のマルウェアがありました
ローカルの暗号ウォレットから盗む可能性のある依存関係チェーン。 SSHキーが盗まれる可能性があります
同じように簡単に。 READMEによると、プロジェクトは開発者を対象としていますが、
share-with-containers-defaultは、開発者をその種の攻撃から保護するものではありません。

はい。現時点では、ToolboxはイメージベースのOS内で従来のパッケージベースの環境を再現しようとしているだけです。

現在のREADMEは誤解を招くと思います：「コンテナ内で完全に非特権」で実行している
セキュリティのように聞こえますが、それはセキュリティシアターだけです-すべての個人ファイルはでアクセス可能です
コンテナ。 上記で、Toolboxがセキュリティについて主張しないことを意図していることを明確にします。
それにもかかわらず、それを明確にするためにREADMEに含めると便利なステートメントになると思います。
コンテナの使用、これはセキュリティではなく利便性のためのツールです。

コミットc047659c1d85ca982374da5c58ee7a24ba3847bdは、その行が追加された場所です。 @cgwaltersは、ツールボックスコンテナ内の独自のUIDにのみアクセスでき、実際のルート（つまり、ホスト上のUID 0）は関与しておらず、利用できないことを意図していると思います。

私も同じ問題を抱えています。 SSHキーやその他の機密情報を盗むことを心配せずに、完全に信頼できないソフトウェアを実行できることを期待して、Silverblueをインストールしました。

ツールボックスではこれができないことに気づいたことは大きな失望であり、そもそもSilverblueの使用を再考することになりました。 個人的には、メインOSのインストールは気にしません。 私はいつでもそれを再インストールすることができます。 本当に分離したい情報は、私のホームディレクトリにあります。

ホームディレクトリのどの部分を共有するかを、より細かく指定することは可能でしょうか？ ツールボックスに必要なディレクトリ（おそらくデスクトップ構成に関連するディレクトリなど）だけをホワイトリストに登録できれば、多くの問題が解決します。

今、私はセキュリティの問題を完全に認識しています。 私はQubesOSを数年使用しているので、分離の問題は難しいものです。 ホームディレクトリを保護しても、コンテナ内で実行されるプログラムはクリップボードなどのコンテナ間の他の通信手段を常に利用できるため、それだけでは十分ではありません。 私はこれを認識しており、完全なQubesインストールと比較して、ツールボックスのようなものの利便性と引き換えに、これらのリスクのいくつかを受け入れたいと思っています。

回避策はここに公開されてい

この回避策は、 /home/userのパスを検索する必要があるすべての場合に、環境変数$HOMEを参照するbashスクリプトとしてtoolboxが実装されているという事実を利用しています。 だから、環境変数設定することにより、 $HOMEへの特定のコールのためのtoolbox潜在的に信頼されていないコンテナと共有するための貴重な個人的なファイルの完全なあなたの全体のホームディレクトリ以外のディレクトリAAの原因となります。

これに基づいて、次のようなラッパーを使用してツールボックスを起動することにより、ツールボックス構成のみを含む空のディレクトリを共有できるようです。

#!/bin/bash
mkdir -p ~/toolboxes
HOME=~/toolboxes "$@"'

このスクリプトにtoolboxという名前が付けられ、システムtoolbox前に$ PATHを配置すると、この懸念に対処できるように見えます。 このソリューションはテストされていません。

この機能は現在、 tlbxフォークで機能しています： https ：

私も同じ問題を抱えています。 できることを期待してSilverblueをインストールしました
SSHを盗むことを心配せずに完全に信頼できない可能性のあるソフトウェアを実行する
キーおよびその他の機密情報。

うーん...これは誤解を招くようです。 信頼できないソフトウェアをユーザーとして実行したい場合、Flatpakは機密情報を失うことについての心配をすでに減らしています。 分離された開発環境が必要な場合、それは別のことです。

また、これはシルバーブルー固有のものではありません。 問題は何十年も前から存在しており、ソリューションはSilverblue固有のものではなく、従来のパッケージベースのOSでも機能します。

回避策は、 toolboxがbashスクリプトとして実装されているという事実を利用しています。
/home/userパスが存在するすべての場合に、環境変数$HOMEを参照します
調べる必要があります。 したがって、特定の環境変数$HOMEを設定することによって
toolboxを呼び出すと、ホームディレクトリ全体以外のディレクトリが貴重なものでいっぱいになります
信頼できない可能性のあるコンテナと共有される個人ファイル。

はい、それはきちんとしたハックです。 :)

ただし、Toolboxプロジェクトの主な目的は、イメージベース（特にOSTreeベース）のオペレーティングシステムで、パッケージベースのオペレーティングシステムとほぼ同じ量の労力でさまざまな開発環境をセットアップできるようにすることです。 これらの開発環境をより安全にすることは確かに有効な望みですが、問題は新しいものではなく、永遠に存在しているため、すぐにやるべきことのリストに載っているものではありません。

また、Silverblueは必ずしもセキュリティに関するものではありません。 私はそれをオペレーティングシステムの安定性と堅牢性の改善としてより多く見ています。 ただし、Flatpaksの使用を奨励しているため、その意味で間接的にセキュリティが向上します。

したがって、既存の問題の一部が残っている場合でも、パッケージベースのLinuxディストリビューションと機能の同等性を確保することには価値があります。 何も解決しないよりも、いくつかの問題を解決し、既存のユーザーベースがソリューションにアクセスできるようにする方が優れています。 :)

未解決の問題のリストが暴走しないように、この問題をクローズし、現在のやることリストにある項目を大まかに反映し続けます。 ただし、今後の参考のために引き続き使用します。

ただし、 README.md方が読みやすいはずだということに同意します。

うーん、私はその議論を理解していません。 問題が古くて永遠に存在しているという理由だけで、それを解決しないのですか？ それは良い見方ではありません、私見。
そして、あなたが言うように、flatpakはそれを行います：それは段階的にセキュリティを改善し、アプリケーションを分離します。 彼らはまた、「うーん、アプリをrpmパッケージとして永久に出荷しました。なぜこの問題を解決する必要があるのですか？」とは言わず、ただ解決しただけです。

ツールボックスが少なくともホームディレクトリも分離してはならない理由はわかりません。 とにかく、 https：//github.com/containers/toolbox/issues/348で議論を続けることができると思います。

ツールボックスの寄稿者とメンテナは、このスレッドを、プロジェクトに投入されたアイデアと作業のバッシングとして受け止めていると思います。 アイデアにワクワクする多くの人に求められる機能だと思います。 $ HOME以外の作業ディレクトリをマウントできる機能に取り組むことに抵抗はありません。 これは、機能とユースケースを大幅に改善できる機能であり、採用と関心も向上します。

私は＃348で$ HOME変数を変更することを提案した人でした。 $ HOMEディレクトリが異なる2つの複数のコンテナを操作する場合に問題が発生するため、これはハッキーなソリューションです。 ツールボックスをgoで書き直すと、これでも機能しないのではないかと心配しています。

多くの人がこの機能を求めており、多くの人がツールボックス、rpm-ostree、silverblueを採用することは参入障壁になっています。 セキュリティに関するものでなくても、ツールボックスを操作するための多くの可能性を開く機能です。

できればこの問題について喜んでお手伝いしますし、他の人も喜んで手伝ってくれると思います。 この機能が論点にならず、将来のツールボックスリリースから除外されることを願っています。 私の意見では、現在そこに欠けているのはそれだけです。 最後の10メートルをやめたので、マラソンでdnfを取得するようなものです。 （しゃれを意図した:)）

それは私にとって大きな問題でした。 後でツールボックスとSilverblueをあきらめました
この欠陥を見つける。

問題が古く、永遠に存在しているという理由だけで、
ただそれを解決しないのですか？ それは良い見方ではありません、私見。

すぐにやることリストに何かがないことは、それを解決しないことと同じでは優先順位などがあり

そしてあなたが言うように、flatpakはそれを行います：それは段階的にセキュリティを改善し、
アプリケーションを分離します。 彼らはまた、「うーん、私たちはアプリを
rpmパッケージは永遠に、なぜこの問題を解決する必要があるのでしょうか？」
それを解決します。

私は彼らという言葉のあなたの使用が大好きです。

いいでしょう、それで私がそれを正しく解釈すれば、これはあなたの「即時のやることリスト」に載っていないだけでなく、将来のアイデアかもしれませんか？ （実装は簡単だと思いますが、特にフォークからパッチをチェリーピックできる場合はなおさらです）*

もしそうなら、たぶんこの問題を開いたままにして、「助けが必要」というタグを付けてください–本当に助けは必要ありませんが、わからない…これを実装するのを妨げるものは何ですか？ このトピックに関するPRを受け入れると言うだけで、実装されると思います。
それを妨げるものは何もありません。それでも、機能の同等性などを達成することはできます…それは実際にはマイナーな機能にすぎません。 ：考え：

*はい、これがGoで書き直されていることを確認しましたが、それでも役立つかもしれません–dunno。 少なくとも、実装が簡単であることを示しています。

参加者のいずれかがhttps://gitlab.com/bkhl/etuiで私のプロトタイプをチェックアウトしてフィードバックを提供したい場合に備えて、この問題を少しハイジャックし

これは、より厳密に含まれた開発コンテナが必要な場合のToolboxの代替として意図されています。

@bkhlありがとう！ ブックマークしました。