Hi Eric, On 12/21/2016 01:17 AM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: > >> Hi Eric, >> >> On 12/20/2016 09:22 PM, Eric W. Biederman wrote: >>> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: >>> >>>> Hello Eric, >>>> >>>> On 12/19/2016 11:53 PM, Eric W. Biederman wrote: >>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: >>>>> >>>>>> Eric, [...] >>>> 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. > >>> That will let the >>> LSMs and any future kerel changes have their say, without any extra >>> maintenance burden in the kernel. >> >> Yes. >> >>> 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. >> 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
