From: "Linda Walsh" <law@sgi.com>
Date: Sat, 27 May 2000 20:34:15 -0700
The comment in 'compute_creds' (fs/exec.c) leaves out the inclusion
of the previous process's Permitted bits. This Disables the possibility
of running a given UID running with specific Capabilities to perform
specific actions (UID's having 'roles', independant of FS settings) --
for example, if someone wanted to run with a 'root' type user in a
capability environment (say user=admin, has all caps and can only login
on the console) -- (policy for that setup being if an admin has access to console
and physical machine, they can pretty much do as they want).ly
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!!)
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)
- Ted
-
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:18 EST