Re: [RFC PATCH 00/27] Containers and using authenticated filesystems

2019-02-20 Thread Steve French
On Tue, Feb 19, 2019 at 5:42 PM David Howells  wrote:
>
> Eric W. Biederman  wrote:
>
> > So you missed the main mailing lists for discussion of this kind of
> > thing
>
> Yeah, sorry about that.  I was primarily aiming it at Trond and Steve as I'd
> like to consider how to go about interpolating request_key() into NFS and CIFS
> so that they can make use of the key-related facilities that this makes
> available with AFS.

I am interested in this discussion because I have gotten various questions
about using Containers better on SMB3 mounts, and the question about
doing request_key better comes up **a lot** on SMB3 mounts (not just
for kerberos, Active Directory), and usability could be improved of some
of the cifs-utils that cifs.ko depends on.

Note that various virtualization/container identify features were added to the
protocol a few years ago (which we don't yet implement in Linux) but which
probably be **very** useful to followup on how these could be exposed
to help containers on network mounts in Linux.See in particular this
new protocol feature (implemented by various servers including Windows
but not by Linux client yet) described in the protocol spec (MS-SMB2 section
2.2.9.2.1) - the "SMB2_REMOTED_IDENTITY_TREE_CONNECT context"
which can be sent at mount time:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/ee7ff411-93e0-484f-9f73-31916fee4cb8

This may be of interest to Samba server developers as well

> > and the maintainer.
>
> That would be me.  I maintain keyrings.


-- 
Thanks,

Steve


Re: [RFC PATCH 00/27] Containers and using authenticated filesystems

2019-02-20 Thread Christian Brauner
On Tue, Feb 19, 2019 at 10:35:20AM -0600, Eric W. Biederman wrote:
> 
> So you missed the main mailing lists for discussion of this kind of
> thing, and the maintainer.  So I have reservations about the quality of
> your due diligence already.
> 
> Looking at your description you are introducing a container id.
> You don't descibe which namespace your contianer id lives in.
> Without the container id living in a container this breaks
> nested containers and process migration aka CRIU.
> 
> So based on the your description.
> 
> Nacked-by: "Eric W. Biederman" 
> 
> 
> 
> David Howells  writes:
> 
> > Here's a collection of patches that containerises the kernel keys and makes
> > it possible to separate keys by namespace.  This can be extended to any
> > filesystem that uses request_key() to obtain the pertinent authentication
> > token on entry to VFS or socket methods.

/me puts on kernel hat:
I'm not neccessarily opposed to making containers kernel objects even
though I have been for quite a while (for brevity I'll use "kcontainers"
for this). But I think the approach taken here is a little misguided.
This patchsets pushes the argument that kcontainers are needed because
of keyrings and authenticated filesystems and is designed around this
use-case. Imho, that is bound to fall short of requirements and
use-cases that have been piling up over the years.
If we want to make kcontainers a thing we need to have a separate
discussion and a separate patchset that is *solely* concerned with
creating a kcontainer api. And frankly, that is likely going to take a
long time.
At this point containers have become a real "thing" on Linux - like it
or not. So justifying it to making them in-kernel citizens doesn't need
the detour over keyrings or something else. We should just discuss
whether we think that the benefits of kcontainers (e.g. security)
outweight the costs (e.g. maintenance).

/me puts on runtime maintainer hat:
One thing that is true is that userspace containers (let's call them
"ucontainers") as implemented by runtimes today will not go away. We
have been living with this ad-hoc concept and it's various
implementations on upstream Linux at least since 2008. And kernels
without kcontainers will be with us until the end of (Linux)time
probably. So anyone who thinks that kcontainers will replace ucontainers
and that'll be it will be thoroughly disappointed in the end.
It is also very likely that not all use-cases we can currently cover
with ucontainers can be covered by kcontainers. Now that might be ok but
if we ever introduce kcontainers through a proper kernel api we will end
up maintaining ucontainers and kcontainers simultaneously. That's a
burden we shouldn't underestimate.


Re: [RFC PATCH 00/27] Containers and using authenticated filesystems

2019-02-19 Thread Paul Moore
On Tue, Feb 19, 2019 at 6:42 PM David Howells  wrote:
> Eric W. Biederman  wrote:

...

> > Looking at your description you are introducing a container id.
>
> Yes.  For audit logging, which was why I cc'd Richard.

Not to pile on, but it is more important to CC the audit mailing list.
You can obviously still CC Richard, but you should send it to the
entire mailing list.

-- 
paul moore
www.paul-moore.com


Re: [RFC PATCH 00/27] Containers and using authenticated filesystems

2019-02-19 Thread David Howells
Eric W. Biederman  wrote:

> So you missed the main mailing lists for discussion of this kind of
> thing

Yeah, sorry about that.  I was primarily aiming it at Trond and Steve as I'd
like to consider how to go about interpolating request_key() into NFS and CIFS
so that they can make use of the key-related facilities that this makes
available with AFS.  And I was in a bit tight for time to mail it out before
having to go out.  I know, excuses... ;-)

