> >I believe that the 'access' system call should check each pathname
> >component to ensure the 'real uid' has at least 'x' for every pathname
> >component except the last. (???)
>
> Personally, I think this really calls for a different approach (a 2.5
> implementation):
--- Why? How does this differ from the current implementation (other than it using 'fsuid' -- which could be different? I.e. my, perhaps flawed, understanding is that this is pretty much how it currently is.The problem comes in later with "Capabilities"...If I drop capabilities associated with a "su-cap" program and return to my previous set (which may be non-zero), I may still have CAP_DAC_READ_SEARCH to allow a lookup to succeed. Currently the access system call would seem to be flawed in that it unilaterally drops all caps -- not just the caps equivalent to an 'euid' that would have been set by a set[e]uid program.
Second -- should access check against the effective or permitted set? Basically, it seems, access was invented before POSIX caps, so the paradigm is ill-defined.
I could argue that access should check the user's effective set as it existed before they ran the sucap program. This would be consistent with the use of the 'capable' function as it is used today in the kernel. (side note: why is 'capable' defined in 'sched.h' and not 'capability.h'?)
I could also argue (perhaps less convincingly) that because the user *could* raise their effective set to their permitted set, we should check the permitted set, but then what's the point of having an 'effective' set if we only check the permitted set. So I think that would be wrong.
> > 1) check access with the process's Effective Caps *before* the > >program loaded it's caps, > > Ummm. How about something similar to "geteuid/seteuid" thing that some setuid > programs do now? --- The problem is not the call, but what data you would you return. Under the current paradigm, once you have executed su-cap program, how do you know what the original capabilities where?
Now I've heard some opinions that all the caps should be saved so a privileged app can completely restore the previous cap state, then fork/exec off a new program at the original cap-state (before the su-cap file was executed).
Is this a desirable paradigm? For some reason I don't like it. What does it mean? Would it be optional? (*ick*) For example -- lets say the new program now executes another su-cap program. That program has it's own inheritable, permitted and effective set. Do we want to merge those bits (with the previous inheritance rules) with the processes prior saved cap set or the process's current cap set? The results seem less than predictable if we were to allow such.
Another question -- how do we want to handle files with no capabilities sets. Does having no set mean 'no change', or does having no set mean the cap set is 'zero' (i.e. it is an unprivileged program). Again, different meanings/implications to either way. Which is cleaner?
> > > > These would be applied within the execX system call. > > > >I also anticipate the need for a 64 bit capability vector. Should we > >fold this in now? I can see (from POSIX 1003.1e DS15) some of the > >following needed caps (which is not to say this is an exhaustive list). > > My opinion is definitly 64 bit (at a minimum). I do believe that some of them > should be set aside for site use (8-16 bits please). Applications could then use > these to determine subsets of actions that may be permitted in user space. The > formula for determining availability should be the same as the kernel supported > capabilities. --- So you want application specific capabilities in the kernel? Maybe a separate cap word for user caps and the kernel does the math on exec's and such. I'd rather not intermix them in the same 64-bit word. > > I think a configuration item would be a very good thing. In fact, a whole > new section ... "Extended Security Options" should be created to hold > capabilities. It could be the place to put MAC capability, perhaps even > IPSec options when these become available. It might even be reasonable > to put the firewall option here (or at least a referece to it). --- I currently have a 'Trust' section under General Ops. MAC is in there along with audit. I thought FS-capabilities (and ACL's) belonged under fs specific stuff. But MAC and audit and capabilities (if we option them) are spread over many places, so I put the first file (audit.c) in a subdir 'trust' under the 'kernel' subdir.
-l
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:16 EST