From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from thejh.net ([37.221.195.125]:48319 "EHLO thejh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752839AbcIWVeA (ORCPT ); Fri, 23 Sep 2016 17:34:00 -0400 Date: Fri, 23 Sep 2016 23:33:56 +0200 From: Jann Horn To: Andy Lutomirski Cc: Alexander Viro , Roland McGrath , Oleg Nesterov , John Johansen , James Morris , "Serge E. Hallyn" , Paul Moore , Stephen Smalley , Eric Paris , Casey Schaufler , Kees Cook , Andrew Morton , Janis Danisevskis , Seth Forshee , "Eric . Biederman" , Thomas Gleixner , Benjamin LaHaise , Ben Hutchings , Linus Torvalds , Linux FS Devel , LSM List , "security@kernel.org" Subject: Re: [PATCH v2 2/8] exec: turn self_exec_id into self_privunit Message-ID: <20160923213355.GB4763@pc.thejh.net> References: <1474663238-22134-1-git-send-email-jann@thejh.net> <1474663238-22134-3-git-send-email-jann@thejh.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 23, 2016 at 02:04:30PM -0700, Andy Lutomirski wrote: > On Fri, Sep 23, 2016 at 1:40 PM, Jann Horn wrote: > > This ensures that self_privunit ("privilege unit locally unique ID") > > is only shared by processes that share the mm_struct and the signal_str= uct; > > not just spatially, but also temporally. In other words, if you do exec= ve() > > or clone() without CLONE_THREAD, you get a new privunit that has never > > been used before. > > > > One reason for doing this is that it prevents an attacker from sending = an > > arbitrary signal to a parent process after performing 2^32-1 execve() > > calls. > > > > The second reason for this is that it permits using the self_exec_luid = in > > a later patch to check during a ptrace access whether subject and object > > are temporally and spatially equal for privilege checking purposes. > > > > The implementation of locally unique IDs is in sched.h and exec.c for n= ow > > because those are the only users so far - if anything else wants to use > > them in the future, they can be moved elsewhere. > > > > changed in v2: > > - have 2^64 IDs per CPU instead of 2^64 shared ones (luid scheme, > > suggested by Andy Lutomirski) > > - take task_lock for reading in setup_new_exec() while bumping the LUID > > > > Signed-off-by: Jann Horn > > --- > > fs/exec.c | 41 +++++++++++++++++++++++++++++++++++++++-- > > include/linux/sched.h | 17 +++++++++++++++-- > > kernel/fork.c | 5 +++-- > > kernel/signal.c | 5 ++++- > > 4 files changed, 61 insertions(+), 7 deletions(-) > > > > diff --git a/fs/exec.c b/fs/exec.c > > index 84430ee..fcc11f0 100644 > > --- a/fs/exec.c > > +++ b/fs/exec.c > > @@ -1281,6 +1281,34 @@ void would_dump(struct linux_binprm *bprm, struc= t file *file) > > } > > EXPORT_SYMBOL(would_dump); > > > > +static DEFINE_PER_CPU(u64, luid_counters); > > + > > +static int __init init_luid_counters(void) > > +{ > > + unsigned int cpu; > > + > > + for_each_possible_cpu(cpu) { > > + /* value 0 is reserved for init */ > > + per_cpu(luid_counters, cpu) =3D 1; > > + } > > + > > + return 0; > > +} > > +early_initcall(init_luid_counters); >=20 > How about static DEFINE_PER_CPU(u64, luid_counters) =3D 1? You could > optionally use local64_t instead, which would let you avoid needing to > think about preemption. Ah, I didn't realize that either of those was possible. Yes, I guess I'll change it to use local64_t. > > + > > +/* > > + * Allocates a new LUID and writes the allocated LUID to @out. > > + * This function must not be called from IRQ context. > > + */ > > +void fill_luid(struct luid *out) > > +{ > > + preempt_disable(); > > + out->count =3D raw_cpu_read(luid_counters); > > + raw_cpu_add(luid_counters, 1); > > + out->cpu =3D smp_processor_id(); > > + preempt_enable(); > > +} > > + >=20 > I would call this alloc_luid(). --lEGEL1/lMxI0MVQ2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJX5Z/DAAoJED4KNFJOeCOodeEQAJZZ6qgTOlWvhJ5xNBk2V+dD RofRKH0JvzgsYSZFxmT7R8AKzbSrXCvThRfFvg8OBKzPNoASJ3J9cTU2xBaqh4sF 8VjNEXUvgR0yukQNdLPibHNYKzbqRXkZpC2hAYTcJBJUqZO9+40NZJ8gEa+IS//1 jvcWPPVvqTOo5+fRQyhhaT9uF+LzbWrW1DwoBNaoo+S5SsJFlgTUJYutI/juhMMv fH0PBjygJ9QfezldVrUIlctxYGWuJLIriMwUjpY2yJ5ARaiG6j+nT11Y0sEoX1+T FLL42ROB1rfBqPbqddgUlSP2KXmQ9xC4QNuXiPUUejzT/w2j0G4g5IN/JDrNPtxk noU/VZLp6BF8v0MMbv83IagTxAR8xGaUfKjkNp0VNi+eMORsNijduLlMfdxsvNus 58pKmchCe4enL1wxg5fOTRrNi6s6nfyPFdMS9iy7yZuCIrnbYu5LpIgfLK1QYfuo 0jSSPrwp6exl7N2YzBSLkot9rRBGJpRqZ7WKzvUrVVD7QpuXRUqDtNxxbkWw6TaE Q5N44Ch61w+elBhyg1PZYqOnAEKPV3kdE5NY3eKhVYX7vDXGOaClQ9N1EMCm9HBk schTFXoy4TrNsFmKPaZhBGv0r1cnVdrLEAPUe1xglK/mBkRZXPO+NTHtRWRBksLk p++DTmcURFNUBfSuT4m/ =tqXM -----END PGP SIGNATURE----- --lEGEL1/lMxI0MVQ2--