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

[Stephen Smalley]

On Thu, Jun 25, 2020 at 11:21 AM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> 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.
>
> 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?

It isn't fundamentally different than the issue of program execution
from a filesystem prior to initial policy load, e.g. executing
programs from the initrd or executing init from the "real" root.
Absent a policy, the process will just remain in the initial
SID/context (kernel SID), which will later be mapped to a context when
policy is loaded.  Typical init programs address this by either
re-exec'ing themselves after policy load or by dynamically switching
contexts via write to /proc/self/attr/current.  The kernel doesn't try
to retroactively transition previously started processes; they are
expected to either exit prior to policy load (ala transient processes
run from initrd) or re-exec or set their contexts after policy load.