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

[Junxiao Bi]

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?

[root@jubi-ol8 tracecmd]# uname -a
Linux jubi-ol8 6.3.0-rc6.master.20230410.ol8.x86_64 #1 SMP 
PREEMPT_DYNAMIC Mon Apr 10 03:33:56 PDT 2023 x86_64 x86_64 x86_64 GNU/Linux
[root@jubi-ol8 tracecmd]# cat /sys/kernel/security/lockdown
none [integrity] confidentiality
[root@jubi-ol8 tracecmd]# trace-cmd record -e block:block_rq_issue -e 
block:block_rq_complete
Hit Ctrl^C to stop recording
^CCPU0 data recorded at offset=0x9fa000
    4096 bytes in size
CPU1 data recorded at offset=0x9fb000
    4096 bytes in size
CPU2 data recorded at offset=0x9fc000
    53248 bytes in size
CPU3 data recorded at offset=0xa09000
    12288 bytes in size

Thanks,

Junxiao.

> Sorry.