linux-kernel - Semantics of blktrace with lockdown (integrity) enabled kernel.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZC8Dbux56HbJjpTy@char.us.oracle.com>
Date:   Thu, 6 Apr 2023 13:37:50 -0400
From:   Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:     linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, paul@...l-moore.com,
        jmorris@...ei.org, serge@...lyn.com, nathanl@...ux.ibm.com,
        junxiao.bi@...cle.com, joe.jin@...cle.com,
        Eric <eric.snowberg@...cle.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>, axboe@...nel.dk
Subject: Semantics of blktrace with lockdown (integrity) enabled kernel.

Hey Jens, Paul, James, Nathan,

We are trying to use blktrace with a kernel that has lockdown enabled and find that it cannot run.

Specifically the issue is that we are trying to do is pretty simple:

strace -f blktrace -d /dev/sda -w 60

[pid 148882] <... mprotect resumed>)    = 0
[pid 148881] openat(AT_FDCWD, "/sys/kernel/debug/block/sda/trace0", O_RDONLY|O_NONBLOCK <unfinished ...>
[pid 148882] sched_setaffinity(0, 8, [1]) = 0
[pid 148881] <... openat resumed>)      = -1 EPERM (Operation not permitted)

which fails. The analysis from Eric (CCed) is that 

All debugfs entries do not exist until blktrace is run.  It is opening
/sys/kernel/debug/block/sda/trace0 which isn’t there normally. While running the utility, 
to place something in it, it must have the write permission set.  When exiting out of 
blktrace, the entry is gone, both on a machine running with secure boot enabled 
and one with it disabled.  Which also indicates the write permission was set, 
otherwise the entry would still be there.

The fix is simple enough (see attachment) but we are not sure about the semantics of what
lockdown has in mind.

Looking at the include/linux/security.h the LOCKDOWN_TRACEFS exists which would
imply that it is expected that operations with tracefs *should* work with lockdown (integrity mode).

But at the same point, debugfs writable attributes are a nono with lockdown.

So what is the right way forward?

Thank you.

View attachment "0001-debugfs-whitelisted-relay-file-for-lockdown.patch" of type "text/plain" (2221 bytes)