On Mon, Dec 10, 2012 at 6:59 AM, Serge Hallyn <serge.hal...@canonical.com> wrote: > Quoting Andy Lutomirski (l...@amacapital.net): >> It's especially bad because granting CAP_DAC_READ_SEARCH to user "foo" >> doesn't mean anything. Is he authorized to back things up to >> encrypted storage? > > We're talking about privileges at the kernel level here, and there is > no way this could be expressed at that level. > > Higher level tools could/should certainly be exposing things at this > level.
Agreed, although selinux tries to allow this kind of detail in the kernel. I don't think capabilities should move in that direction. > > BUT > > You *are* doing a good job of making me feel that we should have > per-user fI xattrs or acls. Sudo is popular because people like to say > "user joe can run foo with privilege". Most people will never want to > be bothered to say "user joe can run foo with CAP_XYZ" (versus "as > root"), but I do think we could get programs/packages to do that. Hmm. I wish I was doing as good a job convincing myself that I know a good solution. I don't actually consider the fact that pI has insufficient granularity to be a problem in need of fixing. I think userspace can take care of detailed authorization questions on its own. I think the problem is that pI is failing to allow users who aren't root (or at least aren't uid=0) to have elevated, but not completely elevated, privilege. (If you don't like "users" in that sentence, feel free to replace it with "trusted programs that use execve as part of their operation".) Part of my struggle in proposing a solution is that there are two things I'd rather not add: 1. More modes. securebits, etc are hard to understand and can break assumptions that are currently true. 2. execve granting new privilege, even in the pI -> pP sense. There have been countless bugs relating to this in the past. This is why I proposed no_new_privs. A new mode that is only allowed when no_new_privs is set is considerably less dangerous, but still not wonderful. I could write a patch to add a new securebit SECURE_CAP_INHERITANCE that changes execve to act as though fI always contained all bits and to change capset to prevent pI from ever exceeding pP & pB. To make it usable without CAP_SETPCAP, maybe setting it to true should be legal without privilege if no_new_privs. (Actually, maybe all of the securebits should be freely tweakable if no_new_privs.) Some use cases: 1. Write a pam module that sets SECURE_CAP_INHERITANCE and assigns inheritable caps. Obviously it would grant users full use of those caps. The question is: what else would break? I.e. could users abuse it to exploit other setuid or fP!=0 binaries? 2. Write little fP != 0 helpers that check authorization, set no_new_privs and SECURE_CAP_INHERITANCE, and invoke something else. 3. (Pipe dream?) Eventually convince everyone to run in SECURE_CAP_INHERITANCE mode. I'll admit I'm not really thrilled by this suggestion. I'd like to do a survey and find out if anyone uses fI. If the answer is "no", fI support could be dropped in some kind of controlled manner, perhaps using the vfs cap version number. The setcap tool IMO wants some reworking anyway. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
