[RFC][PATCH] net/bpfilter: Remove this broken and apparently unmantained

Casey Schaufler casey at schaufler-ca.com
Wed Jun 24 19:48:42 UTC 2020


On 6/24/2020 10:54 AM, Alexei Starovoitov wrote:
> On Wed, Jun 24, 2020 at 08:41:37AM -0700, Casey Schaufler wrote:
>> On 6/24/2020 12:05 AM, Tetsuo Handa wrote:
>>> Forwarding to LSM-ML again. Any comments?
>> Hey, BPF folks - you *really* need to do better about keeping the LSM
>> community in the loop when you're discussing LSM issues. 
>>
>>> On 2020/06/24 15:39, Alexei Starovoitov wrote:
>>>> On Wed, Jun 24, 2020 at 01:58:33PM +0900, Tetsuo Handa wrote:
>>>>> On 2020/06/24 13:00, Alexei Starovoitov wrote:
>>>>>>> However, regarding usermode_blob, although the byte array (which contains code / data)
>>>>>>> might be initially loaded from the kernel space (which is protected), that byte array
>>>>>>> is no longer protected (e.g. SIGKILL, strace()) when executed because they are placed
>>>>>>> in the user address space. Thus, LSM modules (including pathname based security) want
>>>>>>> to control how that byte array can behave.
>>>>>> It's privileged memory regardless. root can poke into kernel or any process memory.
>>>>> LSM is there to restrict processes running as "root".
>>>> hmm. do you really mean that it's possible for an LSM to restrict CAP_SYS_ADMIN effectively?
>> I think that SELinux works hard to do just that. SELinux implements it's own
>> privilege model that is tangential to the capabilities model.
> of course. no argument here.
>
>> More directly, it is simple to create a security module to provide finer privilege
>> granularity than capabilities. I have one lurking in a source tree, and I would
>> be surprised if it's the only one waiting for the next round of LSM stacking.
> no one is arguing with that either.
>
>>>> LSM can certainly provide extra level of foolproof-ness against accidental
>>>> mistakes, but it's not a security boundary.
>> Gasp! Them's fight'n words. How do you justify such an outrageous claim?
> .. for root user processes.
> What's outrageous about that?
> Did you capture the context or just replying to few sentences out of the context?

As I mentioned above, you need to include the LSM list in these discussions.
If you don't want "out of context" comments. I replied to what's presented.
And regardless of the context, saying that an LSM can't provide a security
boundary for "root user processes" is just wrong. Obviously there's been more
to the conversation than is included here.





More information about the Linux-security-module-archive mailing list