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 grsec and pax messages in there > as well.
yes you can shut down the system in the middle of training. -- 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/3025cc8b-becc-4b45-b1ca-67b53722e955%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
