linux-kernel - Re: [PATCH 4/8] user ns: hook permission

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]

Message-ID: <m14pqg2w3o.fsf@ebiederm.dsl.xmission.com>
Date:	Wed, 24 Jan 2007 10:06:03 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	lkml <linux-kernel@...r.kernel.org>, containers@...ts.osdl.org,
	Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH 4/8] user ns: hook permission

"Serge E. Hallyn" <serue@...ibm.com> writes:

> From: Serge E. Hallyn <serue@...ibm.com>
> Subject: [PATCH 4/8] user ns: hook permission
>
> Hook permission to check vfsmnt->user_ns against current.

This looks wrong on several levels.
- This should ultimately be inside generic_permission instead of
  permission as there are some distributed filesystems that know how to cope with
  multiple mount namespaces simultaneous.

- As implemented the test is not what I would expect.  I would
  expect comparisons of uid X == uid Y and gid X == gid Y to
  be replaced by comparing the tuples of uid namesspace and uid.
  Which would allow access to world readable/writeable files,
  and it would allow users with CAP_DAC_OVERRIDE to be able to access
  everything.

All we are really saying as I understand a user namespace is that 
instead of uid's uniquely identifying a user the pair the pair uidns,
uid is uniquely identifies a user.

Because you didn't pick what I would consider the obvious choice
you now need an extra mount flag to disable the uid namespace all
together, so you can transition through the intermediate uid namespace
state.  That really feels wrong.

All mounts should have an associated uid namespace and the only
way you should be able to ignore that is to access filesystems
that can cope with multiple uid namespaces simultaneously.

Eric
-
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/