[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On Saturday, January 28, 2017 at 11:43:51 AM UTC-5, raah...@gmail.com wrote: > On Wednesday, January 25, 2017 at 5:19:00 PM UTC-5, Kopimi Security wrote: > > On Wednesday, January 25, 2017 at 6:22:14 PM UTC+1, raah...@gmail.com wrote: > > > On Tuesday, January 24, 2017 at 9:15:10 AM UTC-5, Kopimi Security wrote: > > > > On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote: > > > > > Yeah, I tried it myself leaving my laptop turned on and on learning > > > > > mode > > > > > for three weeks straight, but it didn't catch everything and certain > > > > > things still failed so there's definitely some manual massaging that > > > > > needs to be done. > > > > > > > > Thank you for your input! > > > > > > > > Would you think a sniffing approach, or a tripwire approach, to be > > > > better*? > > > > > > > > * On a RAM-limited system > > > > > > what do you mean by sniffing approach? > > > > Sorry for being unclear, I'm not a native speaker. > > > > By "sniffing", I meant to refer to active monitoring of known attack types, > > a pro-active approach as opposed to a more after-the-fact intrusion > > detection system. > > Kind of like watchdogs for memory, and snort for ports. > > > > Google recently wrote up some advice for hardening KVMs: > > https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html > > > > Their number one advice is using a pro-active approach. > > I think by proactive approach they mean pen testing. https://www.amazon.com/Basics-Hacking-Penetration-Testing-Second/dp/0124116442 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e735a6eb-4625-4e73-af53-1c836f760ee0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On Wednesday, January 25, 2017 at 5:19:00 PM UTC-5, Kopimi Security wrote: > On Wednesday, January 25, 2017 at 6:22:14 PM UTC+1, raah...@gmail.com wrote: > > On Tuesday, January 24, 2017 at 9:15:10 AM UTC-5, Kopimi Security wrote: > > > On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote: > > > > Yeah, I tried it myself leaving my laptop turned on and on learning mode > > > > for three weeks straight, but it didn't catch everything and certain > > > > things still failed so there's definitely some manual massaging that > > > > needs to be done. > > > > > > Thank you for your input! > > > > > > Would you think a sniffing approach, or a tripwire approach, to be > > > better*? > > > > > > * On a RAM-limited system > > > > what do you mean by sniffing approach? > > Sorry for being unclear, I'm not a native speaker. > > By "sniffing", I meant to refer to active monitoring of known attack types, > a pro-active approach as opposed to a more after-the-fact intrusion detection > system. > Kind of like watchdogs for memory, and snort for ports. > > Google recently wrote up some advice for hardening KVMs: > https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html > > Their number one advice is using a pro-active approach. I think by proactive approach they mean pen testing. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f81ee0e2-0751-432b-9f64-68c79b1c0388%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On Wednesday, January 25, 2017 at 6:22:14 PM UTC+1, raah...@gmail.com wrote: > On Tuesday, January 24, 2017 at 9:15:10 AM UTC-5, Kopimi Security wrote: > > On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote: > > > Yeah, I tried it myself leaving my laptop turned on and on learning mode > > > for three weeks straight, but it didn't catch everything and certain > > > things still failed so there's definitely some manual massaging that > > > needs to be done. > > > > Thank you for your input! > > > > Would you think a sniffing approach, or a tripwire approach, to be better*? > > > > * On a RAM-limited system > > what do you mean by sniffing approach? Sorry for being unclear, I'm not a native speaker. By "sniffing", I meant to refer to active monitoring of known attack types, a pro-active approach as opposed to a more after-the-fact intrusion detection system. Kind of like watchdogs for memory, and snort for ports. Google recently wrote up some advice for hardening KVMs: https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html Their number one advice is using a pro-active approach. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/02fa0201-0f4f-43c4-a786-164a6147d35d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On Wednesday, January 25, 2017 at 12:39:07 PM UTC-5, Reg Tiangha wrote: > On 2017-01-25 10:24 AM, raahe...@gmail.com > wrote: > > > > > It should tell you what rbac is blocking in dmesg or journal no? it will > > say gradm I believe. You should also be seeing grsec and pax messages in > > there as well. > > > > It probably did, although sometimes it'll say what was killed, but not > specifically why. For example, if a process is denied access to a > directory (ex. /var/run or something), it may not be specific enough. > > But in my case, during training, there's a lot of crap that goes into > dmesg, and I didn't discover the actual issues until I restarted the > machines with the new rulesets and I never saved the syslogs before > rebooting. In the case of the UpdateVM where no AppVMs were able to > connect to it and thus wouldn't start, absolutely nothing appeared in > the UpdateVMs logs, dmesg or otherwise. I assume it's some kind of Qubes > process on the UpdateVM that failed to start (or it did but kills > whatever is responsible for allowing an AppVM to connect), but I have no > idea which one; like I said, the developer documentation is a bit > lacking in terms of specifying what exact processes are responsible for > certain tasks, and I think the architecture document is like 10 years > old now and doesn't even reflect how the system works currently. > > Anyways, I'm sure with some more troubleshooting I'd eventually be able > to figure it out, but like I've said, I've dumped enough hours into this > as it is. I'm hoping someone out there with more skill will be able to > come up with a generic Qubes RBAC policy rule set, since I believe it's > something the Qubes community could share among ourselves as whatever > base rules are needed for the Qubes/Xen architecture to work properly > under RBAC would be consistent across all VMs. > > > > > yes you can shut down the system in the middle of training. > > > > Ah, I did not know that. Will it pick up and append where it left off > training wise on the next reboot? Or will it overwrite the training log? > It did not occur to me to shut down in the middle because all the > examples in the documentation say to put the learning log in /etc/grsec, > so I just did it knowing that it'd get blown away on the next reboot. It > didn't occur to me until after I finished testing that perhaps I should > have put those logs in /home instead. But like I said, at that point, I > had already wasted 3 weeks worth of time, and I didn't feel like trying > again. Maybe I'll try again later, but I don't have the time right now. well you got further then I ever did, lol, if you get it working let us know. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5a5e4ef5-c4d8-42ba-8556-3d96b4332ce8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On 2017-01-25 10:24 AM, raahe...@gmail.com wrote: > > It should tell you what rbac is blocking in dmesg or journal no? it will say > gradm I believe. You should also be seeing grsec and pax messages in there > as well. > It probably did, although sometimes it'll say what was killed, but not specifically why. For example, if a process is denied access to a directory (ex. /var/run or something), it may not be specific enough. But in my case, during training, there's a lot of crap that goes into dmesg, and I didn't discover the actual issues until I restarted the machines with the new rulesets and I never saved the syslogs before rebooting. In the case of the UpdateVM where no AppVMs were able to connect to it and thus wouldn't start, absolutely nothing appeared in the UpdateVMs logs, dmesg or otherwise. I assume it's some kind of Qubes process on the UpdateVM that failed to start (or it did but kills whatever is responsible for allowing an AppVM to connect), but I have no idea which one; like I said, the developer documentation is a bit lacking in terms of specifying what exact processes are responsible for certain tasks, and I think the architecture document is like 10 years old now and doesn't even reflect how the system works currently. Anyways, I'm sure with some more troubleshooting I'd eventually be able to figure it out, but like I've said, I've dumped enough hours into this as it is. I'm hoping someone out there with more skill will be able to come up with a generic Qubes RBAC policy rule set, since I believe it's something the Qubes community could share among ourselves as whatever base rules are needed for the Qubes/Xen architecture to work properly under RBAC would be consistent across all VMs. > > yes you can shut down the system in the middle of training. > Ah, I did not know that. Will it pick up and append where it left off training wise on the next reboot? Or will it overwrite the training log? It did not occur to me to shut down in the middle because all the examples in the documentation say to put the learning log in /etc/grsec, so I just did it knowing that it'd get blown away on the next reboot. It didn't occur to me until after I finished testing that perhaps I should have put those logs in /home instead. But like I said, at that point, I had already wasted 3 weeks worth of time, and I didn't feel like trying again. Maybe I'll try again later, but I don't have the time right now. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/o6anqh%248d4%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On Wednesday, January 25, 2017 at 12:24:57 PM UTC-5, raah...@gmail.com wrote: > On Tuesday, January 24, 2017 at 10:32:18 AM UTC-5, Reg Tiangha wrote: > > On 2017-01-24 7:15 AM, Kopimi Security wrote: > > > On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote: > > >> Yeah, I tried it myself leaving my laptop turned on and on learning mode > > >> for three weeks straight, but it didn't catch everything and certain > > >> things still failed so there's definitely some manual massaging that > > >> needs to be done. > > > > > > Thank you for your input! > > > > > > Would you think a sniffing approach, or a tripwire approach, to be > > > better*? > > > > > > * On a RAM-limited system > > > > > > > That could help with the networking stuff. When I said stuff failed for > > me, I meant more along the lines of certain services or processes that > > were getting killed by the kernel that may or may not be integral to the > > way Qubes does things. > > > > For example, I have both a FirewallVM and an caching UpdateVM running > > squid. The only real difference between the two is squid; otherwise, the > > UpdateVM is just a glorified FirewallVM. Therefore, one would expect > > that the final RBAC ruleset after training between the two would only > > differ with the squid bits. > > > > After my training and applying the custom rulesets for each VM, for > > whatever reason, no AppVM could connect to the UpdateVM once it was > > active (and therefore, the AppVM wouldn't start), but they had no > > problems connecting to the FirewallVM. So obviously, something was > > missed when training the UpdateVM, but I don't know what it was. > > Furthermore, since I don't know how Qubes is archetectured and what > > binaries and libraries are responsible for certain functions (or even > > where they live!), I don't know what to whitelist. And I don't want to > > whitelist entire directories that have or need access for Qubes or Xen > > bits like /usr/bin or /var because I'd be whitelisting a bunch of other > > things I wouldn't want to be doing either. > > > > That's just one example, though. There were some other things I > > encountered as well, but I also concede that some measure of manual > > massaging of rules is probably going to be inevitable in the end. > > > > Could I figure out exactly what was failing with enough time by tracing > > logs and whatnot? Sure, I suppose. But I've sunk in a lot of hours into > > this project already so I don't have as much time to troubleshoot as I > > did over the holidays. So I'm hoping someone smarter than me can figure > > out next steps, at least when it comes to the RBAC stuff. Or at least > > give some hints on what may need to be white listed. > > > > When it comes to the unexpected behaviors that I encountered, I'm still > > leaning towards certain things in the Qubes/Xen chain for various use > > cases that are getting killed without warning that the training didn't > > catch to add to its whitelist. The Grsecurity documentation says that a > > process or library needs to be triggered at least four times during the > > training in order for it to be a bit more lax when it comes time to > > analyze the training log and whitelist more things related to that > > binary or library rather than just whitelisting the binary or library on > > its own, and so maybe certain processes that are needed for Qubes to > > operate just weren't being called enough even after having three weeks > > worth of training. > > > > For example, stuff being called during start up and shut down would > > never trigger that four time threshold, and it'd be hard to record since > > an AppVM's root file system would be nuked every time (in fact, if > > you're not careful with your training or how you invoke it, your VM may > > not start because none of the Qubes startup processes would be captured > > with the training; I worked around it by adding a line to rc.local to > > start the training right away, which helped with start up, but I was > > never able to find a way to capture what Qubes processes were > > responsible when shutting down so I ended up having to kill all my VMs > > to turn them off since RBAC would kill whatever processes were > > responsible for shut down because it never caught them in its training). > > > > Perhaps the training log could be made to be persistent by placing it > > within /home, but I was under the impression that the system couldn't be > > shut down in the middle of training. I could be mistaken, though, but I > > never tried it regardless. I suppose one could write a shutdown script > > that flushed the training log, the question would be when in the > > shutdown process would it be called. It would need to be one of the last > > things in the sequence, otherwise you would risk not catching everything > > possible. > > It should tell you what rbac is blocking in dmesg or journal no? it will say > gradm I believe. You should also be seeing
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On Tuesday, January 24, 2017 at 9:15:10 AM UTC-5, Kopimi Security wrote: > On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote: > > Yeah, I tried it myself leaving my laptop turned on and on learning mode > > for three weeks straight, but it didn't catch everything and certain > > things still failed so there's definitely some manual massaging that > > needs to be done. > > Thank you for your input! > > Would you think a sniffing approach, or a tripwire approach, to be better*? > > * On a RAM-limited system what do you mean by sniffing approach? Tripwire is good to have but it will take alot of fine tuning as well so its not so noisy. The open source version default setups are for outdated operating systems. It also takes strict discipline so you don't miss nothing, don't forget to keep keys separate. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/99bff6b9-45da-44c3-a770-a77bdd96a94b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On 2017-01-24 7:15 AM, Kopimi Security wrote: > On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote: >> Yeah, I tried it myself leaving my laptop turned on and on learning mode >> for three weeks straight, but it didn't catch everything and certain >> things still failed so there's definitely some manual massaging that >> needs to be done. > > Thank you for your input! > > Would you think a sniffing approach, or a tripwire approach, to be better*? > > * On a RAM-limited system > That could help with the networking stuff. When I said stuff failed for me, I meant more along the lines of certain services or processes that were getting killed by the kernel that may or may not be integral to the way Qubes does things. For example, I have both a FirewallVM and an caching UpdateVM running squid. The only real difference between the two is squid; otherwise, the UpdateVM is just a glorified FirewallVM. Therefore, one would expect that the final RBAC ruleset after training between the two would only differ with the squid bits. After my training and applying the custom rulesets for each VM, for whatever reason, no AppVM could connect to the UpdateVM once it was active (and therefore, the AppVM wouldn't start), but they had no problems connecting to the FirewallVM. So obviously, something was missed when training the UpdateVM, but I don't know what it was. Furthermore, since I don't know how Qubes is archetectured and what binaries and libraries are responsible for certain functions (or even where they live!), I don't know what to whitelist. And I don't want to whitelist entire directories that have or need access for Qubes or Xen bits like /usr/bin or /var because I'd be whitelisting a bunch of other things I wouldn't want to be doing either. That's just one example, though. There were some other things I encountered as well, but I also concede that some measure of manual massaging of rules is probably going to be inevitable in the end. Could I figure out exactly what was failing with enough time by tracing logs and whatnot? Sure, I suppose. But I've sunk in a lot of hours into this project already so I don't have as much time to troubleshoot as I did over the holidays. So I'm hoping someone smarter than me can figure out next steps, at least when it comes to the RBAC stuff. Or at least give some hints on what may need to be white listed. When it comes to the unexpected behaviors that I encountered, I'm still leaning towards certain things in the Qubes/Xen chain for various use cases that are getting killed without warning that the training didn't catch to add to its whitelist. The Grsecurity documentation says that a process or library needs to be triggered at least four times during the training in order for it to be a bit more lax when it comes time to analyze the training log and whitelist more things related to that binary or library rather than just whitelisting the binary or library on its own, and so maybe certain processes that are needed for Qubes to operate just weren't being called enough even after having three weeks worth of training. For example, stuff being called during start up and shut down would never trigger that four time threshold, and it'd be hard to record since an AppVM's root file system would be nuked every time (in fact, if you're not careful with your training or how you invoke it, your VM may not start because none of the Qubes startup processes would be captured with the training; I worked around it by adding a line to rc.local to start the training right away, which helped with start up, but I was never able to find a way to capture what Qubes processes were responsible when shutting down so I ended up having to kill all my VMs to turn them off since RBAC would kill whatever processes were responsible for shut down because it never caught them in its training). Perhaps the training log could be made to be persistent by placing it within /home, but I was under the impression that the system couldn't be shut down in the middle of training. I could be mistaken, though, but I never tried it regardless. I suppose one could write a shutdown script that flushed the training log, the question would be when in the shutdown process would it be called. It would need to be one of the last things in the sequence, otherwise you would risk not catching everything possible. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/o67s01%24cd5%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On Monday, January 23, 2017 at 8:38:56 PM UTC+1, Reg Tiangha wrote: > Yeah, I tried it myself leaving my laptop turned on and on learning mode > for three weeks straight, but it didn't catch everything and certain > things still failed so there's definitely some manual massaging that > needs to be done. Thank you for your input! Would you think a sniffing approach, or a tripwire approach, to be better*? * On a RAM-limited system -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e1b6a948-ec60-4dbc-a40f-8ca410a3ef9f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On 2017-01-23 12:05 PM, raahe...@gmail.com wrote: > On Sunday, January 22, 2017 at 6:25:42 PM UTC-5, Kopimi Security wrote: >> Hardened kernel with Grsecurity is coming along nicely - and there is yet >> more to come, as this medium-post shows >> https://medium.com/@securitystreak/living-with-qubes-os-r3-2-rc3-for-a-week-1a37e04c799e >> >> Here's the background, I just sent this mail to coldhak.ca: >> --- >> Referring to https://coldhak.ca/coldkernel/ >> >> 1. >> Please add that error-messages from "sudo update-grub2" can safely be >> ignored. >> As also stated in https://www.qubes-os.org/doc/managing-vm-kernel/ , >> "Installing PV GRUB2". >> >> 2. >> Also please add that one needs to change the kernel in appvms to pvgrub2 >> >> 3. >> And related, that one should also install paxtest and run it to confirm that >> grsecurity is running >> As mentioned at https://micahflee.com/2016/01/debian-grsecurity/ >> >> 4. >> And that there is the option to add further to securing the appvm, by using >> gradm2 in learning mode as explained at >> https://en.wikibooks.org/wiki/Grsecurity/The_Administration_Utility#Full_System_Learning >> --- >> >> And so I'd like to hear if you have any suggestions for RBAC given the >> opportunities for compartmentalization that Qubes OS provides. >> >> Cheers, >> C-c & C-v > > oh dam, thats taking it to the next level. lol. I could be wrong but I think > eventually you have to learn how to edit the file manually as the system > changes, which is beyond me. It would be easier to manage on sys-vms though I > would imagine. > Yeah, I tried it myself leaving my laptop turned on and on learning mode for three weeks straight, but it didn't catch everything and certain things still failed so there's definitely some manual massaging that needs to be done. Unfortunately, I don't know enough about the Qubes architecture to figure out what to white list, and while the Qubes architecture documentation is good with explaining the high-level way the processes work and interact with one another, it doesn't do much to define exactly just what binaries and libraries (either Qubes, Xen or otherwise) are actually responsible for doing the work. If I knew that, then things would be easy to manually white list within RBAC or to manually set PAX flags with paxctl and paxctld. With all the difficulties I've faced, I'm now leaning to just white listing all the Qubes/Xen stuff by default in order to be done with it, even though a small part of me dies inside while saying it since it goes against my personal philosophy of only white listing the absolute minimum needed to make things work. Another thing I haven't quite figured out is how to do the RBAC learning when you have one template VM serving a variety of different service VMs and AppVMs. An extreme example is using the default Fedora-23 template as both a firewall and AppVM. You could do the learning on both the firewall and AppVMs, but how do you then merge those RBAC rules onto the template when you're done? And should you even do that in the first place? For example, you'll want to blacklist a lot more on the firewall VM than you would on the AppVM, so how do you do that if they share the same template? The easy answer, of course, is to use different templates for each use case, but then the situation could easily degenerate into a 1:1 template-to-AppVM ratio, which is also silly and wasteful of disk space as well. I actually gave up on figuring out how to make RBAC work in Qubes for the moment until a better approach at white listing that fits the Qubes way of doing things can be found, although I really love the concept and how it'll deny anything that isn't explicitly allowed. Right now, my service VMs are running on minimal Fedora 25-based templates with just the coldkernel, but when Debian-9 hits stable, I'm going to switch those templates to a stripped down version of it since AppArmor seems to work fine with the default coldkernel at the moment. Hopefully someone out there smarter than me will be able to figure out how to get RBAC working properly within a Qubes environment soon. I really love the concept of it. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/o65m2p%24pk2%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
