Re: Semantics of blktrace with lockdown (integrity) enabled kernel.

[Junxiao Bi]

On 4/10/23 2:44 PM, Paul Moore wrote:
> On Mon, Apr 10, 2023 at 5:28 PM Junxiao Bi <junxiao.bi@xxxxxxxxxx> wrote:
> > On 4/10/23 1:22 PM, Paul Moore wrote:
> > > On Mon, Apr 10, 2023 at 3:20 PM Junxiao Bi <junxiao.bi@xxxxxxxxxx> wrote:
> > > > On 4/6/23 2:43 PM, Paul Moore wrote:
> > > > > On Thu, Apr 6, 2023 at 3:33 PM Konrad Rzeszutek Wilk
> > > > > <konrad.wilk@xxxxxxxxxx> wrote:
> > > > > > On Thu, Apr 06, 2023 at 02:39:57PM -0400, Paul Moore wrote:
> > > > > ...
> > > > >
> > > > > > > Before we go any further, can you please verify that your issue is
> > > > > > > reproducible on a supported, upstream tree (preferably Linus')?
> > > > > > Yes. Very much so.
> > > > > Okay, in that case I suspect the issue is due to the somewhat limited
> > > > > granularity in the lockdown LSM.  While there are a number of
> > > > > different lockdown "levels", the reality is that the admin has to
> > > > > choose from either NONE, INTEGRITY, or CONFIDENTIALITY.  Without
> > > > > digging to deep into the code path that you would be hitting, we can
> > > > > see that TRACEFS is blocked by the CONFIDENTIALITY (and therefore
> > > > > INTEGRITY too) setting and DEBUGFS is blocked by the INTEGRITY
> > > > > setting.  With DEBUGFS blocked by INTEGRITY, the only lockdown option
> > > > > that would allow DEBUGFS is NONE.
> > > > >
> > > > > Without knowing too much about blktrace beyond the manpage, it looks
> > > > > like it has the ability to trace/snoop on the block device operations
> > > > > so I don't think this is something we would want to allow in a
> > > > > "locked" system.
> > > > blktrace depends on tracepoint in block layer to trace io events of
> > > > block devices,
> > > >
> > > > through the test with mainline, those tracepoints were not blocked by
> > > > lockdown.
> > > >
> > > > If snoop block devices operations is a security concern in lock down, these
> > > >
> > > > tracepoints should be disabled?
> > > Possibly, however, as I said earlier I'm not very familiar with
> > > blktrace and the associated tracepoints.  If it is possible to snoop
> > > on kernel/user data using blktrace then it probably should be
> > > protected by a lockdown control point.
> > >
> > > Is this something you could verify and potentially submit a patch to resolve?
> > blktrace can not snoop kernel/user data. The information it got from
> > kernel is kind of "io metadata", basically include which process from
> > which cpu, at what time, triggered what kind of IO events(issue, queue,
> > complete etc.), to which disk, from which sector offset and how long.
> > blktrace has no way to know what's inside that io. I am kind of think
> > this is safe for lockdown mode.
> Well, you could always submit a patch* and we would review it like any
> other; that's usually a much better approach.
>
> * Yes, there was a patch submitted, but it was against a distro kernel
> that diverged significantly from the upstream kernel in the relevant
> areas.

Sure, i will submit a new one.

Before that, may i ask this question? It may affect the approach of the 
patch.

Lockdown blocked files with mmap operation even that files are 
read-only, may i know what's the security concern there?

static int debugfs_locked_down(struct inode *inode,
                   struct file *filp,
                   const struct file_operations *real_fops)
{
    if ((inode->i_mode & 07777 & ~0444) == 0 &&
        !(filp->f_mode & FMODE_WRITE) &&
        !real_fops->unlocked_ioctl &&
        !real_fops->compat_ioctl &&
        !real_fops->mmap)
        return 0;

    if (security_locked_down(LOCKDOWN_DEBUGFS))
        return -EPERM;

    return 0;
}

Thanks,

Junxiao.

>