[CRIU] [PATCH] security: check additional groups
Ruslan Kuprieiev
kupruser at gmail.com
Wed Jul 2 05:21:29 PDT 2014
On 02.07.2014 15:17, Ruslan Kuprieiev wrote:
> On 02.07.2014 14:58, Pavel Emelyanov wrote:
>>> -void restrict_uid(unsigned int uid, unsigned int gid)
>>> +int restrict_uid(unsigned int uid, unsigned int gid)
>>> {
>>> - pr_info("Restrict C/R with %u:%u uid\n", uid, gid);
>>> + struct passwd *pwd;
>>> + unsigned int buf[NGROUPS_MAX];
>>> + int nbuf;
>>> +
>>> + pr_info("Restrict C/R with %u:%u uid:gid\n", uid, gid);
>>> cr_uid = uid;
>>> cr_gid = gid;
>>> +
>>> + pwd = getpwuid(uid);
>>> + if (!pwd) {
>>> + pr_perror("Can't get password file entry");
>>> + return -1;
>>> + }
>>> +
>>> + nbuf = NGROUPS_MAX;
>>> + if (getgrouplist(pwd->pw_name, pwd->pw_gid, buf, &nbuf) < 0) {
>> There's no need in getting the caller's groups. It's enough just
>> to check the group it currently lives in.
>
> User's current group may not match all gids of the process. Just as it
> was with
> that game. When user's group was 1000, but process had (1000,20,20).
>
Oh, are you suggesting to check that process grouplist contains caller's
gid?
> And we should check that user isn't restoring process which has more
> groups
> than user already has, shouldn't we?
>
>>> + pr_perror("Can't get group list");
>>> + return -1;
>>> + }
>>> +
>>> + cr_ngroups = nbuf;
>>> + cr_groups = xmalloc(cr_ngroups*sizeof(*cr_groups));
>>> + if (!cr_groups)
>>> + return -1;
>>> +
>>> + memcpy(cr_groups, buf, cr_ngroups*sizeof(*cr_groups));
>>> +
>>> + return 0;
>>> }
>
More information about the CRIU
mailing list