Messages in this thread | | | Date | Sun, 19 Apr 1998 14:22:08 -0700 | From | Andrew Morgan <> | Subject | Re: [patch 2.1.97] more capabilities support |
| |
> On Sun, 19 Apr 1998, Albert D. Cahalan wrote: > > * a Bounding Set that serves as a fail-safe mechanism to ensure users > > cannot acquire more privilege beyond what they have been authorized
One of the critical things about the capability model is the movement away from having executables spontaneously acquire privilege by simply being invoked.
This is one of the main problems with the historical suid model: a program gets all the power when it starts up. There are frequently new attacks on programs that exploit such a feature. Passing command line arguments that overflow a stack comes to mind...
The capability model is designed to change this. The recommended behavior for an executable on a fully capability-aware system is to not raise "effective" capabilities on startup. Since, without them, it has no immediate power. In order to become powerful, it needs to request that one or more of its permitted capabilities be made effective, with a system call.
The recommendation is that before this is done, the application "authenticates" the requesting user and context of the request. This authenticaton can be as strong or as weak as the application sees fit -- from don't care, to please step up to the retinal scanner -- but by providing some distance between acquiring the potential for power and actually activating the power there is at least a window of opportunity to authenticate the request. The fundamental point being that authentication (firewalling if you like) is the only way to enforce a security model.
The single bit 'fE' capability 'set' is the smallest hack possible to provide backwards compatability for legacy setuid applications. For all the reasons that the capability model is a good one, making use of 'fE' is strongly discouraged. The obvious alternative to a single bit of 'fE' capability is to have a complete multi-bit 'fE' set -- indicating which of the new process' permitted capabilities should raised in the effective set. fE is defined to be one bit to strongly discourage this "lack of programming" practice.
Chris Evans writes: > I perceieve the main benefit of this for users like "nobody"; with an > empty bounding set the user really can be "unprivileged", in the sense > they can't try and exploit your SUID/privileged programs to gain a root > shell etc.
The point you raise here about "nobody" getting some power, is an over generalization.. In some rare cases (contexts), it may be appropriate for the "nobody" user to exercise a capability. In these cases it is the "authentication" component of the application that needs to make this decision and because of the context, this is generally not something that can be reduced to a couple of bits in the file's attributes.
I hope that helps clear things up..
Best wishes
Andrew
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |