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

Casey Schaufler casey at schaufler-ca.com
Thu Jun 25 16:06:22 UTC 2020


On 6/25/2020 8:21 AM, Tetsuo Handa wrote:
> 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.

It should also be noted that Smack uses multiple xattrs. It is also
possible for multiple current security modules to use xattrs, including
capabilities. It's not sufficient to provide "the security xattr", there
would have to be provision for general security xattrs.

> 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.

A security module has to have some sort of policy for whatever happens prior
to "policy load" as it is. That's not unique to this situation.





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