linux-kernel - Re: [patch 0/3] add rt_tgsigqueueinfo syscall [RESEND]

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]

Message-Id: <20090227000352.7D32BFC339@magilla.sf.frob.com>
Date:	Thu, 26 Feb 2009 16:03:52 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	mtk.manpages@...il.com
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...sign.ru>, Ingo Molnar <mingo@...e.hu>,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	Linux API <linux-api@...r.kernel.org>
Subject: Re: [patch 0/3] add rt_tgsigqueueinfo syscall [RESEND]

I don't see any rationale for rt_tgsigqueueinfo and rt_sigqueueinfo to
differ in their treatment of si_pid/si_uid (whatever that is).  It just
seems like common sense that they would match.

Oleg and/or Sukadev have some patches floating around (maybe all in -mm?)
that relate to setting those.

I notice that POSIX says that si_pid and si_uid have reliable values
whenever si_code <= 0 (what we call SI_FROMUSER() in asm/siginfo.h).
(POSIX only has sigqueue() and kill() et al to send these, so a POSIX
application never explicitly supplies the values.  libc/libpthread do.
The {t,tg,}kill syscalls all set si_pid to tgid already.)
This means a POSIX-conformant application might check si_pid and si_uid and
rely on them not being forged by some other process/user.  Firstly this
means that si_pid must be the POSIX PID, i.e. tgid, not the Linux TID
(which is not a useful value in POSIX interfaces).  Secondly it means the
kernel should guarantee the correctness of these values (at least when
crossing processes, might as well do always).

I don't recall if the pending changes already use tgid, I think they do.

I think what both calls should do is set si_pid to tgid and si_uid to uid
whenever SI_FROMUSER().  This satisfies the POSIX and security trust
concern, and makes them uniform.  (In Sukadev's version, what si_pid value
they fill in here depends on pid_ns details of sender and recipient.)

Vis a vis Sukadev's changes, I also notice that si_uid ought to be
translated for the recipient user_ns.

Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/