> and the maintainer.

That would be me.  I maintain keyrings.

No one is listed in MAINTAINERS as owning namespaces.  If you feel that should
be you, please add a record.

> Looking at your description you are introducing a container id.

Yes.  For audit logging, which was why I cc'd Richard.

> You don't descibe which namespace your contianer id lives in.

It doesn't.  Not everything has to have a namespace.  As you yourself pointed
out, it should be globally unique, in which case the world is the namespace,
maybe even the universe;-).

> Without the container id living in a container this breaks
> nested containers and process migration aka CRIU.

As long as IDs are globally unique, why should break container migration?
Having a kernel container object might even make CRIU easier.

And what does "Without the container id living in a container" mean anyway?  I
have IDs attached to containers.  A container can see the IDs of its child
containers.  There should be no problem with nesting.

David


Re: [RFC PATCH 00/27] Containers and using authenticated filesystems

2019-02-19 Thread Eric W. Biederman


So you missed the main mailing lists for discussion of this kind of
thing, and the maintainer.  So I have reservations about the quality of
your due diligence already.

Looking at your description you are introducing a container id.
You don't descibe which namespace your contianer id lives in.
Without the container id living in a container this breaks
nested containers and process migration aka CRIU.

So based on the your description.

Nacked-by: "Eric W. Biederman" 



David Howells  writes:

> Here's a collection of patches that containerises the kernel keys and makes
> it possible to separate keys by namespace.  This can be extended to any
> filesystem that uses request_key() to obtain the pertinent authentication
> token on entry to VFS or socket methods.
>
> I have this working with AFS and AF_RXRPC so far, but it could be extended
> to other filesystems, such as NFS and CIFS.
>
> The following changes are made:
>
>  (1) Add optional namespace tags to a key's index_key.  This allows the
>  following:
>
>  (a) Automatic invalidation of all keys with that tag when the
>namespace is removed.
>
>  (b) Mixing of keys with the same description, but different areas of
>operation within a keyring.
>
>  (c) Sharing of cache keyrings, such as the DNS lookup cache.
>
>  (d) Diversion of upcalls based on namespace criteria.
>
>  (2) Provide each network namespace with a tag that can be used with (1).
>  This is used by the DNS query, rxrpc, nfs idmapper keys.
>
>  [!] Note that it might still be better to move these keyrings into the
>network namespace.
>
>  (3) Provide key ACLs.  These allow:
>
>  (a) The permissions can be split more finely, in particular separating
>out Invalidate and Join.
>
>  (b) Permits to be granted to non-standard subjects.  So, for instance,
>Search permission could be granted to a container object, allowing
>a search of the container keyring by a denizen of the container to
>find a key that they can't otherwise see.
>
>  (4) Provide a kernel container object.  Currently, this is created with a
>  system call and passed flags that indicate the namespaces to be
>  inherited or replaced.  It might be better to actually use something
>  like fsconfig() to configure the container by setting key=val type
>  options.
>
>  The kernel container object provides the following facilities:
>
>  (a) request_key upcall interception.  The manager of a container can
>intercept requests made inside the container and, using a series
>of filters, can cause the authkeys to be placed into keyrings that
>serve as queues for one or more upcall processing programs.  These
>upcall programs use key notifications to monitor those keyrings.
>
>  (b) Per-container keyring.  A keyring can be attached to the container
>such that this is searched by a request_key() performed by a
>denizen of the container after searching the thread, process and
>session keyrings.  The keyring and the keys contained therein must
>be granted Search for that container.
>
>This allows:
>
>(i) Authenticated filesystems to be used transparently inside of
>the container without any cooperation from the occupant
>thereof.  All the key maintenance can be done by the manager.
>
>  (ii) Keys to be made available to the denizens of a container (by
>  granting extra permissions to the container subject).
>
>  (c) Per-container ID that can be used in audit messages.
>
>  (d) Container object creation gives the manager a file descriptor that
>can:
>
>(i) Be passed to a dirfd parameter to a VFS syscall, such as
>mkdirat(), allowing an operation to be done inside the
>container.
>
>  (ii) Be passed to fsopen()/fsconfig() to indicate that the target
>  filesystem is going to be created inside a container, in that
>  container's namespaces.
>
>  (iii) Be passed to the move_mount() syscall as a destination for
>  setting the root filesystem inside a new mount namespace made
>  upon container creation.
>
>  (e) The ability to configure the container with namespaces or
>whatever, and then fork a process into that container to 'boot'
>it.
>
>
> Three sample programs are provided:
>
>  (1) test-container.  This:
>
>   - Creates a kernel container with a blank mount ns.
>   - Creates its root mount and moves it to the container root.
>   - Mounts /proc therein.
>   - Creates a keyring called "_container"
> - Sets that as the container keyring.
> - Grants Search permission to the container on that keyring.
> - Removes owner permission on that keyring.
>   - Creates a sample user key "foobar" in the container keyring.
> - Grants various 

