Suggestions for RBAC for grsecurity-enabled kernel?

[Kopimi Security]

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

[raah...@gmail.com]

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.

[Reg Tiangha]

On 2017-01-23 12:05 PM, raah...@gmail.com
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.

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.

[Kopimi Security]

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

[Reg Tiangha]

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.

[raah...@gmail.com]

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.

[raah...@gmail.com]

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.

[raah...@gmail.com]

yes you can shut down the system in the middle of training.

[Reg Tiangha]

On 2017-01-25 10:24 AM, raah...@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.

[raah...@gmail.com]

well you got further then I ever did, lol, if you get it working let us know.

[Kopimi Security]

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.

[raah...@gmail.com]

I think by proactive approach they mean pen testing.

[raah...@gmail.com]

https://www.amazon.com/Basics-Hacking-Penetration-Testing-Second/dp/0124116442