Re: [qubes-devel] qubes-doc & rtd
On December 25, 2021 10:37:04 PM GMT+01:00, mm wrote: > >On 12/25/21 21:16, Manuel Amador (Rudd-O) wrote: >> >> Honestly if I were directing the project I would set up a Plone instance, >> and use its excellent i18n to write docs. Additionally, if wanted, I would >> set up two way sync between a github repo and the site. Ask me for more >> details if interested. > > >Thank you very much for taking the time to reply and also for your >suggestion. > >In my personal opinion Plone as a CMS is much too heavy for the purposes >of the user documentation of Qubes. > >I have experience with it, though a decade ago probably, and it is not >as intuitively as one might think. > >Perhaps things changed and is a straightforward easy to use idk. It's very straightforward to use now. > >If you would like and have the time, could you outline how would you >proceed with markdown - Plone integration (or if it works w/o issues), Plone supports Markdown out of the box. > >automation of translation/localization wrt to transifex and release >specific docs, This would require a bit of code that extracts the strings to translate (using the exportimport framework) from the original language folder, and deploys the translated content (using the exportimport framework) to the respective language folders (linking the translation to the original). E.g. article /en/howtos/vpn would get exported, posted to Transifex (possibly through a Git repo), and then once the German translation is available, /de/howtos/vpn could be posted, linking it to /en/howtos/vpn so the UI can show all translations for the same content item. The items could then be published by the same pipeline doing the exportimport, or left to be reviewed prior to publishing by people. > >so one could weight the pro and contra of the different approaches till now. > >All the best, > >m > > > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/9519C71F-CAE2-496B-9D4C-93929D195276%40rudd-o.com.
Re: [qubes-devel] qubes-doc & rtd
Honestly if I were directing the project I would set up a Plone instance, and use its excellent i18n to write docs. Additionally, if wanted, I would set up two way sync between a github repo and the site. Ask me for more details if interested. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/E3AD1308-7002-44A7-9F39-C78D9BD42D85%40rudd-o.com.
Re: [qubes-devel] Contributing to hardening AppVMs templates
On 16/12/2021 23.54, Hugo V.C. wrote: "is single user in each VM because it is assumed that the kernel is not trustworthy." Can you elaborate it a bit? I don't get what you mean. Are you assuming that compromising a jailed an unprivileged web browser is the same as running it as root? In the Qubes model, yes. Also has proven true in every single PwnToOwn to date. "higher security and performance can perhaps be achieved by using stuff like unikernels running stripped-down apps or services" 100% agree. "why publish a PDF? It's not linkable, hard to quote... Why not a post on a blog?" Not linkable...? I don't have a blog. Maybe I should start one. Thanks for the suggestion. You have a Web site, don't you? --- OK. I went through the PDF. The one attack you discovered is interesting, and the vuln you discovered should be fixed. That said... On page 25, you present the following suggestions (none of which address any of the flaws you discovered) under the section /Hardening of AppVMs/: 1. Making AppVMs multiuser. On what grounds? They are intended as single-purpose single-user environments; they could even be running all their processes as root (they don't, simply because of the practical reason that some GUI apps refuse). Implementing this suggestion would not fix the problems you outlined earlier. This suggestion is 100% a non-sequitur. 2. Sandbox the browser. Could be helpful — anything exposed to the Internet should probably be sandboxed or containerized, just to make an attacker's attempt to compromise the compartment harder. I wonder what level of effort pays off there. 3. Do not regard the AppVM and its tools at the same level of criticality. Again, this is a non-sequitur — if you use Qubes, it is already /postulated as true/ /and well documented/ that you assume the AppVM shares its criticality level, no matter what user or tool you are running. If you want to avoid compromise by using vulnerable tools, you are to run them in a disposable VM. 4. "EASY: just forget about doing those operations from the AppVM/VMs side, just transfer all the responsibility to Dom0" — *lol what*. In Qubes OS, dom0 is explicitly forbidden (unless the user deliberately breaks the model) from seeing or manipulating any data from AppVMs. dom0 is the minimum trusted computing base — if any malicious data infiltrates dom0, it's game over and you might as well be running MS-DOS instead. Honestly, I think you have fundamentally misunderstood the design of Qubes OS, or you are still stuck in the old mental model of the UNIX security model, and your critiques stem from this misunderstanding / fixation. If you want to critique a system of ideas that starts with /postulate/ X, and your critique's argument starts with "I /postulate/ not-X", then your argument is not at all critiquing /that/ system. I'm saying all of the above as someone experienced with Qubes OS, who has written several third-party utilities specifically for the Qubes OS environment — I even wrote a utility to share entire file systems conveniently between VMs, so I did basically what you suggested in point (4). *At no point* in the development of this utility did it even occur to me "You know what would be a swell idea? To pass these shared files through dom0." That seems to me like an extreme error of judgment. On page 26, you present the section /Hardening of the whole solution/: 1. Qubes OS places all its eggs in one basket — the Xen hypervisor. This is partially true, from the perspective that the Xen hypervisor is one of the few trusted components of the system (arguably, the entirety of dom0 is). The rest of the opinion is flat out against the facts. The Qubes OS developers have put enormous amounts of effort in integration work to make the whole ensemble work well. This effort shows — all you managed to chain in order to compromise another VM were components that the Qubes OS developers did /not/ develop, and even then, your /sole/ compromise scenario only works under /highly //specific/ and unlikely circumstances. There have been very few vulnerabilities published against this integration work. 2. Qubes OS lets the user decide what trustworthiness level to place on data / data flows. This is correct. You call this "crazy". How exactly would /you/ do this otherwise? No suggestions there. The section /File transfer solution/ suggests that file integrity must be checked. You propose no mechanism to do this. What you propose is to download files to a "secure and inalterable compartment" — and then /what/? Leave the data there? How does the user use the data then? You also propose involving dom0 in said downloaded data flow — which would basically guarantee compromise of dom0, /id est/, MS-DOS security. It's like your mental image of what the Qubes OS security
Re: [qubes-devel] Contributing to hardening AppVMs templates
On December 16, 2021 8:25:19 AM GMT+01:00, Hugus Maximus wrote: > >Hi all, > >I just published document discussing some well known security limitations >of Qubes OS: > >https://www.pentest.es/Demystifying_QubesOS_Security.pdf I will review it. That said, the security model of Qubes is single user in each VM because it is assumed that the kernel is not trustworthy. So some of your suggested measures, given the official postulates of the Qubes project, are pointless. I personally think that higher security and performance can perhaps be achieved by using stuff like unikernels running stripped-down apps or services (single-process VMs which start in milliseconds). Genode is making headway in that direction without the need for unikernels or virtualization. Question: why publish a PDF? It's not linkable, hard to quote... Why not a post on a blog? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/FD51479B-3BDD-49BB-8711-6079CBBD64CD%40rudd-o.com.
Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service
On 16/12/2021 01.07, Marek Marczykowski-Górecki wrote: Here is how qrexec policy prompt is doing it: https://github.com/QubesOS/qubes-core-qrexec/blob/master/qrexec/tools/qrexec_policy_exec.py#L64-L112 Bad news, I did not understand any of that code. :-( Just to see if I understand at least the process: 1. dom0 sends RPC `policy.Ask` to GUIVM 2. this policy program pops up a dialog 3. the response comes back If this is correct, please let me know if my following theory is correct: 1. I create a `policy.AskBlah` policy with the same config as `policy.Ask` 2. I move my program that asks via UI to the package to be installed in the GUIVM 3. I also move my RPC service code to that package 4. I make my dom0 RPC that (today) executes the GUI program, invoke the policy.AskBlah service, and await a response If so, how do I distinguish between the case of GUIVM and no GUIVM? Additionally, what about the folder share manager application? It currently runs in dom0 (kinda has to, because dom0 is where the file share policy is stored). -- Rudd-O https://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/5d7c05b3-3740-5cbc-e22b-7d0cd161cb03%40rudd-o.com. OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service
On 16/12/2021 01.07, Marek Marczykowski-Górecki wrote: If going with standard qrexec prompt (+#5853), you'd get that for free;) Otherwise, you need a qrexec service that calls into GUI domain to do the prompt (and then validate its output to really allow only the thing that was asked about, not something else). Basically, factor out the prompt code into separate file, then call it via `qvm-run --service ...` instead of directly. Here is how qrexec policy prompt is doing it: https://github.com/QubesOS/qubes-core-qrexec/blob/master/qrexec/tools/qrexec_policy_exec.py#L64-L112 This is very useful, and the best news there is, is that the program that does the asking, is already completely factored out, and its inputs/outputs are filtered too. Thank you. -- Rudd-O https://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/531a7407-724c-3af3-a5a4-2f95100ac088%40rudd-o.com. OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service
Prefacing this response with: I went with the implementation as designed by the document. In the future I will revise argument passing to use the new 4.1 style, instead of base64 over pipes. Currently the implementation uses a custom-made dialog — a very nice one, if I do say so myself — in the spirit of the feature request #5853. On 14/12/2021 15.28, Marek Marczykowski-Górecki wrote: I think it looks ok. Regarding one-time access, I'd rather specify it with a timeout, to avoid cases when the client VM requests authorization but uses it much later. This will land in the project's to-do list and will be implemented at some point in the future. Patches always welcome! One thing you may want to consider is interaction with GUI domain - in this case dom0 couldn't directly ask the user, but rather ask the GUI domain to display the prompt. We do this for normal policy prompts. Anyway, it's of course up to you whether you support GUI domain or not... Yes, I intend to support the GUI domain. *How do I do this?* Right now my code merely spawns up, from dom0, a GUI dialog using DISPLAY:=0. This was lifted from other parts of the Qubes repositories. -- Rudd-O https://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ad26346a-6a2f-46fd-3113-76371a475dc9%40rudd-o.com. OpenPGP_signature Description: OpenPGP digital signature
[qubes-devel] ANN: qubes-shared-folders 0.1.0, now with folder share manager
Hello, folks. A new version of Qubes shared folders has been released. https://github.com/Rudd-O/qubes-shared-folders The main highlight of this version is a revamped security model that allows the user to securely delegate folder access permissions to specific pairs of qubes, either as a one-time basis, or permanently. The UI aims to be clear and easy to use. The included folder share manager allows the user to revoke or revise permanent share decisions any time after the fact. Secondary highlights include a complete implementation of type checking, to prevent security issues and other common bugs that Python programs often carry. Enjoy, and don't forget to open bugs if you find any. -- Rudd-O https://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/fd5dd640-e416-0824-1aff-0691e3e5b3f9%40rudd-o.com. OpenPGP_signature Description: OpenPGP digital signature
[qubes-devel] Re: Design questions for the next steps of the Qubes shared folders service
Update: I have added diagrams to the document https://github.com/Rudd-O/qubes-shared-folders/blob/perfolder/doc/authorization-design.md What's better is that there is now a test implementation available in branch `perfolder`: https://github.com/Rudd-O/qubes-shared-folders/tree/perfolder Information, suggestions, critiques, and patches welcome! On 13/12/2021 06.58, Manuel Amador (Rudd-O) wrote: Hi folks. I wrote the Qubes shared folders service in an afternoon. It is what it is -- useful, but not ideal. I've come up with a design for an improved version that I would like you to review for correctness and to see if it could be implemented better. I think this design has potential, and I want your feedback before implementing it. The document is at https://github.com/Rudd-O/qubes-shared-folders/blob/master/doc/authorization-design.md — I am adding the contents of the document below. Please go ahead and analyze it. Thanks in advance for your feedback. - # Next-gen folder share authorization design Initially, Qubes shared folders used standard Qubes RPC authentication to decide whether to grant access to the folders of a qube (called *server* in this document) initiated by another qube (called *client* in this document). This happens through the client qube invoking the `ruddo.ShareFolder` RPC service on the server qube, which if successful causes the `diod` daemon to be started on the server VM and finally connected via file descriptors to the kernel `v9fs` file system module in the client VM. This is perfectly adequate for the use case where the user wants to grant the client qube blanket read/write access to any folder in the server qube. This is, however, inadequate if the user wants to grant different client qubes finer-grained access to specific subfolders. Consider, for example, one scenario of a "file server" qube that acts as a repository of data for three other client qubes: `work`, `projectX` and `social`. Our stipulated user may want to save some types of data to some folders in the file server qube, but may not want to mix them. In this scenario, our user wants work data to be saved to `fileserver:/home/user/Work`, social data to be saved to `fileserver:/home/user/Memes`, and his project X (work-related) involves some data that should *also* be accessible to his work qube, but he does not desire to grant the project X workspace access to *all* the work data, so he decides to store project X data under `fileserver:/home/user/Work/projectX`. We further stipulate in this scenario that shuttling files around manually using the `qvm-move` facilities would severely impede the user's enjoyment of the Qubes system he is running. This setup naturally requires a more sophisticated access control mechanism than a simple yes/no policy decision. # User interaction What we propose is the following: 1. The user instructs the client qube to mount folder `X` on the server qube. 2. dom0 asks the user "client qube wants to mount folder `X` on server qube". 3. The user responds accordingly. If authorized, the connection is permitted and the client qube can successfully mount `X`. The Qubes policy argument mechanism is insufficient for the proposed interaction. For one, it limits the argument size to 64 bytes, making it unsuitable for a wide possibility of paths the user might want to connect to. Second, it doesn't actually convey the information that the client qube sent — it conveys a form of hobbled information that crucially does not include spaces, slashes, or other special characters, all of which are legitimate in POSIX paths. Third, the way that the question is presented is not exactly usable. # Implementation details The circumstances lead us to consider the implementation of an alternative security mechanism, proposed here. Instead of directly contacting the server qube, the client qube will contact dom0 instead, through a special service `ruddo.AuthorizeFolderAccess` (with a default `allow` policy targeted at dom0), requesting access to a specific path of the server qube (id est, two arguments, the requested path and the target qube). The data mentioned will of course be sanitized accordingly, and rejected if they do not conform to a canonical form. dom0 can then pop up a dialog explicitly designed for the purpose of allowing this policy decision. This dialog will display the crucial information the user needs to know in order to make an informed decision: 1. The origin qube of the request. 2. The target qube of the request. 3. The folder it wants to request. 4. Whether the access should be one-time allow or always allow. If the user accepts this, then the decision data will be stored in dom0, on a dictionary keyed by the first 64 characters of the SHA256 hash of (origin, target, folder) — we will call this hash the decision fingerprint. Then do
[qubes-devel] Design questions for the next steps of the Qubes shared folders service
Hi folks. I wrote the Qubes shared folders service in an afternoon. It is what it is -- useful, but not ideal. I've come up with a design for an improved version that I would like you to review for correctness and to see if it could be implemented better. I think this design has potential, and I want your feedback before implementing it. The document is at https://github.com/Rudd-O/qubes-shared-folders/blob/master/doc/authorization-design.md — I am adding the contents of the document below. Please go ahead and analyze it. Thanks in advance for your feedback. - # Next-gen folder share authorization design Initially, Qubes shared folders used standard Qubes RPC authentication to decide whether to grant access to the folders of a qube (called *server* in this document) initiated by another qube (called *client* in this document). This happens through the client qube invoking the `ruddo.ShareFolder` RPC service on the server qube, which if successful causes the `diod` daemon to be started on the server VM and finally connected via file descriptors to the kernel `v9fs` file system module in the client VM. This is perfectly adequate for the use case where the user wants to grant the client qube blanket read/write access to any folder in the server qube. This is, however, inadequate if the user wants to grant different client qubes finer-grained access to specific subfolders. Consider, for example, one scenario of a "file server" qube that acts as a repository of data for three other client qubes: `work`, `projectX` and `social`. Our stipulated user may want to save some types of data to some folders in the file server qube, but may not want to mix them. In this scenario, our user wants work data to be saved to `fileserver:/home/user/Work`, social data to be saved to `fileserver:/home/user/Memes`, and his project X (work-related) involves some data that should *also* be accessible to his work qube, but he does not desire to grant the project X workspace access to *all* the work data, so he decides to store project X data under `fileserver:/home/user/Work/projectX`. We further stipulate in this scenario that shuttling files around manually using the `qvm-move` facilities would severely impede the user's enjoyment of the Qubes system he is running. This setup naturally requires a more sophisticated access control mechanism than a simple yes/no policy decision. # User interaction What we propose is the following: 1. The user instructs the client qube to mount folder `X` on the server qube. 2. dom0 asks the user "client qube wants to mount folder `X` on server qube". 3. The user responds accordingly. If authorized, the connection is permitted and the client qube can successfully mount `X`. The Qubes policy argument mechanism is insufficient for the proposed interaction. For one, it limits the argument size to 64 bytes, making it unsuitable for a wide possibility of paths the user might want to connect to. Second, it doesn't actually convey the information that the client qube sent — it conveys a form of hobbled information that crucially does not include spaces, slashes, or other special characters, all of which are legitimate in POSIX paths. Third, the way that the question is presented is not exactly usable. # Implementation details The circumstances lead us to consider the implementation of an alternative security mechanism, proposed here. Instead of directly contacting the server qube, the client qube will contact dom0 instead, through a special service `ruddo.AuthorizeFolderAccess` (with a default `allow` policy targeted at dom0), requesting access to a specific path of the server qube (id est, two arguments, the requested path and the target qube). The data mentioned will of course be sanitized accordingly, and rejected if they do not conform to a canonical form. dom0 can then pop up a dialog explicitly designed for the purpose of allowing this policy decision. This dialog will display the crucial information the user needs to know in order to make an informed decision: 1. The origin qube of the request. 2. The target qube of the request. 3. The folder it wants to request. 4. Whether the access should be one-time allow or always allow. If the user accepts this, then the decision data will be stored in dom0, on a dictionary keyed by the first 64 characters of the SHA256 hash of (origin, target, folder) — we will call this hash the decision fingerprint. Then dom0 will create (much like `policy.RegisterArgument` does today) a policy `allow` element (based on the decision the user made) that permits the client qube to access the server qube's `ruddo.ConnectToFolder` service (in charge of establishing the `diod` server-side of the file share service) but *only when the correct argument is supplied*. The decision fingerprint will then be returned to the client VM. At this
[qubes-devel] ANN: ansible-qubes (bombshell-client and qubes-network-server now compatible with Qubes 4.1
Hello, kind folks! I am done making changes and testing the new releases of ansible-qubes (which includes bombshell-client to run shell commands across VMs) and Qubes network server. The master branches of both projects are now compatible with Qubes 4.1 and work correctly as expected. * https://github.com/Rudd-O/ansible-qubes Lets you automate actions between VMs using the qubes.VMShell service. * https://github.com/Rudd-O/qubes-network-server Lets you expose AppVMs and StandaloneVMs to other equipment on your LAN. You should be able to build packages for both projects and deploy these packages to your Qubes 4.1 setup. In the future I'll explore building and publishing packages so that people can deploy directly from a repository. If there is interest, we could continue shepherding these projects directly into the Qubes OS organizational umbrella. Enjoy! -- Rudd-O https://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/657d5501-877d-1eb0-3b7b-0343cc4df757%40rudd-o.com. OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-devel] Contributing a SaltStack module for qvm-appmenus
Good point. Syntax may actually be a dict instead of a list of enabled ones, with the values of the dict being booleans for configuring yes/no to the menu entry. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/3fc85a72-c9ac-472b-ab96-9e028ff496ca%40rudd-o.com.
Re: [qubes-devel] Google Summer of Code - Gnome dom0 project
Is there anything else you guys would recommend me to look at? Any resources? IIRC Mutter is programmable via JavaScript. It should be doable to select a window border color by looking at the correct window manager hint and then telling Mutter to paint the border of a window a color that matches the WM hint. -- Rudd-O https://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/9af03c18-421d-da69-789c-8635b2450934%40rudd-o.com. OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-devel] Qubes network server: 4.0 and beyond
Good news. Branch * https://github.com/Rudd-O/qubes-network-server/tree/r4.0 is now updated to include the admin code as a dom0 add-on package, using the Qubes extension mechanisms. Please, please, help me with a review of the code! I will now close the pull requests I opened against the qubes-core-admin repository. Work on >= 4.1 is ongoing. For the time being, this is great progress, as I can finally configure my VMs correctly, and begin restoring network services that were previously protected by Qubes OS. Thanks. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/4449b34b-244e-934a-5ce2-63f0176c0eb6%40rudd-o.com.
Re: [qubes-devel] Qubes network server: 4.0 and beyond
On 14/04/2020 01.29, Marek Marczykowski-Górecki wrote: > > I see all you do is to react to some events and update qubesdb then. We > have specific API that allows you to do that from a 3rd-party extensions. > You can find documentation here (see also other about 'qubes' module, > but you got that part right already): > https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-ext.html > and here is also real-world example: > https://github.com/QubesOS/qubes-core-admin-addon-whonix/ > The files you need are: > - qubeswhonix/__init__.py - here is an actual extension (rename the > directory obviously) > - setup.py > plus a standard packaging stuff: > - Makefile > - rpm spec > - Makefile.builder Thank you. I will get right on this. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/e7619b7f-1df7-96c0-cb65-049603d90226%40rudd-o.com.
[qubes-devel] Qubes network server: 4.0 and beyond
Folks, Given my own need to update my own machines, I've updated the Qubes network server code to work with 4.0 (and, soon, beyond 4.0). Unlike the previous iteration (which used /qrexec/ to set things up in NetVMs and AppVMs), this code re-scopes the feature to be limited to network-exposing machines directly attached to NetVMs, uses a proper agent that goes in the NetVM, and does not set up firewall rules in the AppVMs. Unfortunately, this iteration of the code requires integration of a pull request in the Qubes OS admin component, responsible for informing the NetVM of which machines require exposure to the network: * 4.0: https://github.com/QubesOS/qubes-core-admin/pull/336 * 4.1: https://github.com/QubesOS/qubes-core-admin/pull/337 The code that actually implements the correct behavior in NetVMs is here: * https://github.com/Rudd-O/qubes-network-server/tree/r4.0 Additionally, I have no clue why the tests broke. I could seriously use help getting this code in. I'm happy to work with anyone on this issue. Thanks in advance! -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/e6735bab-ed8e-c29c-2b5d-1a1d57eef850%40rudd-o.com.
Re: [qubes-devel] Re: Question about storage pool "file"
On 26/06/2019 09.50, Rusty Bird wrote: > > So this would not cause data loss. > > But there are bound to be some serious data loss bugs in 'file' - the > worst that I know of is that cloning or backing up a running VM will > likely result in corrupted data (in the destination), because those > operations read the live volume data while it is being modified: > > https://github.com/QubesOS/qubes-issues/issues/4324 Thanks for the comprehensive answer! My current backup solution takes a ZFS snapshot, mounts it read-only, then copies the data. VMs running during backups will have inconsistent file system volumes upon restore, but otherwise no biggie. Qubes ought to move to a model where the underlying system uses btrfs snapshots to do backups. That way we could rid ourselves of the existing complexity (at least for the private.img volumes). > > > my ZFS pool code > > Nice. Godspeed! > > I had been hoping that OpenZFS would finally get FICLONE support after > Or*cle ZFS got the Solaris equivalent a while ago - which would make > 'file-reflink' compatible with ZFS. But nothing really seems to be > happening on that front: > > https://github.com/zfsonlinux/zfs/issues/405 > > Rusty I hope that happens soon too. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/e1df9ac7-0bba-39db-a707-72581b4d3e13%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Question about storage pool "file"
Folks, I haven't been able to understand the codebase for the "file" storage pool very well. At which point in the lifetime of a VM do changes get merged down from the COW private.img to the base private img? If my machine crashes, what prevents the data in the COW private.img from being lost next time the VM starts? Thanks. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/61153cbf-6ab2-1ddf-62a7-af499132f2e2%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] qvm-create behavior / VM prefs (4.0)
On 2018-04-23 10:41, Ivan Mitev wrote: > Hi, > > In 4.0, when creating an AppVM based on a TemplateVM, is it expected > that none of the new VM's prefs are copied from the template VM ? > > For instance: (test2 is a TemplateVM) > > qvm-prefs test2 kernel -> '' > qvm-prefs test2 virt_mode -> 'hvm' > qvm-prefs test2 memory -> '2096' > > qvm-create --template test2 --label red testapp2 > > qvm-prefs testapp2 kernel -> '4.4.18-1' > qvm-prefs testapp2 virt_mode -> 'pvh' > qvm-prefs testapp2 memory -> '400' > ... > > I'll file an issue if it's a bug; if it isn't, this behavior is a bit > problematic: for instance a newly created AppVM from a windows TemplateVM > - will never boot because of the 'kernel' pref > - will not work in pvh mode > - will fail because of too low mem / mem balancing > ... > > > Cheers, > ivan > To my knowledge, app VMs do not copy their properties from template VMs upon creation. They are independent. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/6fde36ed-2248-f776-a30f-04ef893a51ed%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Changing qubes-core-admin license to LGPL v2.1+
I have no problem with this. Go ahead. On July 17, 2017 2:21:37 PM GMT+02:00, "Marek Marczykowski-Górecki" <marma...@invisiblethingslab.com> wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > >Dear Qubes Contributors, > >In the process of developing commercial extensions[1], we may need to >interface them directly with Qubes core scripts. While our goal is to >keep Qubes OS itself as open source, this may not apply to some >commercial extensions. The majority of commercial components can be >implemented as standalone applications (qrexec services, etc.) and >specific configurations (including salt state files). But some of them >may need to interface with core Qubes code directly (proverbial "import >qubes" in Python). Doing this with the qubes-core-admin component, >which is licensed under GPL, would force such an extension to be >licensed under GPL also. In many cases, we may decide to do this >anyway, >but we'd prefer not to force this (on ourselves or anyone else). > >We have three goals here: > - Keep core Qubes OS code open source > - Allow proprietary extensions > - Find ways for Qubes OS to survive and grow > >In order to achieve those goals, we'd like to change the >qubes-core-admin component license in Qubes 4.0 to "LGPLv2.1 (or >later)". >License text is here: > >https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html > >To do so, we must ask everyone who contributed code used in >qubes-core-admin in >Qubes 4.0 to accept this change. Here is the list of contributors: > >- - Andrew David Wong (Axon) >- - Bahtiar `kalkin-` Gadimov >- - Desobediente Civil >- - HW42 >- - Ivan Konov >- - Jasper Tron >- - Jeepler >- - Jon Griffiths >- - Mario Geckler >- - Michal Rostecki >- - Nicklaus McClendon >- - Olivier Médoc >- - o >- - Patrick Schleizer >- - Joonas Lehtonen >- - qubesuser >- - Manuel Amador (Rudd-O) >- - Rusty Bird >- - ttasket >- - Unman >- - Victor Lopez >- - Vít Šesták >- - Zrubi > >If you are on this list, and you agree to the license change, please >reply to this email with a simple "I agree." >If you signed your patch(es), we would strongly prefer that you use the >same key to sign your reply. > >*Important!* > >Ideally, we would like to get consent from everyone on this list >before proceeding with this change. However, it is possible that >one or more people on this list will not reply (e.g. because we do >not have a working email address for them, or they no longer check >the address we have). Therefore, we are adopting the following >policy: *If you do not reply with one month, we will assume that >you consent to this change.* (If you need more time to decide, >simply reply within one month to tell us that you need more time.) > >[1] https://www.qubes-os.org/news/2016/11/30/qubes-commercialization/ > > >- -- >Best Regards, >Marek Marczykowski-Górecki >Invisible Things Lab >A: Because it messes up the order in which people normally read text. >Q: Why is top-posting such a bad thing? >-BEGIN PGP SIGNATURE- >Version: GnuPG v2 > >iQEcBAEBCAAGBQJZbKvSAAoJENuP0xzK19cs+uAH/06+oZBlEGo+aqyw6VLCLUUP >+dyKtFNLLo76B8KPYM8UC/Q+pSMby+apX2Mm8kxSDF5K4idIWD3wF3Y45tc8I/aW >8/2QdGHEvw8ejsgtirRIw4o52MtNj6RHvH+Cak2PlYArUHPGsGX9un5PbO7n37uO >MRLuZLo0+Y0TD+0JkdMCSJY18450Uh+4xF/7KLEBcXlyWRaqVnfKfBiDoH5aONOx >Fanwp7gAH0Q1L6UnhG88cRGzwfgOvTiXk4IsMFAcXQSNqbFGZmFte1tTAocjj5VJ >SK1E/SQNFbQR2J6MrIBikTRcHkd7Guwo5iXwub5DbmdxsPZN/47NL8uPLmgbmJk= >=Sh4A >-END PGP SIGNATURE- -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/15C171E3-BAD0-4709-A8D9-171ED6EC140E%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Qubes 4.0 development status update
On 12/05/2016 02:50 AM, Marek Marczykowski-Górecki wrote: > > There are also still a couple of rough edges during installation/first > run. For > example "LVM thin" storage should be used, but currently it needs to be > selected manually (using custom partitioning option). And depending on > the disk > layout, it may require creating those partitions manually. > Honestly, it would be so much better if Qubes OS did NOT use LVM, and used btrfs or ZFS instead. LVM has no protection whatsoever against data corruption. I hope the APIs are modular such that there is an implementable interface for storage backends which does not assume LVM is the only thing that underlies the system. As a person using Qubes OS on top of ZFS, I would find myself in quite some trouble if that was not the case. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/47b930e6-c409-cf2e-4a1d-e7be6496c42c%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] 4.8.7 kernel in unstable repository
On 11/11/2016 11:57 PM, Trammell Hudson wrote: > On Sat, Nov 12, 2016 at 12:47:22AM +0100, Marek Marczykowski-Górecki wrote: >> [...] But in anyone need something newer than 4.4.x >> for some hardware support - here it is. > That's great -- I've been struggling to get the power consumption > on Skylake down to reasonable levels with the 4.4 kernel in r3.2. > I'll try upgrading next week at the office. Please tell us the results of your experiment please please. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/528681b6-f109-b2bd-ddd8-175c69c2d1e6%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Running (or not) Xen during installation
On 11/04/2016 12:07 PM, Ivan wrote: > > > Seconded - there should really be a way to test hardware compatibility > before installing. A menu entry right under "Test and install the image" during the installer GRUB boot? That would be very nice, actually. Donno what the menu entry should do, but it should probably try to boot into Xen, then into Linux, then run a /sbin/init that is a Hello World program, which accepts any key to reboot. (We'll sell those Any Key USB peripherals to make ourselves REAL RICH!) -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/199b68d7-860a-ee35-23b1-eaa1368b4018%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Running (or not) Xen during installation
On 11/03/2016 08:13 PM, Marek Marczykowski-Górecki wrote: > Hi, > [...] > So, now the question - do we want to keep launching Xen for > installation, or launch just plain Linux? You're asking us about something whose answer you already know. And we agree with you. If there is no security benefit from launching the installer under Xen, then kill Xen in the installer. Just make a note during the install that the first boot may fail, and provide a prominent link to a page where users can go AFTER the install is done, to diagnose why their system does not boot. That last part is really important! -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/1149892f-afe4-dbcb-2e1b-570497e50574%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Extra partitions in /etc/crypttab in initramfs
On 10/28/2016 11:28 AM, Trammell Hudson wrote: > I'm not sure if this issue affects anyone else, but the /etc/crypttab in > initramfs does not have entries for extra partitions that were created > during installation. It only has / and swap. > > Since I'm configuring / to be read only, I have a separate /home for > the modifiable state. The disks are unlocked via a TPM sealed keyfile, > so the initramfs needs to be modified to add the additional entry for > the extra partitons. > After editing /etc/crypttab you must rebuild the initramfs: dracut -fv --regenerate-all HOWEVER, /home does absolutely not need to be present in /etc/crypttab or in kernel cmdline. It can be unlicked after boot. I would recommend using a keyfile to prevent having to type the password for /home. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/144faef2-bb3d-7399-76fa-f585ec8e5a94%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] ANN: git-remote-qubes: Inter-VM Git for Qubes OS
On 10/28/2016 01:48 PM, HW42 wrote: > Marek Marczykowski-Górecki: > [...] > > I see. The server part is much more critical, so it's ok to have as it > > is now. Actually my solution also pass the data manually on the > client side > > - but it uses "cat" for this: > > > (echo $GIT_EXT_SERVICE $2 $3; exec cat) | qrexec-client-vm > $VMNAME local.Git > > This unfortunately does not work if the remote simply exits. The problem > ist that cat does not detect that it's output fd is closed and therefore > still waits for input on stdin (You can observe this for example if you > try to fetch from an non existing repo). > > That's the same reason why > > cat | /bin/true > > blocks. While you can work around it I'm not aware of a _simple_ trick > to do it. > > What do you think of providing some way to pass a first line in > qrexec-client-vm or some wrapper. Then not everybody who implements such > simple qrexec services needs to implement their own "copier" and think > of all the corner cases. BTW the code is written as-is aand can be used as a library, no need to write anything new anyone else anymore. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ce29bfb7-e630-2159-e48e-51a55720a34d%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] ANN: git-remote-qubes: Inter-VM Git for Qubes OS
On 10/28/2016 01:48 PM, HW42 wrote: > Marek Marczykowski-Górecki: > [...] > > I see. The server part is much more critical, so it's ok to have as it > > is now. Actually my solution also pass the data manually on the > client side > > - but it uses "cat" for this: > > > (echo $GIT_EXT_SERVICE $2 $3; exec cat) | qrexec-client-vm > $VMNAME local.Git > > This unfortunately does not work if the remote simply exits. The problem > ist that cat does not detect that it's output fd is closed and therefore > still waits for input on stdin (You can observe this for example if you > try to fetch from an non existing repo). > > That's the same reason why > > cat | /bin/true > > blocks. While you can work around it I'm not aware of a _simple_ trick > to do it. > > What do you think of providing some way to pass a first line in > qrexec-client-vm or some wrapper. Then not everybody who implements such > simple qrexec services needs to implement their own "copier" and think > of all the corner cases. FWIW: This is exactly the issue that motivated me to create a solution based on data copying — not being able to detect whether the remote process had exited. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/4878102d-7e3a-c67d-5580-fc8182bf4e14%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: ANN: git-remote-qubes: Inter-VM Git for Qubes OS
On 10/28/2016 10:51 AM, cyrinux wrote: > Le jeudi 27 octobre 2016 13:47:14 UTC+2, Manuel Amador (Rudd-O) a écrit : >> It gives me great pleasure to announce the inter-VM Git bridge for Qubes >> OS, which allows you to git push and git pull from VMs stored in other >> repos, with no networking involved whatsoever, and observing full >> compliance with Qubes OS qrexec policy. >> >> This should usher in a new era of software development that allows >> people to segregate their secure Git repos from insecure build VMs and >> other engineering constructs I can't even think of (after doing >> low-level socket programming for a week, which has left my brain utterly >> fried). >> >> Find the software at https://github.com/Rudd-O/git-remote-qubes >> >> --- >> >> # Inter-VM Git for Qubes OS >> >> This is a very simple Git protocol bridge between Qubes OS VMs. With it, >> you can `git pull` and `git push` between VMs without having to grant >> any of the VMs any special policy privileges other than access to Git. >> >> ## Using the software >> >> These instructions assume you have installed the software. See the >> *Installing the software* heading below for more information. >> >> ### Creating a repository >> >> We'll assume for illustration purposes that you want to access a repository >> stored in `/home/user/xyz` on your VM `servervm`. >> >> Run the following commands on `servervm`: >> >> ``` >> cd /home/user >> mkdir -p xyz >> cd xyz >> git --bare init >> ``` >> >> That's it. Your new and empty repository is ready to use. >> >> ### Adding a remote to a local repository >> >> For illustration purposes, you'll be pushing and pulling `servervm`'s `xyz` >> repo on your vm `clientvm`. Run the following commands on `clientvm`: >> >> ``` >> cd /home/user >> git clone qubes://clientvm/home/user/xyz >> ``` >> >> You will get a permission dialog from dom0 asking for `ruddo.Git` access. >> Accept it. Note that accepting the permission dialog implicitly gives >> Git access to all Git repos stored in `servervm`, but only for that one >> execution (unless you say *Yes to all*, in which case the permission >> is remembered within the policy file that you installed earlier with the >> `dom0` package). >> >> This should have cloned `xyz` from `servervm` into your `/home/user/xyz` >> directory in `clientvm`. >> >> From this point on, you can push and pull in `clientvm` from >> `servervm:/home/user/xyz` to your heart's content. >> >> If, instead of cloning, you have an existing repo, you can add a new remote >> just as easily: >> >> ``` >> cd /home/user/existingxyz >> git remote add qubesremotevm qubes://servervm/home/user/xyz >> ``` >> >> That addition will enable to push and pull from the remote `qubesremotevm` >> which represents the repo `/home/user/xyz` in the remote VM `servervm`. >> >> ## Installing the software >> >> There are two components for this software: >> >> * Component 1 is the VM side of things, which implements the Git protocol >> across VMs. >> * Component 2 is the dom0 side of things, which is a simple text file >> declaring >> the initial Git access policy for your VMs. >> >> First, build the software, After cloning this repository on a suitable VM, >> run the command: >> >> ``` >> make rpm >> ``` >> >> This will generate two installable packages on the local directory: >> >> * `git-remote-qubes-.noarch.rpm`, which contains the Git >> protocol implementation. >> * `git-remote-qubes-dom0-.noarch.rpm`, which contains the >> default policy. >> >> Copy the `git-remote-qubes-.noarch.rpm` file to the template VM >> or standalone VM where you plan to pull or push to / from a Git repo >> stored in another Qubes VM. Install the RPM with >> `dnf install `. At this point, this VM, as well as >> any VMs using this as a template, have gained the ability to push and pull >> from Git repos stored in other VMs, as well as the ability to listen on >> push / pull requests from different VMs in the same system. >> >> Now copy the `git-remote-qubes-dom0-.noarch.rpm` file to >> your dom0. At this point, the default policy (`deny`) is active on >> your Qubes OS system, and you can begin pushing and pulling. >> >> Those clever among you will have discovered that there is a `Makefile` >> included, and
Re: [qubes-devel] ANN: git-remote-qubes: Inter-VM Git for Qubes OS
On 10/28/2016 09:17 AM, Marek Marczykowski-Górecki wrote: > On Fri, Oct 28, 2016 at 04:56:36AM +0000, Manuel Amador (Rudd-O) wrote: > > On 10/27/2016 01:13 PM, Marek Marczykowski-Górecki wrote: > >> On Thu, Oct 27, 2016 at 11:47:04AM +0000, Manuel Amador (Rudd-O) wrote: > >>> It gives me great pleasure to announce the inter-VM Git bridge for > Qubes > >>> OS, which allows you to git push and git pull from VMs stored in other > >>> repos, with no networking involved whatsoever, and observing full > >>> compliance with Qubes OS qrexec policy. > >> > >>> This should usher in a new era of software development that allows > >>> people to segregate their secure Git repos from insecure build VMs and > >>> other engineering constructs I can't even think of (after doing > >>> low-level socket programming for a week, which has left my brain > utterly > >>> fried). > >> > >> Hmm, have you seen this? > >> > https://www.qubes-os.org/doc/development-workflow/#git-connection-between-vms > >> > > > I had. That inspired me to package up the solution in a nice-to-use and > > easy-to-install way, that is more general and is not limited to Qubes OS > > development. As you know, instructions are cool, but ready-to-go > > software is cooler. I quite like that my solution actually has a > > distinct protocol qubes:/// too. > > I think it should be possible without manually copying the data back and > forth, too. In other words: connect git directly to stdin/out and wait > it for finish, then handle next command (if any). The amount of code > scares me - over 10x more over something that works just fine... I appreciate your security instincts. I tried that first, but, you see, there was a huge problem. I explain: When the slave spawns / execs git-blah-borg-flurb, and that thing happens to die (say, because the remote repo directory does not exist), then the master (git-remote-qubes invoked by git itself) hangs. Why? Well, I don't *** know, but I spent literally four days battling with that, until I decided that the sensible thing to do would be to just copy the data back and forth. Now, something must have changed lately, because now if I make the slave execvp() the git receive pack program, it works fine. So I suppose the problem was all along in the master. Thus, I have changed the slave to execvp(). This reduces the amount of code being executed to a minimum. Master (src/gitremotequbes/client.py) still needs to copy to and from the VM, because the connection to the slave is spawned *before* beginning to process what Git wants us to do. It would be the only way in which I could (for later iterations of the program) detect whether Git wants to push or to pull. > > One possible problem is that it gives access to all the repositories > (there is an info about that in doc). It may not always be desired > effect. The instruction above have a place to limit the access, I see > two easy ways how to do it in your solution: > > 1. Add some configuration in target VM - like > .config/qubes-git/allow-from-MY_SOURCE_VM_NAME and put allowed paths > there. > > 2. Use qrexec service argument[1]. This way it can be specified in > policy (and > single "yes" on ask would allow only specific repository access). Using > the same way you could also add access level: pull/push only. > > The second one is surely more flexible and more user friendly (no new > config, the same confirmation, etc). But probably require few more > changes. Also note that service argument cannot contain "/", so you'll > need to encode the path somehow. And also service name + argument is > limited to 64 characters, but this shouldn't be a big problem in > practice. > > [1] https://www.qubes-os.org/doc/qrexec3/#service-argument-in-policy > Honestly, UNIX permissions should suffice for that purpose. A VM that wants access to pull but not push can contact the Git server using a user that is not the "user" user, and then the files will appear read-only to that VM. Or even completely barred, if the repo in question is mode 0700 owned by user:user. BUT, I can add the argument thing. That is not hard to do. Edit: BIG FAT PROBLEM: if I say "yes to all" when there is an argument (it's already in the code I just pushed to Github) then nothing actually gets saved as "yes to all" anywhere. In other words: there's a bug as "Yes to all" does nothing when an argument is specified. Please fix!!! -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/6d2c214d-dbdc-187a-1294-40b445869801%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] ANN: git-remote-qubes: Inter-VM Git for Qubes OS
On 10/27/2016 01:13 PM, Marek Marczykowski-Górecki wrote: > On Thu, Oct 27, 2016 at 11:47:04AM +0000, Manuel Amador (Rudd-O) wrote: > > It gives me great pleasure to announce the inter-VM Git bridge for Qubes > > OS, which allows you to git push and git pull from VMs stored in other > > repos, with no networking involved whatsoever, and observing full > > compliance with Qubes OS qrexec policy. > > > This should usher in a new era of software development that allows > > people to segregate their secure Git repos from insecure build VMs and > > other engineering constructs I can't even think of (after doing > > low-level socket programming for a week, which has left my brain utterly > > fried). > > Hmm, have you seen this? > https://www.qubes-os.org/doc/development-workflow/#git-connection-between-vms > I had. That inspired me to package up the solution in a nice-to-use and easy-to-install way, that is more general and is not limited to Qubes OS development. As you know, instructions are cool, but ready-to-go software is cooler. I quite like that my solution actually has a distinct protocol qubes:/// too. I'm sure you've noticed that I tend to improve things in this manner :-) I need some help here: what aspects of the documented solution should I incorporate to my program? -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/26feecb3-39ff-c2c0-dab5-05fe9efa22c8%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Automated tests results
On 10/27/2016 11:32 AM, Marek Marczykowski-Górecki wrote: > On Thu, Oct 27, 2016 at 01:31:21PM +0200, Marek Marczykowski-Górecki > wrote: > > Hi, > > > If anyone is curious, I've uploaded example test results: > > https://ftp.qubes-os.org/~marmarek/tests-r3.2-20161025.html > > and original text version: > > https://ftp.qubes-os.org/~marmarek/tests-r3.2-20161025.log > > > This one is from R3.2, with all updates (including current-testing) > > installed. And many combination of templates. Those with "upgraded" in > > name are upgraded from previous version (like fedora-21 -> > > fedora-23-upgraded). Those without such suffix are clean install. > > > As you can see, full test run takes about 30 hours... > > > Not every thing is perfect - some failures are real bug, some are "just" > > problems with the test itself. But vast majority passes :) > > @Rudd-O: this one is previous run, the one with your patches is still > running... > Understood. You are an angel for having built these tests and run them. More people should appreciate your work. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/1b70466b-ddaf-bdfc-1163-9edd91cd3fbf%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Race condition in bootup
I filed a ticket about it a long time ago and then made a fix today: https://github.com/QubesOS/qubes-core-agent-linux/pull/20 -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/dd541667-f777-7df5-f0c9-20698664f74f%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] ANN: Qubes network server
Folks, it gives me great pleasure to announce the product of over two years of work (primarily because I never paid enough attention to this project to bring it to completion): Qubes network server. The traditional Qubes OS networking model contemplates a client-only use case. User VMs (AppVMs or StandaloneVMs) are attached to ProxyVMs, which give the user control over outbound connections taking place from user VMs. ProxyVMs in turn attach to NetVMs, which provide outbound connectivity for ProxyVMs and other user VMs alike. Qubes network server changes all that. With the Qubes network server software, it becomes possible to make network servers in user VMs available to other machines, be them peer VMs in the same Qubes OS system or machines connected to a physical link shared by a NetVM. You get actual, full, GUI control over network traffic, both exiting the VM and entering the VM, with exactly the same Qubes OS user experience you are used to. This is all, of course, opt-in, so the standard Qubes OS network security model remains in effect until you decide to share network servers. Anyway, without further ado: https://github.com/Rudd-O/qubes-network-server Real easy: clone, build, install, test. I tested it with Qubes 3.1, but it's very likely that it'll work fine in Qubes 3.2. I recommend you test this on a Qubes machine that is not your main Qubes machine, but the code does not do anything funky, and uninstalling the program should be enough to revert your system back to its original state. I hope we can turn this add-on into a core Qubes feature. As always, contributions to the project — reports, code enhancements, pull requests, other items — are very much welcome! -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/6de9db66-fbd1-a8a9-ef53-c2f6173e6356%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Window border colors
Hello. I just did an update, rebooted, and now my window borders do not have the VM's colors. The prefix on the window title is correct tho. What gives? -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/b4518451-6a35-5e08-3681-f9e6e97a1f9d%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
