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

[Tetsuo Handa]

On 2020/06/25 23:26, Stephen Smalley wrote:
> On Thu, Jun 25, 2020 at 9:25 AM Greg Kroah-Hartman
> <gregkh at linuxfoundation.org> wrote:
>>
>> On Thu, Jun 25, 2020 at 08:56:10AM -0400, Stephen Smalley wrote:
>>> No, because we cannot label the inode based on the program's purpose
>>> and therefore cannot configure an automatic transition to a suitable
>>> security context for the process, unlike call_usermodehelper().
>>
>> Why, what prevents this?  Can you not just do that based on the "blob
>> address" or signature of it or something like that?  Right now you all
>> do this based on inode of a random file on a disk, what's the difference
>> between a random blob in memory?
> 
> Given some kind of key to identify the blob and look up a suitable
> context in policy, I think it would work.  We just don't have that
> with the current interface.  With /bin/kmod and the like, we have a
> security xattr assigned to the file when it was created that we can
> use as the basis for determining the process security context.

My understanding is that fork_usermode_blob() is intended to be able to run
without filesystems so that usermode blobs can start even before global init
program (pid=1) starts.

But SELinux's policy is likely stored inside filesystems which would be
accessible only after global init program (pid=1) started.

Therefore, I wonder whether SELinux can look up a suitable context in policy
even if "some kind of key to identify the blob" is provided.
Also, since (at least some of) usermode blob processes started via
fork_usermode_blob() will remain after SELinux loads policy from filesystems,
I guess that we will need a method for moving already running usermode blob
processes to appropriate security contexts.

Is my understanding/concerns correct?