Re: [RFC PATCH 0/2] Landlock network PoC implementation
From: Konstantin Meskhidze <hidden>
Date: 2021-12-30 06:53:41
Hi, Paul Thanks for your comment. 12/11/2021 2:01 AM, Paul Moore wrote:
On Fri, Dec 10, 2021 at 11:57 AM Casey Schaufler [off-list ref] wrote:quoted
As I think you've realized, *sockets are not objects*. There isn't a way to justify them as objects without introducing ethereal or magical subjects that don't exist. Sockets are part of a process. OK, it's not that simple, and it would be foolish to deny that a socket may have security relevant properties. But they aren't objects. I strongly recommend that you follow Smack's example and use the sending task and receiving task attributes to make the decision. You may find that storing that information in the socket security blob is convenient. BTW - not everyone agrees with me on this topic. I'll leave the misguided to make their own arguments. ;)I'm running low on my lets-argue-on-the-internet motivation today, but I feel like I'm being goaded into some sort of comment so I will simply offer SELinux as a rebuttal to Casey's comments. I think that either approach can be acceptable, it depends on how your security model works and your comfort level with the various tradeoffs associated with each approach. I personally prefer the approach SELinux has taken (minus some of the compat cruft we are saddled with, not to mention that restrictions handed to use from netdev), but I'll admit a certain level of bias in this.
I just tried to follow Landlock's implementation concept: attaching policy rules to kernel objects. For filesystem "objects" are underlying inodes. For socket the same approach could be used - using sockets' inodes as "object". I also read about this concept from some LSM papers: https://www.usenix.org/legacy/events/sec02/full_papers/wright/wright.pdf https://elinux.org/images/0/0a/ELC_Inside_LSM.pdf
-- paul moore www.paul-moore.com .