Yet another vision of Linux security | Endpoint Security Framework

[Timur Chernykh]

> Please don't assume that everyone knows your abbreviations.
> Audio Visual / Editable Data Record.

I'm sorry for that. Of course, AV - Antivirus, EDR - Endpoint
Detection and Response.

> "Consistent" is hardly a term you can use to describe Linux security events.
> Is binding a socket to a port a security event? Where is the security event
> when using io_uring?

Under "consistent" I mean "has a unified structure". Currently all
security mechanisms in Linux have a different events format and it's
an additional task to read, parse and transform it to a unified view.
The assumed list of security events can be found at
https://github.com/Linux-Endpoint-Security-Framework/linux/blob/esf/main/include/uapi/linux/esf/defs.h#L73

> A comprehensive set of events is likely to overwhelm any user space
> collector.

I'm definitely agree. The kernel in my vision must define what
security events are, as it is done with LSM. Userspace should have a
restricted set of security events, it shouldn't know about any kernel
internals. Each event should be a kind of abstraction above what
really happens. There is a good example of real-life implementation:
https://developer.apple.com/documentation/endpointsecurity/event_types.
For my vision of linux security events in userspace, please, look the
link above thought.

> "Consistent" is hardly a term you can use to describe Linux security events.

Yes, and this is a bad thing, which I want to fix.

> Is binding a socket to a port a security event? Where is the security event
> when using io_uring?

Socket binding may not be a security event itself, but a listening
port for a network connection is. And it doesn't matter how many steps
are included to a port listening itself. Opening socket, setup,
binding should be converted to a single event, that says to userspace
agent: "Hey, this process is trying to listen to the socket for a
network connection. Do you want to allow this action?".

> Performance concerns (locking, sleeping and a host of others) are
> likely to prevent this.

It's not an unresolvable task. MacOS and Windows solved this issue.
Anyway, users should have a choice between security and performance.
All modern security solutions in any implementation already affect the
linux performance.

> If the kernel's policies, mechanisms and structures were more consistent
> you might have a chance at this.

I think that's a work I (and even probable we) should work for. As a
better OS Linux should provide userspace stable structured security
events.

> User-space arbitration of kernel events won't work. It's been tried
> repeatedly. I started seeing it in the early 1980's. It always devolved
> into a kernel bolt-on, with sub-optimal performance and versatility.

Can you give examples, please? I don't remember early '80, hah, I want
to get to know about previous attempts :)
I don't be sure if this is impossible. As I mentioned before, Windows
and MacOS are done with it. Anyway, I think that users must have a
choice.