We are using Oracle VirtualBox OSE as a part of our custom virtualization infrastructure, and compile it on our CI servers. One of numerous compilation parameters you can add into LocalConfig.kmk is VBOX_WITH_HARDENING = 0, which obviously means compiling VirtualBox without Hardening. Also, you could not turn it on, if you compile it yourself.

I could not find in official build instructions, what in "hardening" on the "low-level", as far as I understood it's a some security patch, increasing guest OS-es protection against some type of exploits. However, it still leaves a lot of questions. What is it physically, a driver, a patch, an application? Why Hardening sources are not included in VirtualBox OSE, an open-source product?And the main question, is it possible to compile VirtualBox OSE with Hardening?

VirtualBox is not an open source project, only the OSE version is. The commercial version has both open and closed source, the latter mostly in the extension pack. I'm not sure what you're saying there: are you saying that you want to decide which modules the copyright holder releases source code for?

Letting a hacker see what the software does to detect hacking would be rather self defeating don't you think?

Yurii.Ch wrote:One of numerous compilation parameters you can add into LocalConfig.kmk is VBOX_WITH_HARDENING = 0, which obviously means compiling VirtualBox without Hardening.

Or you can specify it in the command line options with the "--disable-hardening" switch. That's how I do it, I don't use it in the "LocalConfig.kmk". In fact, I use the opposite, I have "VBOX_WITH_HARDENING = 1" set in the LocalConfig.kmk, and I omit the "--disable-hardening" switch, when I want to build a hardened build.

Yurii.Ch wrote:Also, you could not turn it on, if you compile it yourself.

Yes, you can. See above.

Yurii.Ch wrote:I could not find in official build instructions

You didn't even mention where you're building VirtualBox (your host), so I'm not sure which instructions you refer to.

Yurii.Ch wrote:as far as I understood it's a some security patch, increasing guest OS-es protection against some type of exploits

That would be a very close description. The idea is to prevent known vectors of attack, like simple user having access to the host kernel via the VirtualBox libs/bins/modules. For some more info see the first few paragraphs of the "Diagnosing VirtualBox Hardening Issues" FAQ.

Yurii.Ch wrote:What is it physically, a driver, a patch, an application?

Additional checks. For example (and I'll speak about the OSX build), you have to specify during the build where exactly your built application is going to be located in the filesystem, and its exact name. If the app does not meet the requirements, as defined during the build process, the app won't run. That's why you cannot relocate VirtualBox.app, and that includes renaming it! "VirtualBox-5.2.18.app" won't run, "VirtualBox.app" will.

Another thing to note is that you cannot run VirtualBox from its "out/<platform>.<arch>/release/" location if you're building a hardened build. You'll see a "Hardening error"...

Yurii.Ch wrote:Why Hardening sources are not included in VirtualBox OSE, an open-source product?

Why do you think they're not included? Of course they are, otherwise you wouldn't be able to build a hardened build!

Yurii.Ch wrote:And the main question, is it possible to compile VirtualBox OSE with Hardening?

Yes, see above.

I had already compiled my answer, when mpack's message got in, I thought I'd address that as well:

mpack wrote:Letting a hacker see what the software does to detect hacking would be rather self defeating don't you think?

Oh, but they do let you see what's going on. This is not a "security through obscurity" case. Remember that the most secure projects are indeed open source...

If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.

socratis wrote:You didn't even mention where you're building VirtualBox (your host), so I'm not sure which instructions you refer to.

Windows 10

socratis wrote:Or you can specify it in the command line options with the "--disable-hardening" switch. That's how I do it, I don't use it in the "LocalConfig.kmk". In fact, I use the opposite, I have "VBOX_WITH_HARDENING = 1" set in the LocalConfig.kmk, and I omit the "--disable-hardening" switch, when I want to build a hardened build.

Yurii.Ch wrote:as far as I understood it's a some security patch, increasing guest OS-es protection against some type of exploits

That would be a very close description. The idea is to prevent known vectors of attack, like simple user having access to the host kernel via the VirtualBox libs/bins/modules. For some more info see the first few paragraphs of the "Diagnosing VirtualBox Hardening Issues" FAQ.

Thanks for quick answer and detailed explanation, we will try. I don't remember exact details, but when we tried to compile it hardened first, we failed, but now we have more experience with build process and troubleshooting.

I take it then that you've already taken a look at the "Windows build instructions", and especially the self-signing binaries part...

If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.