Re: [PATCH 0/2] Add further ioctl() operations for namespace discovery

"Michael Kerrisk (man-pages)" [off-list ref] writes:

Hi Eric,

On 12/20/2016 09:22 PM, Eric W. Biederman wrote:

quoted

"Michael Kerrisk (man-pages)" [off-list ref] writes:

quoted

Hello Eric,

On 12/19/2016 11:53 PM, Eric W. Biederman wrote:

quoted

"Michael Kerrisk (man-pages)" [off-list ref] writes:

quoted

Eric,

The code proposed in this patch series is pretty small. Is there any
chance we could make the 4.10 merge window, if the changes seem
acceptable to you?

I see why you are asking but I am not comfortable with aiming for
the merge window that is on-going and could close at any moment.
I have seen recenly too many patches that should work fine have
some odd minor issue.  Like an extra _ in a label used in an ifdef
that resulted in memory stomps.    Linus might be more brave but i would
rather wait until the next merge window, so I don't need to worry about
spoiling anyone's holidays with a typo someone over looked.

I'll just gently ask if you'll reconsider and take another look at the
patches. They patches are very small, and don't change any existing
behavior. And if we see a problem in the next weeks they could be pulled.
In the meantime, I'd be aiming to publicize this API somewhat, so that we
might get some eyeballs to spot design bugs. But, I do understand your
position, if the answer is still "not for this merge window".

My position is still not this merge window.  I am more than happy to
queue up the changes for the next one.  Even on the best of days there
is a reasonable chance Linus would not be happy to receive code
development done in the merge window.

Okay. So, I can at least think about this at leisure! (Actually, 
I think I really do mean: thanks for saying "no" again.)

quoted

I think there is also just a little bit of discussion that needs

58 more quoted lines

Well over the target process but yes.

quoted

That will let the
LSMs and any future kerel changes have their say, without any extra
maintenance burden in the kernel.

Yes.

quoted

What I really don't want is for userspace to start depending on the
current formula being the only factors that say if it has a capabliltiy
in a certain situation because in practice that just isn't true.
Permission checks just keep evoloving in the kernel.

This was the bit I hadn't really considered when I first started down 
this path, but I started to see the light a bit already today, but
didn't have it so crisply in my mind as you just said it there.

So, we have two ioctls already in 4.9, I proposed two more. And 
then we have this fifth operation. Should we have an nsctl(2)?

I would rather move the other direction and have a system call.

In the meantime, here's something I hacked together. I know it
needs work, but I just want to check whether it's the direction
that you were meaning in terms of the checks. It's done as an
ioctl() (structure hard coded in place while I play about, and
some names and types should certainly be better). Leaving aside 
the messy bits, is the below roughly the kind of checking you 
expect to be embodied in this operation?

Yes.  It probably nees u32 instead of long, or eles we need to have
a compat version for 32bit OS's.

Now the question becomes who are the users of this?  Because it just
occurred to me that we now have an interesting complication.  Userspace
extending the meaning of the capability bits, and using to protect
additional things.  Ugh.  That could be a maintenance problem of another
flavor.  Definitely not my favorite.

The access system is limited to asking about yourself, and to
asking very specific questions.  If our new operation did something
similar and only allowed asking about yourself, and a capablity I would
find it less scary, and I am wondering if it would be possible to ask
not about a capability but an operation that the capability guards
such as chroot.

Implementing target operations instead of target capabilities would be a
bit trickier to implement (as it requires factoring out the permission
checks) but it may be much more useful in the long run.

So why are we asking the questions about what permissions a process has?

Eric

Hi Eric,

On 12/21/2016 01:17 AM, Eric W. Biederman wrote:

"Michael Kerrisk (man-pages)" [off-list ref] writes:

quoted

Hi Eric,

On 12/20/2016 09:22 PM, Eric W. Biederman wrote:

quoted

"Michael Kerrisk (man-pages)" [off-list ref] writes:

quoted

Hello Eric,

On 12/19/2016 11:53 PM, Eric W. Biederman wrote:

quoted

"Michael Kerrisk (man-pages)" [off-list ref] writes:

quoted

Eric,

[...]

quoted

quoted

quoted

3. NS_GET_NSTYPE and NS_GET_CREATOR_UID solve my problem, but
   obviously your idea would make life simpler for user space.
   Am I correct to understand that you mean an API that takes
   three pieces of info: a PID, a capability, and an fd referring
   to a /proc/PID/ns/xxx, and tells us whether PID has the specified
   capability for operations in the specified namespace?

Something like that.  But yes something we can wire up to
ns_capable_noaudit and be told the result.  

Yes, that was my line of thinking also. It seems to me that to
prevent information leaks, we also should check that the caller
has some suitable capability in the target namespace, right?
(I presume a ptrace_may_access() check.)

Well over the target process but yes.

quoted

quoted

That will let the
LSMs and any future kerel changes have their say, without any extra
maintenance burden in the kernel.

Yes.

quoted

What I really don't want is for userspace to start depending on the
current formula being the only factors that say if it has a capabliltiy
in a certain situation because in practice that just isn't true.
Permission checks just keep evoloving in the kernel.

This was the bit I hadn't really considered when I first started down 
this path, but I started to see the light a bit already today, but
didn't have it so crisply in my mind as you just said it there.

So, we have two ioctls already in 4.9, I proposed two more. And 
then we have this fifth operation. Should we have an nsctl(2)?

I would rather move the other direction and have a system call.

Okay -- I'll give that a some thought.

quoted

In the meantime, here's something I hacked together. I know it
needs work, but I just want to check whether it's the direction
that you were meaning in terms of the checks. It's done as an
ioctl() (structure hard coded in place while I play about, and
some names and types should certainly be better). Leaving aside 
the messy bits, is the below roughly the kind of checking you 
expect to be embodied in this operation?

Yes.  It probably nees u32 instead of long, or eles we need to have
a compat version for 32bit OS's.

Yes.

Now the question becomes who are the users of this?  Because it just
occurred to me that we now have an interesting complication.  Userspace
extending the meaning of the capability bits, and using to protect
additional things.  Ugh.  That could be a maintenance problem of another
flavor.  Definitely not my favorite.

I don't follow you here. Could you say some more about what you mean?

The access system is limited to asking about yourself, and to
asking very specific questions.  If our new operation did something
similar and only allowed asking about yourself, and a capablity I would
find it less scary, 

Okay. But that's a less interesting operation from my point of view.
I mean: one way of knowing if we have permission to do an operation
is to try to do it.

and I am wondering if it would be possible to ask
not about a capability but an operation that the capability guards
such as chroot.

Implementing target operations instead of target capabilities would be a
bit trickier to implement (as it requires factoring out the permission
checks) but it may be much more useful in the long run.

But, would this not mean factoring out the permission checks on a per 
operation basis? (There are of courses hundreds of such checks.)

So why are we asking the questions about what permissions a process has?

My main interest here is monitoring/discovery/debugging on a running
system. NS_GET_PARENT, NS_GET_USERNS, NS_GET_CREATOR_UID, and 
NS_GET_NSTYPE provide most of what I'd like to see. Being able to ask
"does this process have permissions in that namespace?" would be nice 
to have in terms of understanding/debugging a system.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/