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.
