Clarify some threat model assumption when Falco is deployed in a K8s cluster

[leogr]

/area documentation

What would you like to be added:

Quoting the last security audit report of Jan 2023 (section 5.1 A note on threat actors , page 8):

Considering Falco might be installed on Kubernetes clusters nodes, it's safe to assume that most
users will be non-trusted unprivileged users, or diminished root users in containers. Indeed by
default, as root in Kubernetes pods, the default set of Linux capabilities is restricted, which means
root doesn't have all capabilities, like CAP_SYS_ADMIN or the ones allowing to reboot or remove
and add kernel modules. In addition, other security mechanisms limit the access to /proc or
/sys as root.

The plurality of "root status" in containers environment creates some confusion. Linux capabilities,
namespace and the various security modules allow to create more complex combination of rights.
However, considering the most used configuration it should be clarified that regular users on
the system, i.e., unprivileged users or containerized root users in Kubernetes pods are the main
threat. Root users on the host and root users in privileged containers should be out of the scope of
the threat actors. As a matter of fact, privileged containers with root users are almost equivalent
to root processes on the host: all except the process Linux namespace are disabled, all capabilities
are granted, virtual file systems are unmasked and LSMs are disabled. It's trivial to pivot from a
privilege container process to "complete root" on the host.

Update the Falco documentation to make the assumption "that most users will be non-trusted unprivileged users, or diminished root users in containers" explicit when Falco is deployed in a K8s cluster. In case that assumption wasn't valid for the adopter use case, the documentation should clearly state that, without additional strategies, a malicious actor may disable Falco, thus voiding its security value.

Why is this needed:

The current documentation might confuse our users and expose them to potential security issues. Making them fully aware of the intended threat model would mitigate such risk.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

cc @LucaGuerra @incertum

[incertum]

"that most users will be non-trusted unprivileged users, or diminished root users in containers"

I agree that improving the documentation on "users" and privileges in the cloud ecosystem is crucial. It is important to provide a clear distinction between Linux and audit users, including elaborating on the concept of sometimes users representing individuals with interactive access. Furthermore, yes it would be beneficial to clarify the meaning of "root" in the context of effective Linux capabilities and privileges, emphasizing the potential damage that could occur if such a user were compromised.

Lastly, while the quoted statement may hold true statistically, it does not necessarily encompass a generic threat model or reflect what each organization truly values. Ultimately, the focus should be on identifying and protecting the specific "crown jewels" of your organization, which can vary greatly from one organization to another.

... without additional strategies, a malicious actor may disable Falco ...

Kindly asking to clarify this?

Disabling Falco may not be as simple as one might think, depending on the deployment configuration. In fact, I believe it is easier for logging to be circumvented through obfuscation techniques or resource exhaustion tricks. Consequently, the community would greatly appreciate documentation that dives into this topic, providing insights into the challenges associated with disabling Falco and more importantly offering guidance on effective measures to mitigate the risks of logging evasion.

intended threat model

Linux security monitoring is unique in every organization because of factors such as the organization's environment, system architecture, risk profile, security objectives, compliance requirements, the evolving threat landscape, and available resources. These factors influence the specific security monitoring needs and approaches of each organization.

Therefore, an alternative approach is to educate the adopter on effectively using Falco and customizing it to align with their organization's requirements and threat model. This approach aims to set realistic expectations and provide additional educational resources beyond Falco's scope. It recognizes that Linux security monitoring encompasses various technologies that span multiple domains, and empowering the adopter with knowledge in these areas can lead to better utilization of Falco and overall security monitoring practices.

Technologies and domains Falco touches: Linux kernel and eBPF, Offensive security, Cyber defense, Incident response, Production deployment and operationalization, Performance optimization and stability, Data pipelines and scale, Big Data and Data Science.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[incertum]

/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[LucaGuerra]

/assign

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/help
/remove-lifecycle stale

[poiana]

@leogr:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help
/remove-lifecycle stale

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[poiana]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh with /remove-lifecycle rotten.

Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle rotten

[poiana]

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community.
/close

[poiana]

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.