[CRIU] [PATCH] security: check_ids - return true if [se]?[ug]id is the same as task id

Pavel Emelyanov xemul at parallels.com
Thu Jun 19 03:50:43 PDT 2014


On 06/19/2014 05:06 AM, Ruslan Kuprieiev wrote:
> After a bit more thinking I don't like the idea of checking owner and 
> perms at all.
> And I think we should create images with owner == current user.
> Let me explain why.
> Lets imagine, I'm a developer of, for example, a game, who wants to save by
> dumping and load by restoring( well, why not?=) ). I want to be able to 
> delete some old saves, but currently i'm not able, because images are 
> owned by root and
> perms == 0644.
> Playing the game as root isn't cool =).

Removing a file doesn't requite _it_ to be writable. It requires
directory the files are in to be such.

> Still, there is a bug, when one can't dump/restore process which 
> r/e/sgid doesn't
> match user crgid. crgid is primary group of the user and if it doesn't 
> match sgid
> it doesn't mean that user isn't in additional group sgid.
> So, it looks like we should divide uid and gid checking. For gid 
> checking we should
> compare crgid with additional groups of the user.
> 
> On 17.06.2014 17:25, Pavel Emelyanov wrote:
>> On 06/17/2014 06:18 PM, Ruslan Kuprieiev wrote:
>>> ~snip~
>>> So, just to be sure that I get it right. Here is the plan:
>>> -- make criu create images with rw-r--r-- perms owned by root
>>> -- on restore, make sure that images are rw-r--r-- and owned by root, and if
>>>       smth wrong, don't allow non-root to restore
>> No, don't allow restoration of "extended prio" like changed xids and
>> non zero caps.
>>
>>> -- use that check from kill_ok_by_creds to determine whether or not
>>> non-root user
>>>       is allowed to dump/restore
>> No, regular user cannot change to another user or raise its caps by
>> changing images. This has nothing to do with kill_ok_by_creds.
>>
>> Thanks,
>> Pavel
> 
> .
> 




More information about the CRIU mailing list