Is it possible to request this as a feature here on the forum?
Unfortunately i do not have a GitHub account 
Me too, but nope. You can ask someone to do that instead of you, if interested in. But, frankly, given my experience so far I doubt it as this can be seen as a matter of convenience. And the word isn’t too welcomed in Qubes world, hahaha (too few devs)
IIRC the idea was dismissed.
I guess it’s mostly a security issue: If you get a random focused popup from qrexec with a preselected domU while typing something, accidentally hitting just Return is more likely than some Arrow + Return.
And if you always allow it, you can just put it in the policy.
Well…
The alternative is even more insecure: Allowing it every time without user interaction…
This would be something that the user has to configure, so of course one has to know what he/she is doing when tinkering with qrexec rules.
The problem i am facing is: I want to only allow disp1234 to access disp1111, and disp9999 to access disp2222 but the names are not known when the rule is written, as those are disposables. So i have to allow the whole class of dispVMs to access the other, that would allow disp1234 to access disp2222 and i don’t want that.
I think what you need is a named disposable, just look at how default service like disp sys-net, firewall, usb.
2 Likes
Good idea, but that is not easily possible in my use case.
I am creating disposable split-ssh qubes on demand, so there likely are more than one vaults.
I have considered this: Make the names deterministic and “preload” 100 or so rules with the predetermined names. But then i need to keep track of how many split-ssh clients and vaults are running. I would consider this an acceptable hacky solution, but that is certainly not how i want to solve that.
Then consider using vm tag, would that do ?
1 Like
That is what i have right now. I have a tag for the clients and one for the vaults.
But this way every client could (in theory) access every vault. The only thing preventing that is that the client a does not know the name of vault b.
If one gets compromised it could then start brute forcing the names of vaults, probably with me not noticing if i leave the PC. Unlikely but possible. That is why i would love to just give another “Yes, go ahead” confirmation.
Then use a dedicated template for those disposables and allow that.
Possibly the qrexec policy doesn’t allow filtering by templates (I don’t remember anymore), but it allows filtering by tags. So you would have to tag the template with qvm-tags. IIRC tags are inherited to disposables based on that template and tags are supported in the qrexec policy.
Yes, that is what i do right now.
However this allows all clients to access all vaults, not only the one they are assigned to.
Why isn’t setting ask in policy enough for what you want?
All clients to access all vaults, only if you specifically allow them on ask?
This is what i want.
I want to confirm any access of any split-ssh client to their corresponding ssh-vault to be confirmed by me.
The problem is, that every split-ssh client has its own split-ssh-vault corresponded.
Say i want to talk to one of my servers. I initate this, so 2 qubes are created: disp1234, that is my split-ssh-client and disp1111 that is the ssh-vault that only holds the one ssh-key to that server. In the meantime i am working on another server of mine, so disp34567 is created as the ssh-client with the disp2222 qube holding the ssh-key to it…
If disp1234, a ssh-client, wants to access the corresponding disp1111 ssh-vault to create the response for my remote machine, there is a prompt to ask me for confirmation.
This prompt wants me to enter “disp1111” as the target qube, as it cannot be prefilled with the qube the ssh-client wants to talk to.
If i would only handle one singular ssh-client, this might be possbile, but when dealing with multiple ssh-clients, it is totally unrealistic for me to know that disp1234 is only supposed to talk to disp1111, and not disp2222.
I want the target qube to be prefilled by the domUs choice. What i see is “ok, this qube send only one singular request. It surely knows what it is doing, i initiated the qrexec call so it is fine” and confirm this.
The alternative would be to allow any ssh-client to talk to any ssh-vault, so bruteforce gets possible.
a rogue disp111 could start trying disp0001, disp0002 and so on until it hits others that have keys it is not supposed to have if i allow any ssh-client to access any ssh-vault. This is what i want to avoid by having the confirmation.
Ah, I see now, and as i see it it is close to my question to you on another topic.
So, you don’t know that disp1234 should talk only to disp1111.
I can’t think it through in details because I don’t still use it, but I am almost sure that this can be done via Admin API.
For each par of s-ssh client and vault (or server? that’s where I’m lost), another adminVM creates template, dvm-template and vault.
created-by tag should allow interacting disposable and vault related only to that server. That’s how you’d get prefilled dialog box
I’m not sure if my understanding of your goal is right, or, if it is, that I am clear enough, but I am sure that sticking to tags resulted from adminVM would resolve this, one way or another, even if that considers some scenario adapting.
I am using Tags right now.
So my ssh-clients have the tag “ssh-client” and the vaults have the tag “ssh-vault”. However with this i can only restrict the ssh-clients to only talk to the ssh-vaults.
This would not restrict a rogue ssh-client to only talk to it’s ssh-vault. That is what i ideally want.
What tag, please give an example?
Well,
my rule right now is “Allow all qubes with “ssh-client” tag to talk to “ssh-vault” tag qubes”.
I cannot say: This one qube (disp1234) is only supposed to talk to this one other qube (disp1111). My confidentiality of secret key is only dependent of “ssh-client disp1234 does not know that qube disp2222 does know keys ,disp1234 is not allowed to know”. It could request it if it knows the qube name.
I could give the admin VM rights to modify the rules, to set this in dom0 on runtime but it would be able to modify any rule, leading to it gaining absolute control over any qube in my system. I am not doing that lol.
I can increase the namespace of this qubes, so brute force attacks will take longer, but this is only a mitigation for the problem, not a fix.
I am talking about the specific tag
@tag:created-by-adminVM-to-manage-server1
Such a tag is automatically created and I am still not sure if you are aware of it and that as such it can do basically whatever you want.
Are you sure you can’t recognize the way to reach your goal in
and
As I see it, your question should be how to prevent one dvm-template created by one template created by one adminVM, to create more than 2 dispxxx (if that is necessary at all, and one answer to this is named disposables as already suggested, and the other could be something I read here and am trying to find it at the moment), and not your question should be how to prefill
1 Like
Thanks for pointing that out!
I am aware of that. The created-by-vm tag is how i confine my admin VM to the vms it creates.
Your linked post was essential for me figuring out the admin VM stuff.
Both, the ssh-clients and the ssh-vaults are created by the same admin VM so this does not help me unfortunately.
I can publish all the scripts and qrexec rules how i do things if this helps
. (Only wanted to do this when things are solved how i think they are as secure as humanly possible)
Sorry. I thought something like
ssh-client1 vault1 created by adminVM1
ssh-client2 vault2 created by adminVM2
and the policy that would contain:
… @tag:created-by-adminVM1 @tag:created-by-adminVM1 allow target=wahtever
…@tag:created-by-adminVM1 @anyvm deny
would work. As I said, I still don’t use such scenarios (regardless of the purpose of created adminVMs) and I thought I understood it this way.
1 Like
Indeed this would work. But then i would need an adminVM for every ssh-client/vault pair i have. As the number of servers may change, for every change i need to modify stuff in dom0 which i would like to avoid.
My other idea is to create a tag for each pair i am likely to use, like
# Pair 1
… @tag:ssh-pair-1 @tag:ssh-pair-1 allow target=wahtever
…@tag:ssh-pair-1@anyvm deny
# Pair
… @tag:ssh-pair-2 @tag:ssh-pair-2 allow target=wahtever
…@tag:ssh-pair-2@anyvm deny
And create like 100 or so of those rules. The adminVM would need to keep track of all running pairs and assign the tags so no collisions can exist.
I think this is the most secure hotfix, but in my opinion this is a bit ugly.
1 Like