Hello Jann,

Thanks for your comments. Sorry for the delayed follow-up...

On 04/16/2018 04:10 PM, Jann Horn wrote:

On Fri, Apr 13, 2018 at 9:26 PM, Michael Kerrisk (man-pages)
[off-list ref] wrote:

quoted

Hello Serge, Jann,

On 01/16/2018 06:26 PM, Jann Horn wrote:

quoted

On Tue, Jan 9, 2018 at 7:52 PM, Serge E. Hallyn [off-list ref] wrote:

[...]

quoted

       Starting  with  Linux  4.14,  a  security.capability   extended
       attribute  is automatically created as (or converted to) a ver?
       sion 3 (VFS_CAP_REVISION_3) attribute if both of the  following
       are true:

       (1) The  thread  writing  the attribute resides in a noninitial
           namespace.

I'm not entirely happy with this - while under most circumstances
(especially nowadays) correct, isn't this going to confuse readers who
want to understand the actual rules?

So, you mean that the text should read more likely the parenthesized 
part that follows:

quoted

           (More precisely: the thread resides in  a  user
           namespace  other  than  the  one  from which the underlying
           filesystem was mounted.)

?

I think if you're in a parent namespace of the user namespace that
mounted the filesystem, you actually can write a VFS_CAP_REVISION_2
attribute?

I'm not quite clear. Do you mean this as some correction to my text?
Let me see if I grasp your meaning:

(0) First of all, as things currently stand, filesystems can be
    mounted only in the initial user NS (which has no parent). But,
    this will change in the future, according to current work on FUSE.
    Your comment here related to that future. (Right?)

(1) You mean that a process in the parent user NS could write
    (setxattr(2)) a VFS_CAP_REVISION_2 attribute, but what would 
    actually be recorded is a VFS_CAP_REVISION_3 attribute?

quoted

       (2) The thread has the CAP_SETFCAP  capability  over  the  file
           inode,  meaning  that  (a)  the  thread has the CAP_SETFCAP
           capability in its own user namespace; and (b) the  UID  and
           GID  of  the  file inode have mappings in the writer's user
           namespace.

quoted

           ???????????????????????????????????????????????????????
           ?FIXME                                                ?
           ???????????????????????????????????????????????????????
           ?Does there also need to be some kind  of  credential ?
           ?match  between  the  file  and the namespace creator ?
           ?UID?                                                 ?
           ???????????????????????????????????????????????????????

The namespace creator UID (iow, the namespace owner) is irrelevant
here; the capability model is somewhat inconsistent here. Normal
capability checks that go down to cap_capable() (like ns_capable())
grant all privileges to processes in parent namespaces that have an
EUID that matches the owner UID of one of the intermediate namespaces,
including the target namespace. But capable_wrt_inode_uidgid() always
requires the caller to have the specified capability in its own
namespace because, when operating on an inode, the concept of an
implicit "target namespace" doesn't really exist. (For a properly
consistent model, you'd probably need to let the caller explicity
specify the target namespace, but then that would somewhat break the
transparency of namespaces.) cap_convert_nscap() starts by checking
for capable_wrt_inode_uidgid().

Okay -- I think I got this a little twisted. The point here, as far
as I can see, is that there is a credential check involved. The rule
is that from inside the user NS, you can set a VFS_CAP_REVISION_3
only on a file whose (mapped) UID matches the UID 0 of the namespace.
Have I got that right?

[...]

quoted

       As with a binary that has VFS_CAP_REVISION_2 file capabilities,
       a  binary  with  VFS_CAP_REVISION_3  file  capabilities confers
       capabilities to a process during execve().  However,  capabili?
       ties  are conferred only if the binary is executed by a process
       that resides in a user namespace whose UID 0 maps to  the  root
       user  ID  that is saved in the extended attribute, or when exe?
       cuted by a process that resides in descendant of such a  names?

Nit: "in a descendant"?

Thanks. Fixed.

[...]

quoted

quoted

quoted

Likewise,
+.BR getxattr(2)
+results will be converted and simplified to show a VFS_CAP_REVISION_2
+extended attribute, if a VFS_CAP_REVISION_3 applies to the caller's
+namespace, or to map the VFS_CAP_REVISION_3 root user ID into the
+caller's namespace.

I haven't captured that last paragraph in my text. I'm not sure I
understand the idea being presented. Serge, could you elaborate?

Summary: When you read a capability attribute with getxattr(), the
kernel will rewrite the returned value such that it looks the way it
would have to look if the filesystem was mounted in your user
namespace; just like how, when the attribute is written, the caller
provides an attribute value written as if the filesystem was mounted
in the caller's user namespace.
Conceptually, this is mostly the same as the UID conversions applied
by chown() and stat().

Okay -- thanks. I got this now. I'll work some text into the page.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html