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.
