I have a suggestion for an alternate approach to managing source-based libraries in Buck. What do you think of changing the documentation such that Buck open source users first run CMake to setup the source checkouts and patching, then we update the expected paths in Buck to look for a ./build folder or ./libraries/cmake/source. This avoids duplicating generated code and avoids duplicating submodule configurations.

I have a suggestion for an alternate approach to managing source-based libraries in Buck. What do you think of changing the documentation such that Buck open source users first run CMake to setup the source checkouts and patching, then we update the expected paths in Buck to look for a ./build folder or ./libraries/cmake/source. This avoids duplicating generated code and avoids duplicating submodule configurations.

Buck has since been removed from this version of osquery. How can we take a next step on this PR?

The build becomes much easier since we are nearly 100% using the source layer in CMake.

Ping @alessandrogario, are we still interested in merging these features? Is there a strong desire for this data?

Ping @alessandrogario, are we still interested in merging these features? Is there a strong desire for this data?

We did write this for one of our clients and would still like to see it merged. I was asking earlier about the next step. It looks like it hasn't been reviewed, but there was a Buck-related suggestion that is I assume no longer applicable. If we rebased this PR and removed the Buck files, would it be eligible for a PR review at that point?

If we rebased this PR and removed the Buck files, would it be eligible for a PR review at that point?

I am broadly interested in this work. The PR does need a refresh though. (sorry)

If we rebased this PR and removed the Buck files, would it be eligible for a PR review at that point?

I am broadly interested in this work. The PR does need a refresh though. (sorry)

I believe the PR is refreshed and it was just not communicated well. If someone can review/approve, I think this PR is ready.

+1 on this feature. Of note, file capabilities and process capabilities can be different as a set of capabilities can be preserved across an execve. For this reason, I analyze process capabilities so that inheritable capabilities (CapInh) are collected by osquery.
For example ...

cat /proc/$pid/status
[...]
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	0000003ff7fdffff
CapAmb:	0000000000000000
NoNewPrivs:	1
Seccomp:	2

An approach the parses out /proc table will also allow include NoNewPrivs as well as Seccomp process attributes. Perhaps, we can extend https://osquery.io/schema/4.5.0/#processes table to include additional attributes? Could someone point me to the https://osquery.io/schema/4.5.0/#processes Linux C/C++ code?

Here's an example of a osquery-go-sdk extension ...

osquery> SELECT name, cmdline, seccomp, nonewprivs, capeff, capamb FROM process_security;
+-----------------+----------------------------------------------+---------+------------+------------------+------------------+
| name            | cmdline                                      | seccomp | nonewprivs | capeff           | capamb           |
+-----------------+----------------------------------------------+---------+------------+------------------+------------------+
| dns | dns             | 2       | 1          | 0000000000000000 | 0000000000000000 |
| edgeworker | /usr/local/bin/worker-debug              | 2       | 1          | 0000000000000000 | 0000000000000000 |

The PR LGTM aside from renaming extended_attributes to file_capabilties.

I like the idea of another processes_ table for Linux security attributes vs further extending the processes table, but that is not a strong opinion.

One user experience I like is having processes be as cross platform as possible, then each OS’s specific processes-related data shows up in nuanced and specific additional tables. In this scenario the overhead of joining those tables together should be minimal.

A downside to using two joined tables, is you can get inconsistencies for rapidly changing data. (This is potentially an issue with processes, we've had customers bump into problems with other vendor solutions joining processes to open sockets)