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

Ruslan Kuprieiev kupruser at gmail.com
Thu Jun 19 04:27:51 PDT 2014


On 19.06.2014 14:11, Pavel Emelyanov wrote:
> On 06/19/2014 02:54 PM, Ruslan Kuprieiev wrote:
>> On 19.06.2014 13:50, Pavel Emelyanov wrote:
>>> 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.
>> Oh, now I see.
>>
>>>> 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.
>> So, how about additional groups checking?
> Yes, I agree. Additional groups are to be checked as well. But anyway,
> the rule of a thumb from my perspective is -- if a user, that asks to
> restore from images that fully belong to root and can _not_ modify them
> -- restore is allowed w/o any restrictions.

I agree too. So, for now, will introduce imgs checking and ability
to restore any good images without restrictions. For bad ones - will 
leave current
check for now. And then will introduce additional groups checking.

Btw, when all from the above will be completed, why not make 
images/logs/pidfiles
to be owned by current user? It looks right to me. That being said it 
wasn't
requested by anyone for some practical usage.

>
> Thanks,
> Pavel



More information about the CRIU mailing list