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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1484297111.2197.1.camel@nonadev.net>
Date:   Fri, 13 Jan 2017 09:45:11 +0100
From:   José Bollo <jobol@...adev.net>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [RFC DRAFT] Adds PUI: process unic identifier

On Thu, 2017-01-12 at 19:33 +0900, Tetsuo Handa wrote:
> 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.

Hi Tetsuo-san,

Thank you for your review.  It helps a lot! 

After reading about the possible use of real_start_time, I was
wondering if using a kind of clock+pid(ns) would be able to replace
at lower resource cost what I proposed. That leads to use of 128 bits
puids but without changing anything in {pid,pid_namespace}.[ch]. Great!
But I still have to check.

I wanted to get advices first so I didn't sent the fs part of pui
because it is not still existing. This fs part will allow access to
task by their pui.

I'll probably send an update in a month or more.

Best regards
José Bollo