Messages in this thread | | | Date | Fri, 25 Feb 2022 12:10:46 -0800 | Subject | Re: [PATCH] userfaultfd, capability: introduce CAP_USERFAULTFD | From | Casey Schaufler <> |
| |
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@redhat.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 >>
| |