Try it like this with single quotes inside double qoutes:
socat TCP-LISTEN:54321 EXEC:"'qvm-run --pass-io testqube socat STDIO TCP:localhost:12345'"
I don’t have other ideas besides using qvm-run.
But I’m not sure that this is a problem with Qubes OS version. And even if it is, there should be another way to make it work for Qubes OS 4.1.
I don’t know about this either.
In-place upgrade won’t work.
It starts the virtuals to do the upgrade, then says it can’t shut the virtuals down.
So I think that 4.2 is still way too buggy.
I mean 4.1 is bad enough with it’s bugs, but 4.2 won’t even install.
I was just letting you know that it won’t install so you know that I can’t even upgrade to it to see if that is the issue. I can’t install a new one, nor can I do an upgrade.
Maybe I should just go back to Qubes 3 where things actually worked properly and nice and fast with less issues… or version 2 where there was even more flexability and issues…
But 3 won’t install on my hardware… 2 won’t install either… the installers just crap out as they seem to not be able to handle AMD hardware.
So I’m forced to use 4.
Ran this one.
The command worked this time. No error when running it.
HOWEVER…
When I performed the “nc localhost 54321”
" socat[PID] E connect(5, AF=2 127.0.0.1:12345, 16) Connection refused "
Unfortunately, it didn’t work the way we hoped yet.
All I want is a simple connection TO and FROM a guest on whatever port I want using TCP or UDP, whichever I require.
I’ve rebuilt qubes multiple times to try to get the remote connection working for the remote GUI too.
Did you have nc -l 12345 running in testqube?
You can test it with some other service running in testqube instead of netcat as well. For example, if you have http server running in testqube with port 80 on localhost then you can test the connection with curl:
In your testqube start http server on port 80.
In dom0 run:
socat TCP-LISTEN:8080 EXEC:"'qvm-run --pass-io testqube socat STDIO TCP:localhost:80'"
In dom0 run:
curl http://localhost:8080
Firstly, yes I did have that running in “testqube”.
I had everything set up the way you had told me.
The HTTP version worked fine.
I got the webpage accurately from the virtual.
The next thing would be getting data back the other way.
Because it needs to be a constant connection with data travelling both ways over the connection, not just a one time thing with one command and a response.
Or will that keep an open connection to the virtual for as long as there is no command running?
Mine might be a naive question, feel free to disregard.
If you establish a two-way data connection between two qubes, then those two qubes’s security level become essentially the same. (I’m thinking Biba model here.)
If dom0 will end up at the same level than an arbitrary qube (say “qube A”)… I’m not seeing the point of either:
- using Qubes OS for that task, since compartimenlatization from “qube A” is not reliable anymore if data flows into dom0 from “qube A”, and if all other qubes are within reach of “qube A”… we’re in a regular OS scenario with unnecessary added complexity?
- or not running whatever you do on “qube A” in dom0 instead, which seems like it would be equivalent security-wise but simpler?
Again, it sounds like I’m missing or misundertanding something, please correct my thinking!
No question is Naive. If you don’t know then you don’t know.
Actually, the security would not be as compromised as the virtual.
There are multiple reasons for this…
- You are only openning the ports you desire.
- There is only the communication you desire.
- It isn’t an unrestricted flow, it’s only between Dom0 and the DomU, so there is no external access, pathing or routing.
3.1 This means that if Dom0 tried to connect out to the internet, it could not.
3.2 Commands on Dom0 can’t be run directly as it is not console connection.
3.3 The vulnerability is only as vulnerable as you want it to be. (Any admin knows that if you lock it down there is no issue.) - There is the remote access variant through Whonix, that uses more insecure things and has more security holes than what I’m doing.
I would preferr to attach a NIC to the guest, as I know what I’m doing security wise and would be locking the system down in a big way. I’m not just openning it up on all things, I’m just wanting to have one port open for access from the virtual.
Not from outside connections.
Does this make sense?
1 Like
The open port is already a two-way communication.
You can even create a tunnel through this port with VPN or SSH.
As long as socat is running in dom0 and service is running in testqube it’ll keep the connection.
Thing is that this did not happen.
I used multiple terminals.
First I had it using port 8080 and 80 for the web, after the first request, it stopped and killed it.
Next I tried with the software. It did the first connection and then the connection stopped.
Yes, socat command stopped and terminated after the execution.
So I don’t know what went wrong or anything like that. But I will keep looking into it.
I mean the connection should just keep functioning from the start of it and not stop.
So yes I am confused regarding it.
This little thing is the only thing that I am in need of getting working to complete the tasks I need to do. But it has been annoying me for a long time.
I have tried running socat in the virtual as well to hopefully fix it, but it did not.
It resolves many issues trust I have had with other things having that ability.
As long as it is only a connection between dom0 and the domu that I want that is fine, as I will be using the same ports on the external nic.
Maybe there is a bigger difference between your version and mine than either of us had thought?
What operating systems are you using for the testing using it?
Maybe that could have the bigger issue?
Add fork option:
socat TCP-LISTEN:8080,fork EXEC:"'qvm-run --pass-io testqube socat STDIO TCP:localhost:80'"
Hi App, that worked perfectly. Exactly what it was missing, even though I did not really want it to fork and make multiple connections or instances, but it can’t be access from outside the PC on that port and all, so they is brilliant.
Only problem is… Once I set it up to start automatically, it killed the machine. DM-RAID startup would not complete.
So I have to completely rebuild the system again.
Any thoughts on why this might happen? It did take ages to shut the machine down, and the guest would not easily shut down either.
So it took a very long time… over an hour to shut down.
What’s your systemd service looks like?
Maybe you’re starting socat before Qubes OS services are started so qvm-run is not working?
Also make sure to add systemd stop command.
I’ll have to see if I can recover the file. But it should not load before all virtualisation because I told it that virtualisation is required.
Qvm-run is a command in the virtual and it said for the connection. So that could be an issue.
However it should not stop the DM-RAID from starting as it has to start before it can load the SystemDumb crap anyway.
But it just fails at the DM-RAID, and I did enter the correct decryption key. Everything should have been all good.
I’ll pull out my work qubes drive later tonight and do a decrypt on it to get the files. At the moment I have the drive doing a long smart test to see if the drive started to fail.
This pipe is the only and last piece I need to have working to finish off the server and get everything up and running completely.
Thanks again for your assistance in the matter. It really is just the startup for it that needs to be fixed.
And yes, I hate MicroSoft SystemD. Implemented only to try to turn Linux into Windows.
Maybe you’ve used the wrong service type:
https://wiki.archlinux.org/title/Systemd#Service_types
Did you try with Type=simple?
I just copied from another one to get the template to create it.
So all I did was remove everything that was not needed.
That I did not try, I don’t think it even has a type, it was just a single execution from what I remember.
Just executes a single shell script.
I’ll have a read of what the SystemD spyware does in more detail on that page as to the options and go from there.
Thanks.
Well, QVM-RUN doesn’t need to be active for the thing to be run, since the connection won’t take place until the login screen appears.
I am still having issues trying to get it to start up. Tried multiple things and nothing seems to stick yet.
This is what I have for the service…
[Unit]
Description=SHServer Access
After=qubes-db-dom0.service libvirtd.service xenconsoled.service qubesd.service qubes-qmemman.service
[Service]
Type=basic
ExecStart=socat TCP-LISTEN:9090,fork EXEC:“‘qvm-run --pass-io SHServer socat STDIO TCP:localhost:80’”
RemainAfterExit=yes
[Install]
WantedBy=sh.service
I removed the
"
[Install]
WantedBy=sh.service
"
as it isn’t needed that I know of.
But it is needed to be able to get things going I think.
Try it like this:
cat << 'EOF' | sudo tee /etc/systemd/system/socat.socket
[Unit]
Description=socat
[Socket]
ListenStream=127.0.0.1:9090
Accept=true
[Install]
WantedBy=sockets.target
EOF
cat << 'EOF' | sudo tee /etc/systemd/system/socat@.service
[Unit]
Description=socat
[Service]
ExecStart=/usr/bin/socat STDIO EXEC:“‘qvm-run --pass-io SHServer socat STDIO TCP:localhost:80’”
StandardInput=socket
StandardOutput=inherit
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now socat.socket
Interesting way to do it.
At the moment I have a 60 second delay in a bash script that runs the command and a few other bits. So the system should be fully up and running by the time the connection tries to establish itself.
I don’t understand why you have sudo and tee and all that extra crap in there.
But yes my bash script runs as a normal basic service like you mentioned. I removed all the extra stuff from it to leave it as just a few lines.
But how can I get the service to run after the specific guests have started?
I can’t figure that one out using systemd.
The bash script just checks with the system using XL to see if the 3 visuals have started or not. If they have started then it runs the command, otherwise it waits another few seconds before retrying.
But right now I’m just working on the networking site of things and performing the pass through between the guest and the internet to accept an incoming connection and setting that on the networking.
Currently harder than it used to be in qubes 3.
But then again all of it is easier in the earlier versions. But that is what happens when people try to fix something that isn’t broken.
I appreciate the help with this issue, you have given me plenty of answers and guided me to many thoughts and ideas that I can now achieve.