validity test in cap_set_proc(), POSIX.1e 25.4.15.2
Casey Schaufler
casey at sgi.com
Wed Dec 5 17:35:20 GMT 2001
Robert Watson wrote:
>
> POSIX.1e D17 25.4.15.2 reads:
>
> The function cap_set_proc() shall set the values for all capability
> flags for all capabilities defined in the implementation with the
> capability state identified by cap_p. The new capability state of the
> process shall be completely determined by the contents of cap_p upon
> successful return from this function. If any flag in cap_p is set for
> any capability not currently permitted for the calling process, the
> function shall fail, and the capability state of the process shall
> remain unchanged.
>
> In our currently implementation, we impose an additional check on cap_p
> provided to cap_set_proc(): we require that the resulting capability set
> be "valid" in the sense that the new effective capabilities be a subset of
> the new permitted capabilities. Does anyone else take this reading, and
> if not, is there a good reason not to?
You may wish to have a case where you need an effective capability
to do an exec(), perhaps CAP_DAC_OVERRIDE, but explicitly don't
want it in the permitted set of the resulting program. In this
case you would raise CAP_DAC_OVERRIDE to effective, and clear it
from permitted. You can't clear the permitted set while leaving
any effective in your scheme.
I haven't spent the time required to follow through the
capability recalculation calculus to verify this as an
important case, but it could be.
--
Casey Schaufler Manager, Trust Technology, SGI
casey at sgi.com voice: 650.933.1634
casey_p at pager.sgi.com Pager: 888.220.0607
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message
More information about the posix1e
mailing list