Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Raising the AppContainer to the level of Linux namespaces #78

Open
RealAlphabet opened this issue Jul 23, 2024 · 2 comments
Open
Labels
feature-request Feature or enhancement request

Comments

@RealAlphabet
Copy link

Summary

Enhance the Windows AppContainer feature to provide better isolation and security. This includes implementing a mechanism to hide the adjacent filesystem, introducing a kernel-level filtering system similar to eBPF on Linux for secure and optimized file management, and concealing the AppContainer status from applications to prevent them from detecting their contained environment.

Pitch

Improving the AppContainer feature will significantly enhance the security and isolation of applications running in a contained environment. By hiding the filesystem, applications will be unable to access or even detect files and folders outside their container, thus protecting user data and system integrity. Introducing a kernel-level filtering mechanism, akin to eBPF on Linux, will allow developers to create highly secure and optimized programs that can dynamically enforce permissions policies.

Concealing the AppContainer status will prevent applications from altering their behavior based on their environment, thereby thwarting potential malicious activities. These enhancements will elevate AppContainers to the security level of Linux namespaces, reducing risks associated with running untrusted applications and ensuring comprehensive monitoring and isolation for a safer computing experience.

@RealAlphabet RealAlphabet added the feature-request Feature or enhancement request label Jul 23, 2024
@cchavez-msft
Copy link
Contributor

Hi, @RealAlphabet

Thank you so much for engaging with us! Your proposal indeed is a great idea. However, implementing these changes would unfortunately break compatibility with most existing Win32 apps. Moreover, maintaining compatibility with a vast array of existing applications is crucial for our users, as it ensures stability and usability across the Windows ecosystem. Thus, I am sorry I can't give the answer you want.

Please, do let me know if you have any more questions or suggestions. We strongly appreciate your input.

@RealAlphabet
Copy link
Author

Hi, @RealAlphabet

Thank you so much for engaging with us! Your proposal indeed is a great idea. However, implementing these changes would unfortunately break compatibility with most existing Win32 apps. Moreover, maintaining compatibility with a vast array of existing applications is crucial for our users, as it ensures stability and usability across the Windows ecosystem. Thus, I am sorry I can't give the answer you want.

Please, do let me know if you have any more questions or suggestions. We strongly appreciate your input.

Thank you for your reply. I may have misspoken, but this is not supposed to break compatibility with Win32 applications.

The Windows ecosystem now needs, more than ever, reliable application isolation methods that prevent anti-virus software from having to execute privileged kernel code.

A few years ago, some AVs used drivers and modified the Windows kernel code for certain security features. Since the advent of AKP (Anti Kernel Patch), the resources available to anti-virus software have been greatly reduced in the face of increasingly intelligent computer viruses.

To back up my argument that a mechanism similar to eBPF on Linux (with seccomp) is needed on Windows, the recent CrowdStrike incident, which affected millions of Windows devices, highlighted several extremely important issues that underline the fragility of the Windows ecosystem and the fragility of kernel code reviews. As proof, Crowdstrike bypassed Microsoft's review and dynamically executed code at the most privileged level on the system, in the kernel. Other rootkits do this, kernel anticheats such as Vanguard, Valorant's anticheat.

If Windows had such a system, current security tools would not need to execute code in the kernel, or they could do so safely, under Microsoft's control, and without impacting on the stability of the system.

I'm just a user and a developer, but I love the Windows ecosystem and I'm convinced that Microsoft is aware of these issues.

If need be, I'm prepared to write a complete proposal with friends who are already professionally involved in cyber security. I just don't know whether non-employees can make this kind of proposal and where it should be made.

Thank you very much for your previous reply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Feature or enhancement request
Projects
None yet
Development

No branches or pull requests

2 participants