linux-kernel - Re: [PATCH] userfaultfd, capability: introduce CAP

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] [day] [month] [year] [list]

Message-ID: <686276b9-4530-2045-6bd8-170e5943abe4@schaufler-ca.com>
Date:   Fri, 25 Feb 2022 12:10:46 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Axel Rasmussen <axelrasmussen@...gle.com>,
        Peter Xu <peterx@...hat.com>
Cc:     Andrea Arcangeli <aarcange@...hat.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Serge Hallyn <serge@...lyn.com>,
        Paul Moore <paul@...l-moore.com>,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        Eric Paris <eparis@...isplace.org>,
        Ondrej Mosnacek <omosnace@...hat.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jeremy Kerr <jk@...econstruct.com.au>,
        linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
        Suren Baghdasaryan <surenb@...gle.com>,
        Lokesh Gidra <lokeshgidra@...gle.com>,
        Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH] userfaultfd, capability: introduce CAP_USERFAULTFD

On 2/25/2022 10:17 AM, Axel Rasmussen wrote:
> Thanks for the detailed explanation Casey!
>
> On Thu, Feb 24, 2022 at 6:58 PM Peter Xu <peterx@...hat.com> wrote:
>> On Thu, Feb 24, 2022 at 04:39:44PM -0800, Casey Schaufler wrote:
>>> What I'd want to see is multiple users where the use of CAP_USERFAULTD
>>> is independent of the use of CAP_SYS_PTRACE. That is, the programs would
>>> never require CAP_SYS_PTRACE. There should be demonstrated real value.
>>> Not just that a compromised program with CAP_SYS_PTRACE can do bad things,
>>> but that the programs with CAP_USERFAULTDD are somehow susceptible to
>>> being exploited to doing those bad things. Hypothetical users are just
>>> that, and often don't materialize.
>> I kind of have the same question indeed..
>>
>> The use case we're talking about is VM migration, and the in-question
>> subject is literally the migration process or thread.  Isn't that a trusted
>> piece of software already?
>>
>> Then the question is why the extra capability (in CAP_PTRACE but not in
>> CAP_UFFD) could bring much risk to the system.  Axel, did I miss something
>> important?
> For me it's just a matter of giving the live migration process as
> little power as I can while still letting it do its job.

That's understood. But live migration is a bit of a special case,
and as mentioned above, is trusted to do an oodle of important stuff
correctly.

> Live migration is somewhat trusted, and certainly if it can mess with
> the memory contents of its own VM, that's no concern. But there are
> other processes or threads running alongside it to manage other parts
> of the VM, like attached virtual disks. Also it's probably running on
> a server which also hosts other VMs, and I think it's a common design
> to have them all run as the same user (although, they may be running
> in other containers).

That seems unwise. I am often surprised how we're eager to add
new security features to make up for the unwillingness of people
to use the existing ones.

> So, it seems unfortunate to me that the live migration process can
> just ptrace() any of these other things running alongside it.

I get that. On the other hand, most of the systems you'll run
live migration on are going to have full-up root processes,
possibly even userfaultd (in spite of instructions not to do so).

> Casey is right that we can restrict what it can do with e.g. SELinux
> or seccomp-ebpf or whatever else. But it seems to me a more fragile
> design to give the permissions and then restrict them, vs. just never
> giving those permissions in the first place.

If we lived in a universe with a root-less reality I'd agree.

> In any case though, it sounds like folks are more amenable to the
> device node approach. Honestly, I got that impression from Andrea as
> well when we first talked about this some months ago. So, I can pursue
> that approach instead.

I think that's more realistic.

>
>> Thanks,
>> --
>> Peter Xu
>>