linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cdde1e4e-142e-3859-71ba-f7bacf0dbaae@oracle.com>
Date:   Mon, 10 Apr 2023 14:51:46 -0700
From:   Junxiao Bi <junxiao.bi@...cle.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, jmorris@...ei.org,
        serge@...lyn.com, nathanl@...ux.ibm.com, joe.jin@...cle.com,
        Eric <eric.snowberg@...cle.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>, axboe@...nel.dk
Subject: Re: Semantics of blktrace with lockdown (integrity) enabled kernel.


On 4/10/23 2:44 PM, Paul Moore wrote:
> On Mon, Apr 10, 2023 at 5:28 PM Junxiao Bi <junxiao.bi@...cle.com> wrote:
>> On 4/10/23 1:22 PM, Paul Moore wrote:
>>> On Mon, Apr 10, 2023 at 3:20 PM Junxiao Bi <junxiao.bi@...cle.com> 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@...cle.com> 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.

>