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

Ruslan Kuprieiev kupruser at gmail.com
Wed Jun 18 18:51:20 PDT 2014


On 19.06.2014 04:06, 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 =).
>

Btw, is criu able to damage a system by restoring bad images(non-root and
without caps)?

> 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