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

[Junxiao Bi]

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.

The following is sample of blktrace output.

252,0    1        1     0.000000000  2570  Q   W 45779288 + 48 [nstat]
252,0    1        1     0.000000000  2570  Q   W 45779288 + 48 [nstat]
252,0    1        1     0.000000000  2570  Q   W 45779288 + 48 [nstat]
252,0    1        1     0.000000000  2570  Q   W 45779288 + 48 [nstat]
252,0    3        1     0.001038626  2572  C   W 45779288 + 48 [0]
252,0    3        1     0.001038626  2572  C   W 45779288 + 48 [0]
252,0    3        1     0.001038626  2572  C   W 45779288 + 48 [0]
252,0    3        1     0.001038626  2572  C   W 45779288 + 48 [0]
252,0    1        2     1.764157693  1384  Q  WS 24577112 + 8 [auditd]
252,0    1        2     1.764157693  1384  Q  WS 24577112 + 8 [auditd]
252,0    1        2     1.764157693  1384  Q  WS 24577112 + 8 [auditd]
252,0    1        2     1.764157693  1384  Q  WS 24577112 + 8 [auditd]
252,0    1        3     1.764216845  1384  Q  WS 24577120 + 16 [auditd]
252,0    1        3     1.764216845  1384  Q  WS 24577120 + 16 [auditd]
252,0    1        3     1.764216845  1384  Q  WS 24577120 + 16 [auditd]
252,0    1        3     1.764216845  1384  Q  WS 24577120 + 16 [auditd]


Thanks,

Junxiao.

>