Open radek-otee opened 1 month ago
Hi @ben-grande! A quick question on the management and interaction with the
dev
qube. (relates to [#68])
Hello, good that you have read previous issues.
Since the
qusal.ConnectTCP
policy allows for managing access with the outside world, what is the intended/recommended procedure for adding libraries and packages required for various projects securely? I have followed the cited ideas and created arust.install
state (using this one as an example),
Missing link?
now I would like to add things through
cargo
. Same question applies topip
- orpoetry
-based packages for python etc.
The only integration by default for dev
with qusal.ConnectTCP
is SSH because it allows to connect to a proxy through a command and because Git integrates well with SSH.
I don't think pip
and cargo
have such proxy command option, although both of them have HTTP Proxy settings. Just brainstorming, but untested as I don't have a formula that uses pip or cargo on a qube without a netvm:
qubes.ConnectTCP
;~/.cargo/config
or ~/.config/pip/pip.conf
) and test the proxy configuration by pulling sources;Qubes uses Tinyproxy for the qubes.UpdatesProxy
, it possibly can be replicated for the above setup but note that tinyproxy may be stopped on some qubes as they are not needed in all netvms as per Qusal setup.
Note this is harder to restrict than Git+SSH so less secure. It may be better than direct network access and Qubes Firewall as it only works with IPs and not DNS records (in case the proxy supports DNS based filtering). If you are not able to configure your HTTP proxy setup, I recommend using a qube with a netvm, it is better to be able to have a working solution than nothing at all.
If you complete this, a write up or formula would be nice if contributed.
Missing link?
I will PR this to you, but it's a spinoff from install-python-tools.sls
with debian packages for rust documentation, a compiler and a package manager - nothing special really.
The only integration by default for
dev
withqusal.ConnectTCP
is SSH because it allows to connect to a proxy through a command and because Git integrates well with SSH.I don't think
pip
andcargo
have such proxy command option, although both of them have HTTP Proxy settings. Just brainstorming, but untested as I don't have a formula that uses pip or cargo on a qube without a netvm:
I believe (this at least was historically true) pip operates through port 3128, but not entirely sure it's still true - will investigate. That said the dev
qube does require a lot more flexibility if the template is to support multiple projects and technologies. I was thinking to create a sort of an "code execution powerhouse", but then it would render the dev
qube a glorified typing qube (why not develop directly in the code-exec
qube in this scenario), which is not at all intended. On the other hand, you probably didn't want to pollute the dev template with all technologies just in case someone may need it.
- From the netvm; install and configure an HTTP proxy;
- From the client, bind the HTTP proxy port of the netvm locally using
qubes.ConnectTCP
;- From the client, set proxy settings for your desired tool via configuration file (
~/.cargo/config
or~/.config/pip/pip.conf
) and test the proxy configuration by pulling sources;
cargo proxy <- your suggestions are making more and more sense :)
Any tips / templates on the config file? A quick google search reveals the following for pip
: https://stackoverflow.com/questions/14277088/what-url-should-i-authorize-to-use-pip-behind-a-firewall
- From the netvm, restrict domains the proxy clients can access with the proxy configuration allowlists.
Qubes uses Tinyproxy for the
qubes.UpdatesProxy
, it possibly can be replicated for the above setup but note that tinyproxy may be stopped on some qubes as they are not needed in all netvms as per Qusal setup.Note this is harder to restrict than Git+SSH so less secure. It may be better than direct network access and Qubes Firewall as it only works with IPs and not DNS records (in case the proxy supports DNS based filtering). If you are not able to configure your HTTP proxy setup, I recommend using a qube with a netvm, it is better to be able to have a working solution than nothing at all.
If you complete this, a write up or formula would be nice if contributed.
Happy to try it, see where it gets us :)
One more question: in your dev README, you state:
The installation will make the Qusal TCP Proxy available in the updatevm (after it is restarted in case it is template based). If you want to have the proxy available on a netvm that is not deployed by Qusal, install the Qusal TCP proxy on the templates of your netvm:
sudo qubesctl --skip-dom0 --targets=TEMPLATE state.apply sys-net.install-proxy
From there we would actually configure the proxy to be usable with dev
for the cargo
and pip
contexts. Where would be a good place to configure the proxy? I am new to Qubes and any pointers appreciated.
In a more general sense, how do you go about it? Presumably you also must have hit that wall when coding for multiple contexts?
Missing link?
I will PR this to you, but it's a spinoff from
install-python-tools.sls
with debian packages for rust documentation, a compiler and a package manager - nothing special really.
Please read the contribution guidelines before anything.
The only integration by default for
dev
withqusal.ConnectTCP
is SSH because it allows to connect to a proxy through a command and because Git integrates well with SSH. I don't thinkpip
andcargo
have such proxy command option, although both of them have HTTP Proxy settings. Just brainstorming, but untested as I don't have a formula that uses pip or cargo on a qube without a netvm:I believe (this at least was historically true) pip operates through port 3128, but not entirely sure it's still true - will investigate. That said the
dev
qube does require a lot more flexibility if the template is to support multiple projects and technologies. I was thinking to create a sort of an "code execution powerhouse", but then it would render thedev
qube a glorified typing qube (why not develop directly in thecode-exec
qube in this scenario), which is not at all intended. On the other hand, you probably didn't want to pollute the dev template with all technologies just in case someone may need it.
I don't plan to make the dev qube formula to fit all developers, that would not be possible even considering that developers using the same programming language can use multiple tools that may not intersect.
The dev qube covers the basics:
The one thing I would actually consider trimming from dev is the lint
part, it is too specific to my use of qusal and the utilities I use in the project. A separate state I shall organize.
So, adding new things even to the python installation has to be considered if it serves the needs of many and also doesn't put burden on the project. Installation from cargo and pip has been a no-go as the default installation method unless in special circumstances where external projects indicate to use those tools.
- From the netvm; install and configure an HTTP proxy;
- From the client, bind the HTTP proxy port of the netvm locally using
qubes.ConnectTCP
;- From the client, set proxy settings for your desired tool via configuration file (
~/.cargo/config
or~/.config/pip/pip.conf
) and test the proxy configuration by pulling sources;cargo proxy <- your suggestions are making more and more sense :)
Any tips / templates on the config file? A quick google search reveals the following for
pip
: https://stackoverflow.com/questions/14277088/what-url-should-i-authorize-to-use-pip-behind-a-firewall
No tips, haven't done it.
One more question: in your dev README, you state:
The installation will make the Qusal TCP Proxy available in the updatevm (after it is restarted in case it is template based). If you want to have the proxy available on a netvm that is not deployed by Qusal, install the Qusal TCP proxy on the templates of your netvm:
sudo qubesctl --skip-dom0 --targets=TEMPLATE state.apply sys-net.install-proxy
From there we would actually configure the proxy to be usable with
dev
for thecargo
andpip
contexts. Where would be a good place to configure the proxy? I am new to Qubes and any pointers appreciated.In a more general sense, how do you go about it? Presumably you also must have hit that wall when coding for multiple contexts?
Let's first separate the current qusal.ConnectTCP
to the proxy that will be used in this issue. They are different things. The RPC qusal.ConnectTCP
is not enough to solve this issue and the proxy that will be configured from this issue needs to be in a separate state, not in sys-net.install-proxy
.
A place to configure the proxy is in a networked qube, it doesn't need to be a netvm. If you are new to Qubes, read the upstream documentation about Qrexec.
Please read the contribution guidelines before anything.
will do
I don't plan to make the dev qube formula to fit all developers, that would not be possible even considering that developers using the same programming language can use multiple tools that may not intersect.
Agreed, I guess my point is for the dev
qube to become an extensible enough to be usable beyond basic bash and python in terms of programming, with as little loss of security as possible, since it is one of you design principles in this project.
So, adding new things even to the python installation has to be considered if it serves the needs of many and also doesn't put burden on the project. Installation from cargo and pip has been a no-go as the default installation method unless in special circumstances where external projects indicate to use those tools.
A potential counter-example for that would be that python without pip
is (by analogy) pretty much as paralysed as removing apt
from debian :) - I am thinking it's not the tool itself that the qube may potentially need, it's the possibility (and instruction) of setting it up if needed, with good sec practices that I am thinking about.
Always interesting to talk UX stuff :)
Commitment
I confirm that I have read the following resources:
Question
Hi @ben-grande! A quick question on the management and interaction with the
dev
qube. (relates to [#68])Since the
qusal.ConnectTCP
policy allows for managing access with the outside world, what is the intended/recommended procedure for adding libraries and packages required for various projects securely? I have followed the cited ideas and created arust.install
state (using this one as an example), now I would like to add things throughcargo
. Same question applies topip
- orpoetry
-based packages for python etc.Wondering what your thoughts are.
.