lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 1 Sep 2017 10:30:31 -0700
From:   Prakash Sangappa <prakash.sangappa@...cle.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, drepper@...hat.com
Subject: Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS
 without CAP_SYS_ADMIN



On 8/30/17 10:41 AM, ebiederm@...ssion.com wrote:
> Prakash Sangappa <prakash.sangappa@...cle.com> writes:
>
>
>> With regards to security, the question basically is what is the consequence
>> of passing the wrong id. As I understand it, Interpreting the id to be pid
>> or tid, the effective uid and gid will be the same. It would be a problem
>> only if the incorrect interpretation of the id would refer a different process.
>> But that cannot happen as the the global tid(gettid() of a thread is
>> unique.
> There is also the issue that the receiving process could look, not see
> the pid in proc and assume the sending process is dead.  That I suspect
> is the larger danger.
>

Will this not be a bug in the application, if it is sending the wrong id?

>> As long as the thread is alive, that id cannot reference another process / thread.
>> Unless the thread were to exit and the id gets recycled and got used for another
>> thread or process. This would be no different from a process exiting and its
>> pid getting recycled which is the case now.
> Largely I agree.
>
> If all you want are pid translations I suspect the are far easier ways
> thant updating the SCM_CREDENTIALS code.

What would be an another easier & efficient way of doing pid translation?

Should a new API/mechanism be considered mainly for pid translation purpose
for use with pid namespaces, say based on 'pipe' something similar to 
I_SENDFD?

Thanks,
-Prakash.

> Eric
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