Grsecurity & Openvz

[hmhansolo]

Hello. I am trying to get grsecurity and openvz working together. The biggest problem is that the openvz's development model is to stick to one kernel version and backport important fixes from the later kernel. Their stable version is at 2.6.9. However, their development version is at 2.6.18 right now. So trying to pick a kernel version and use to patches meant for 2 different kernel versions isn't pretty.

So, I am looking for a grsecurity patch against the 2.6.18.* kernel. And I want to see how well openvz and the grsecurity patches for the same kernel work together, if at all.

Where are the archived grsecurity patches kept?

Thanks

[Thrawn]

Take a look at http://forums.grsecurity.net/viewtopic.php?t=328

And please report back about your experiences with grsec + openvz.

[hmhansolo]

Just an update:

I have successfully patched openvz-028test010 and grsec grsecurity-2.1.9-2.6.18-200610021833.patch on linux kernel 2.6.18.

It was actually quite difficult. After manually patching the code that would not automatically patch, I tried compiling. Failures in compiling showed a lot of other bugs. Most of them were due to function declarations changed by OpenVZ. There were actually a couple of code snippets that were mispatched, and I manually repatched it.

So, in the end, the code compiled. Yay!. No idea if it would actually boot or not. But, it did!!

Notice, I have no idea of any possible deadlocks or bugs arising from the merging of the two patches. All I do know for sure, is that it can patch, it can compile, it can boot, and grsec can turn on with the default policy.

I still have to test if openvz can run virtual environments... and I need to test whether grsec can run while an openvz virtual environment is running.. To that end, I am about to run a openvz virtual environment while grsec is in learning mode. Then I will try to apply the new policy and then run some openvz virtual environments.

After the above, one can be sufficiently certain that at least it can work. However, to be certain that it works properlly without bugs, deadlocks, kernel oops, or worse security loopholes, will just need a lot of time and testing.

The security loopholes I mentioned is the biggest problem. Even if everything works without bugs, deadlocks, and kernel oops, which can be tested to some degree (60-80 %) of certainty, just by using it over time, the only way to be certain that security loopholes don't exist is to actually read the code and do a design overview and review of openvz and grsec. These security loopholes, in my opinion, can arise even if both grsec and openvz are secure individually. This is because the way openvz does something may conflict with the way grsec does something, actually opening up a security hole that did not exist either in grsec and openvz.

[hmhansolo]

Oh yeah.. another problem is the maintaince and the update process for this patchset.

The base kernel/patcheset will have to be openvz. This is because openvz releases patches for a stable kernel and does not release for the newest kernel. The grsec patch will then have to patch over openvz.

Openvz states that it backports important/security changes from the latest kernel into their kernel. So that I suppose is good at least.

When grsec puts out an updated patch, what would be needed is a diff patch between 2 grsec patches... that way, I suppose, I can tell what changed between two grsec patches and then update the existing openvz/grsec patchset.

And when openvz puts out a new patch for a new kernel, you have to go through the whole process again. Get the new vanilla kernel version that openvz is supporting, patch with the openvz patch, and then patch with the grsec patch, doing all the necessary manual patching, manual code editing, compiling, testing and what not all over again.

Any ideas?

[hmhansolo]

Doesn't the subject say it all?

So, running grsecurity with the default policy and openvz virtual environments work!! Basically all the `vzctl start 102` and other vzctl maintaince commands can be run perfectly fine after doing a `grsec -a admin`.

So far:

Code: Select all

grsec -a admin
vzctl start 102
vzctl enter 102
/etc/init.d/sshd start
grsec -u


`ssh xxx.xxx.x.yy`, where xxx.xxx.x.yy is the ip address of the virtual environment.. i can successfully log in and i can run stuff like top, ps, etc.. perfectly fine outside of a grsec authenticated role..

its times like these being a geek is so totally fantastic =)...


Update:

scratch the above.. a quick `gradm -D` and `gradm -E` showed me quite clearly that I was in err. So, basically, the sshd process above was also launched in `gradm -a admin` mode, so it had all related priveleges. After a gradm restart, sshd lost those priveleges, and I could no longer ssh into the virtual environment.. All i need to do, I believe, is just add the '/vz/root/102/usr/sbin/sshd' subject to the policy. I am gonna try that and update again.

[hmhansolo]

Hello.. so I have a question regarding the grsec policy I am working on for openvz


Basically, the virtual environment (VE) is in a chroot and it is "mounted". Basically, the actual files of the VE is in /vz/private/102/ and when it is started, it is mounted and chrooted at /vz/root/102...

First I tried the subject as "/vz/root/102/usr/sbin/sshd", but it just wouldn't hit. I then tried the subject as "/vz/private/102/usr/sbin/sshd", thinking that grsec might actually be using the real location of the file. That seems to work.

However, when accesses are denied or logged, they are logged with the "/vz/root/102" directory instead of the "/vz/private/102" directory.

Why is there a discrepancy with the acl ruleset using the "real" location, and the log file using the "mounted" location.