Will ReactOS use certificates on OS files?

[Konata]

I don't think it's in NT 5.1, but NT 6 and later sign ntoskrnl.exe and other OS files with a certificate to ensure they aren't modified, and won't boot if their certificates are invalid. I really like this security feature, as it ensures rootkits can't function. Will this be getting in ReactOS, optionally or otherwise? Now, or in the future, after targeting future NT versions? It would be cool to have it as an advanced configuration option during installation, probably off by default for compatibility with NT 5.1 programs (I recall the only "legitimate" use for this method was for antiviruses to have full control of your system), and on by default when targeting NT 6 or greater.

[dsp8195]

It has way more downsides than upsides - every check costs CPU time and does not cures the cause but tries to get rid of symptom. Not to mention the signing was introduced merely to disallow unapproved applications to run on Windows RT.

With rootkits or not, having a working PC is better than a bricked one. The easiest way would be to not sign the files but launch unknown/unapproved applications from restricted "sandbox" account which would not be allowed to make changes to registry or overwrite files in either system or user account directories.

Or, you know, ROS could just do what Linux does.

[Konata]

I don't think you read my post. I asked about ReactOS checking if it's kernel is modified so it can refuse to boot, I didn't say anything about RT/UWP. This is something that Windows started doing in Vista.

[dsp8195]

I don't think you read my post.

My thought exactly. FYI, most of rootkits don't patch the kernel files at all - they either integrate themselves via drivers or hacks in the registry. You don't need to sign any files - just prevent them from installation in the first place.

Signing is bad, because if you don't have easy access to installation medium or recovery partitions, and the only OS you have is compromised (either by a virus or by yourself editing binary resources with ResHacker), it results in a bricked PC.

[Konata]

Well the point of it was just to ensure the integrity of the functionality of the operating system. You could just repair the offline installation if it bricks. But even then, the OS files don't belong to the user in NT 6 and up, so it's not much of an issue anyway. I'm just asking what ReactOS's plans are for the future and if they plan to integrate this now, later (when targeting newer NT versions) or never.

[erkinalp]

We are open source, reproducing a build followed by comparison will suffice to check integrity. No signing needed.

[Konata]

We are open source, reproducing a build followed by comparison will suffice to check integrity. No signing needed.

That'd be a good method too, I suppose. Just anything that would ensure rootkits can't do anything would be nice. Infecting binaries is just bad, no matter what's doing it.

[raijinzrael]

I don't see why signing mechanism can't be implemented for an extra security layer for people and developers requiring it. Only difference would be that, instead ReactOS providing signed builds and stuff like MS does (unmantainable from team side), the OS would only come with the necessary mechanisms in Kernel and Loader for signature checking enforcement, with the proper ifdefs to enable or disable it, and would be your task to provide your own trusted signature to the build process, allowing you to create your own secured builds and signed binaries using your own trusted certificates.

You could even do white lists and disallow execution of binaries not signed with your certificates and such, useful for using in secure environments like ATMs, where you only need the signed OS, the signed ATM app and nothing else. Enabling Secure Boot in this way, by embedding your certificate intro the firmware secure store (a lot of actual systems allow this), would allow preboot secure paths. No one, except your trusted certificate and signature, would be involved in the process.

[ANIKHTOS]

JUST DO NOT
ReactOS is binary compatible to windows 2003 but if it is possible lets get rid off some bad features elements of them.

microsoft is a hype, all the time the new windows, the safest windows ever made, new safety features

and windows is the worse safe os ever,

lets keep the binary compatibility, without the stupidity,
if we just clone windows then whats the point???that it will be named react os??

reactos is a new os that aims to run native windows applications, so lets focus on that

make it run the applications, but the os itself can get rid of lots of bad features and become the windows as they should have been build

if reactos just copy 100% windows then there is no point for them to exist

[PurpleGurl]

I see the point of both posts directly above this one. I do believe it would be handy to have driver signing or similar on hand for situations such as systems running sensitive software or running sensitive applications (like point of sales, investing or banking apps), and yet I also agree with keeping unnecessary complexity out of the equation.

[Konata]

JUST DO NOT
ReactOS is binary compatible to windows 2003 but if it is possible lets get rid off some bad features elements of them.

microsoft is a hype, all the time the new windows, the safest windows ever made, new safety features

and windows is the worse safe os ever,

lets keep the binary compatibility, without the stupidity,
if we just clone windows then whats the point???that it will be named react os??

reactos is a new os that aims to run native windows applications, so lets focus on that

make it run the applications, but the os itself can get rid of lots of bad features and become the windows as they should have been build

if reactos just copy 100% windows then there is no point for them to exist

I have no idea why you would say any of this but I don't think you know anything about NT's architecture or the fact that ReactOS is indeed re-implementing NT's architecture very faithfully, because apart from easier compatibility, it's just a really good architecture.
Windows NT versions before Vista lacked some basic security, like a real multiuser system, but Vista and up are the most secure operating systems on the planet. That's why I'm recommending this, it's a feature that was introduced in Vista but I feel ReactOS could use it now, since it wouldn't break any compatibility and it would just add more security, not less. Plus it would be one less thing to do when it eventually goes to targeting Vista compatibility. Why would you think this would make it less secure?

You should really read up on NT's architecture. The whole reason I'm following this wonderful project is that it's creating an open-source re-implementation of NT's architecture, and shedding light on a lot of undocumented things in it, not just because it can run Windows programs. If that's all you care about, you should just follow the WINE project. Without them we wouldn't have the Windows API and only Native API applications could run. ReactOS is specifically to re-implement NT. And if you actually looked at how the Object Manager works or what the Security Reference Monitor and Security Subsystem looked like, or how they leverage Group Policy, you'd see it's not as insecure as you think.

[erkinalp]

Group Policy, you'd see it's not as insecure as you think

If only Microsoft could drop some of the backwards compatibility, would this be more secure. It is a problem with too much backwards compatibilty duty carried on. GUI stuff partly on kernel for example.

[Konata]

Group Policy, you'd see it's not as insecure as you think

If only Microsoft could drop some of the backwards compatibility, would this be more secure. It is a problem with too much backwards compatibilty duty carried on. GUI stuff partly on kernel for example.

Yeah, moving GDI out of the kernel was always something I hoped for.
You think ReactOS will be doing this?

[raijinzrael]

Yeah, moving GDI out of the kernel was always something I hoped for.
You think ReactOS will be doing this?

No. This would break compatibility with video drivers.
If any, you would expect ROS driver model migrating to the WDDM driver model in a far/distant future. That would mean some parts of the graphic stack returning to user mode, but not more.

[PurpleGurl]

Yes, Microsoft made the decision with NT to move the GDI to the kernel. 95/98/ME had it in the userspace, unless I'm mistaken. One problem with that approach was lack of responsiveness during trouble conditions. It would take forever to wrestle the control back when an application was misbehaving, assuming you could do so at all.