On 6/28/22 11:12 AM, KP Singh wrote:
On Tue, Jun 28, 2022 at 6:02 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
On 6/28/2022 8:14 AM, Frederick Lawler wrote:
On 6/27/22 6:18 PM, Casey Schaufler wrote:
On 6/27/2022 3:27 PM, Paul Moore wrote:
On Mon, Jun 27, 2022 at 6:15 PM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote:
On 6/27/22 11:56 PM, Paul Moore wrote:
On Mon, Jun 27, 2022 at 8:11 AM Christian Brauner <brauner@xxxxxxxxxx> wrote:
On Thu, Jun 23, 2022 at 11:21:37PM -0400, Paul Moore wrote:
...
This is one of the reasons why I usually like to see at least one LSM
implementation to go along with every new/modified hook. The
implementation forces you to think about what information is necessary
to perform a basic access control decision; sometimes it isn't always
obvious until you have to write the access control :)
I spoke to Frederick at length during LSS and as I've been given to
understand there's a eBPF program that would immediately use this new
hook. Now I don't want to get into the whole "Is the eBPF LSM hook
infrastructure an LSM" but I think we can let this count as a legitimate
first user of this hook/code.
Yes, for the most part I don't really worry about the "is a BPF LSM a
LSM?" question, it's generally not important for most discussions.
However, there is an issue unique to the BPF LSMs which I think is
relevant here: there is no hook implementation code living under
security/. While I talked about a hook implementation being helpful
to verify the hook prototype, it is also helpful in providing an
in-tree example for other LSMs; unfortunately we don't get that same
example value when the initial hook implementation is a BPF LSM.
I would argue that such a patch series must come together with a BPF
selftest which then i) contains an in-tree usage example, ii) adds BPF
CI test coverage. Shipping with a BPF selftest at least would be the
usual expectation.
I'm not going to disagree with that, I generally require matching
tests for new SELinux kernel code, but I was careful to mention code
under 'security/' and not necessarily just a test implementation :) I
don't want to get into a big discussion about it, but I think having a
working implementation somewhere under 'security/' is more
discoverable for most LSM folks.
I agree. It would be unfortunate if we added a hook explicitly for eBPF
only to discover that the proposed user needs something different. The
LSM community should have a chance to review the code before committing
to all the maintenance required in supporting it.
Is there a reference on how to write an eBPF security module?
There's a documentation page that briefly touches on a BPF LSM implementation [1].
That's a brief touch, alright. I'll grant that the LSM interface isn't
especially well documented for C developers, but we have done tutorials
and have multiple examples. I worry that without an in-tree example for
eBPF we might well be setting developers up for spectacular failure.
Casey, Daniel and I are recommending an in-tree example, it will be
in BPF selftests and we will CC you on the reviews.
Frederick, is that okay with you?
Yep.
There should be something out there warning the eBPF programmer of the
implications of providing a secid_to_secctx hook for starters.
Links:
1. https://docs.kernel.org/bpf/prog_lsm.html?highlight=bpf+lsm#
