[RFC PATCH 0/2] Landlock network PoC implementation

[Konstantin Meskhidze]

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 <casey at schaufler-ca.com> wrote:
>> 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
> .