[PATCH V3] debugfs: allow access blktrace trace files in lockdown mode

Junxiao Bi junxiao.bi at oracle.com
Thu Apr 20 15:04:06 UTC 2023



> On Apr 19, 2023, at 11:00 AM, Paul Moore <paul at paul-moore.com> wrote:
> 
> On Tue, Apr 18, 2023 at 1:27 PM Junxiao Bi <junxiao.bi at oracle.com> wrote:
>> 
>> blktrace trace files are per-cpu relay files that are used by kernel to
>> export IO metadata(IO events, type, target disk, offset and len etc.) to
>> userspace, no data from IO itself will be exported. These trace files have
>> permission 0400, but mmap is supported, so they are blocked by lockdown.
>> Skip lockdown for these files to allow blktrace work in lockdown mode.
>> 
>> v3 <- v2:
>> allow only blktrace trace file instead of relay files
>> https://lore.kernel.org/lkml/b68c9e1d-71c8-adf9-f7da-1b56a3d4bfbc@oracle.com/T/
>> 
>> v2 <- v1:
>> Fix build error when CONFIG_RELAY is not defined.
>> Reported-by: kernel test robot <lkp at intel.com>
>> Link: https://lore.kernel.org/oe-kbuild-all/202304121714.6mahd9EW-lkp@intel.com/
>> Signed-off-by: Junxiao Bi <junxiao.bi at oracle.com>
>> ---
>> fs/debugfs/file.c            | 10 ++++++++++
>> include/linux/blktrace_api.h |  3 +++
>> include/linux/relay.h        |  3 +++
>> kernel/relay.c               | 16 ++++++++++++++++
>> kernel/trace/blktrace.c      |  7 +++++++
>> 5 files changed, 39 insertions(+)
>> 
>> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
>> index 1f971c880dde..973e38f3e8a1 100644
>> --- a/fs/debugfs/file.c
>> +++ b/fs/debugfs/file.c
>> @@ -21,6 +21,7 @@
>> #include <linux/pm_runtime.h>
>> #include <linux/poll.h>
>> #include <linux/security.h>
>> +#include <linux/blktrace_api.h>
>> 
>> #include "internal.h"
>> 
>> @@ -142,6 +143,12 @@ EXPORT_SYMBOL_GPL(debugfs_file_put);
>>  * Only permit access to world-readable files when the kernel is locked down.
>>  * We also need to exclude any file that has ways to write or alter it as root
>>  * can bypass the permissions check.
>> + * Exception:
>> + * blktrace trace files are per-cpu relay files that are used by kernel to
>> + * export IO metadata(IO events, type, target disk, offset and len etc.) to
>> + * userspace, no data from IO itself will be exported. These trace files have
>> + * permission 0400, but mmap is supported, so they are blocked by lockdown.
>> + * Skip lockdown for these files to allow blktrace work in lockdown mode.
>>  */
>> static int debugfs_locked_down(struct inode *inode,
>>                               struct file *filp,
>> @@ -154,6 +161,9 @@ static int debugfs_locked_down(struct inode *inode,
>>            !real_fops->mmap)
>>                return 0;
>> 
>> +       if (blk_trace_is_tracefile(inode, real_fops))
>> +               return 0;
> 
> I think it would be a little more foolproof if we made the connection
> to lockdown a bit more explicit in the relay/blktrace code.  How about
> something like this here, borrowing your previously defined
> 'is_relay_file()' function:
> 
>  if (is_relay_file(real_fops) && relay_bypass_lockdown(inode, real_fops))
>    return 0;
> 
> ... and in the relay code we would have something like this, borrowing
> from your logic in this patch, and using some shortcut-y pseudo-code:
> 
>  bool relay_bypass_lockdown(struct inode *inode,
>                             const struct file_operations *fops)
>  {
>    struct rchan_buf *buf = inode->i_private;
> 
>    if (buf->chan->cb->bypass_lockdown)
>      return buf->chan->cb->bypass_lockdown(inode);
> 
>    return false;
>  }
> 
> ... where in the case of blktrace rchan_callbacks::bypass_lockdown
> would be a simple "true", assuming it is safe to do so (we need some
> ACKs from the blktrace folks):
> 
>  bool blk_trace_bypass_lockdown(struct inode *inode)
>  {
>    return true;
>  }
Good idea. Will make a new version for it. Thanks.
> 
> -- 
> paul-moore.com


More information about the Linux-security-module-archive mailing list