> Well, the comments and the code reflect what's was in the last withdrawn
> draft of Posix 1.e (draft 17). It does disable the possibilities of
> capabilities which are permanently handed down from process to process.
> This was deliberate on the POSIX 1.e authors, since it avoids a classic
> set of security bugs. (i.e., /bin/mail being setuid, and the programmer
> of /bin/mail forgetting to drop privileges before exec'ing a pager such
> as /usr/ucb/more which allows the user to hell out. Oops!!)
===
Hmmm..
The Posix draft under section 25.1.1.2 "Capability Inheritance" says:
"Folling the _exec_() of a program, the capabilities that have their _permitted_ flags set in the new process image depend on the
capability states of both
the previous process image and the exec'd program file. Each capability
marked as _permitted_ may have been forced to be set by the progra file
or inherited from the previous image (if the capability attributes of the
program file allow the inheritance [read this as meaning inheritance bits
of both the previous process as well as the inheritance bits of the new].
This implies an 'or' of the Permitted sets. I also read the inheritance
check in the more restrictive fashion as needing to be set as inheritable
in both the current process and the new file.
What part of the draft standard where you referring to that says all
previous Permitted bits are dropped? That is supposed to be a function
of the 'inheritable' vector. I.e. you don't have to "drop" privileges,
they dropped automatically by setting the inheritable set to 0.
>
> Secondly, the comment doesn't reflect the code -- the effective set
> is never computed.
> Yes it is (from compute_creds()):
> cap_t(current->cap_permitted) = new_permitted;
> cap_t(current->cap_effective) = new_permitted &
> cap_t(bprm->cap_effective)
--- Misread this...you're right, this is set.So it seems to me there's just the bug of non-compliance with the spec. And there's the issue of using both Inheritable masks ("AND"ed) resulting in a more conservative setting, vs. only using the file's Inheritable set (which is what you *don't* want, since you want the current process to be able to choose what access rights can be propogated on to the next program -- you don't want the next program to choose that.
-linda
- 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:19 EST