Re: [RFC PATCH 00/27] Containers and using authenticated filesystems

2019-02-15 Thread James Morris
On Fri, 15 Feb 2019, David Howells wrote:

> 
> Here's a collection of patches that containerises the kernel keys and makes
> it possible to separate keys by namespace.  This can be extended to any
> filesystem that uses request_key() to obtain the pertinent authentication
> token on entry to VFS or socket methods.

Shouldn't Eric Biederman be cc'd on this?

-- 
James Morris




[RFC PATCH 00/27] Containers and using authenticated filesystems

2019-02-15 Thread David Howells


Here's a collection of patches that containerises the kernel keys and makes
it possible to separate keys by namespace.  This can be extended to any
filesystem that uses request_key() to obtain the pertinent authentication
token on entry to VFS or socket methods.

I have this working with AFS and AF_RXRPC so far, but it could be extended
to other filesystems, such as NFS and CIFS.

The following changes are made:

 (1) Add optional namespace tags to a key's index_key.  This allows the
 following:

 (a) Automatic invalidation of all keys with that tag when the
 namespace is removed.

 (b) Mixing of keys with the same description, but different areas of
 operation within a keyring.

 (c) Sharing of cache keyrings, such as the DNS lookup cache.

 (d) Diversion of upcalls based on namespace criteria.

 (2) Provide each network namespace with a tag that can be used with (1).
 This is used by the DNS query, rxrpc, nfs idmapper keys.

 [!] Note that it might still be better to move these keyrings into the
 network namespace.

 (3) Provide key ACLs.  These allow:

 (a) The permissions can be split more finely, in particular separating
 out Invalidate and Join.

 (b) Permits to be granted to non-standard subjects.  So, for instance,
 Search permission could be granted to a container object, allowing
 a search of the container keyring by a denizen of the container to
 find a key that they can't otherwise see.

 (4) Provide a kernel container object.  Currently, this is created with a
 system call and passed flags that indicate the namespaces to be
 inherited or replaced.  It might be better to actually use something
 like fsconfig() to configure the container by setting key=val type
 options.

 The kernel container object provides the following facilities:

 (a) request_key upcall interception.  The manager of a container can
 intercept requests made inside the container and, using a series
 of filters, can cause the authkeys to be placed into keyrings that
 serve as queues for one or more upcall processing programs.  These
 upcall programs use key notifications to monitor those keyrings.

 (b) Per-container keyring.  A keyring can be attached to the container
 such that this is searched by a request_key() performed by a
 denizen of the container after searching the thread, process and
 session keyrings.  The keyring and the keys contained therein must
 be granted Search for that container.

 This allows:

 (i) Authenticated filesystems to be used transparently inside of
 the container without any cooperation from the occupant
 thereof.  All the key maintenance can be done by the manager.

 (ii) Keys to be made available to the denizens of a container (by
 granting extra permissions to the container subject).

 (c) Per-container ID that can be used in audit messages.

 (d) Container object creation gives the manager a file descriptor that
 can:

 (i) Be passed to a dirfd parameter to a VFS syscall, such as
 mkdirat(), allowing an operation to be done inside the
 container.

 (ii) Be passed to fsopen()/fsconfig() to indicate that the target
 filesystem is going to be created inside a container, in that
 container's namespaces.

 (iii) Be passed to the move_mount() syscall as a destination for
 setting the root filesystem inside a new mount namespace made
 upon container creation.

 (e) The ability to configure the container with namespaces or
 whatever, and then fork a process into that container to 'boot'
 it.


Three sample programs are provided:

 (1) test-container.  This:

- Creates a kernel container with a blank mount ns.
- Creates its root mount and moves it to the container root.
- Mounts /proc therein.
- Creates a keyring called "_container"
  - Sets that as the container keyring.
  - Grants Search permission to the container on that keyring.
  - Removes owner permission on that keyring.
- Creates a sample user key "foobar" in the container keyring.
  - Grants various permissions to the container on that key.
- Creates a keyring called "upcall"
  - Intercepts "user" key upcalls from the container to there.
- Forks a process into the container
  - Prints the container keyring ID if it can
  - Exec's bash.

 This program expects to be given the device name for a partition it
 can mount as the root and expects it to contain things like /etc,
 /bin, /sbin, /lib, /usr containing programs that can be run and /proc
 to mount procfs upon.  E.g.:

./test-container /dev/sda3

 (2) test-upcall.  This is a service