[PATCH] capabilities: Introduce CAP_RESTORE

Casey Schaufler casey at schaufler-ca.com
Wed May 27 15:57:04 UTC 2020


On 5/27/2020 6:48 AM, Adrian Reber wrote:
> On Mon, May 25, 2020 at 11:55:20AM -0700, Casey Schaufler wrote:
>> On 5/25/2020 1:05 AM, Adrian Reber wrote:
>>> On Fri, May 22, 2020 at 09:40:37AM -0700, Casey Schaufler wrote:
>>>> On 5/21/2020 10:53 PM, Adrian Reber wrote:
>>>>> This enables CRIU to checkpoint and restore a process as non-root.
>>>> I know it sounds pedantic, but could you spell out CRIU once?
>>>> While I know that everyone who cares either knows or can guess
>>>> what you're talking about, it may be a mystery to some of the
>>>> newer kernel developers.
>>> Sure. CRIU - Checkpoint/Restore In Userspace.
>> Thanks. I blew out my acronym processor in the 1990's while
>> working on trusted Unix system security evaluations.
>>
>>>>> Over the last years CRIU upstream has been asked a couple of time if it
>>>>> is possible to checkpoint and restore a process as non-root. The answer
>>>>> usually was: 'almost'.
>>>>>
>>>>> The main blocker to restore a process was that selecting the PID of the
>>>>> restored process, which is necessary for CRIU, is guarded by CAP_SYS_ADMIN.
>>>> What are the other blockers? Are you going to suggest additional new
>>>> capabilities to clear them?
>>> As mentioned somewhere else access to /proc/<pid>/map_files/ would be
>>> helpful. Right now I am testing with a JVM and it works without root
>>> just with the attached patch. Without access to /proc/<pid>/map_files/
>>> not everything CRIU can do will actually work, but we are a lot closer
>>> to what our users have been asking for.
>> Are you talking about read access to map_files owned by other users
>> or write access to map_files for the current user?
> If I understand part of CRIU correctly, then we only need read-access
> for the current user. I am sure Andrei, Pavel or Cyrill will correct me
> if I am wrong concerning map_files.

If I do "ls -l /proc/self/map_files" I get the link name and link content.
While I can't open /proc/self/map_files/7fbde0c3200-7fbde0c3300 I can read
that it points to /usr/lib64/ld-2.30.so, which is something I can open 
and read. Sure, it's an extra step, but it's no big deal. It does raise the
question of what value comes from disallowing open via the symlink.





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