linux-kernel - Re: [RFC DRAFT] Adds PUI: process unic identifier

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 12 Jan 2017 19:33:22 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:     jobol@...adev.net
Cc:     linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [RFC DRAFT] Adds PUI: process unic identifier

Jose Bollo wrote:
> Hi all,
> 
> I'd like to get your feeling about the idea
> exposed in that draft. Should continue or stop
> immediately? Is there already some existing work?
> How is the taken approach?
> 
> BR - Jose Bollo
> 
> [RFC DRAFT] Adds PUI: process unic identifier
> 
> The name 'pui' is choosen -instead of puid-
> to avoid confusion with either pid and uid.
> It is intended to identify uniquely each
> activated task item, accordling to namespaces.
> 
> 64 bits seems to be a good deal for beginning.
> The count of second in a year is less than 2^25.
> So if a huge machine is able to create 2^31 processes
> per second (ex: 2^7 cores, each creating 2^24 processes
> -a nighmare-), then the unic id is over in 2^8 years.
> Far more than what a regular system upgrade needs.
> 
> The pui is represented as a hexadecimal value because
> it is much more efficient.

Firstly, please explain the motivation why you need process unique
identifier that is really unique. This patch involves userspace visible
changes but not everybody is aware of what your PTAGS wants to do.

Secondly, please describe how userspace processes use process unique
identifier. This patch adds "Pui:" line and "NSpui:" line to
/proc/$pid/status and SO_PEERPUI option to getsockopt(), but nothing else.
Why these lines and option are needed and why they are sufficient?

There is start_time field ("struct task_struct"->real_start_time)
in /proc/$pid/stat which is already almost unique. Even if userspace
processes use both $pid and start_time for identifying a process, is it
unreliable? If userspace processes use both "struct task_struct"->pid
and "struct task_struct"->real_start_time for identifying a process,
is it still unreliable? I wonder why find_pui_ns() needs to be aware of
CONFIG_PID_NS. How userspace processes use process unique identifier for
identifying a "struct task_struct"?

There are %Lu %Ld %Lx %LX kstrtoull() kstrtoll() for converting
string to 64bit integer, and %llu %lld %llx %llX for converting
64bit integer to string. You don't need to redefine 64bit types
using typedef keyword.