This is how privs/capabilities are supposed to work, I don't know if this
is the way they do (in actuality work) in the linux model. Feel free
to correct me if I'm wrong (nobody's perfect ;-) ).
In the kernel you have 3 different sets of privs/capabilities,
Permitted, Inheritable, and Effective.
Permitted is what privs/caps the process is allowed to raise in the
effective set, and/or the inheritable set. If you drop any priv/caps from
the permitted set, you are never able to raise them in the permitted
set of that process again. (i.e. you can drop privs/caps from the
permitted set, but never add to the permitted set). This means
you can never re-raise any priv/cap that you have dropped from
the permitted set, in either the effective or inheritable set.
Effective set is what privs/caps the process has at any given time. You
can raise and lower this all you like, however you cannot raise a priv/cap
thats not in your permitted set.
Inheritable set is the privs/caps that can be potentially passed on
to any child process of the process in question. Again you can
raise and lower this all you like, however you cannot raise a priv/cap
thats not in your permitted set.
On the filesystem you should have two different sets of
privs/capabilities, Forced, and Allowed.
Forced privs/caps MUST be a subset of (or the same set as) the allowed
privs/caps. These are privs that are set NO MATTER what the inheritable
privs (set by the parent) are.
Allowed privs are the set of privs/caps that can possibly be set
for the process. They are either forced on the process by being
in the forced set of the binary, or they're inherited by being
in the in inheritable set (passed from the parent process).
The kernel portion of all this is that it must:
1. determine what to set in the permitted, effective, and
inheritable sets when a program is exec()'d.
a. they are basically set to the union of the
inheritable privs/caps (from the parent process) and
the forced privs/caps (on the executable that gets exec()'d)
intersected with the allowed privs/caps (on the executable
that gets exec()'d)
2. provide system calls to raise and lower privs/caps in the effective,
permitted, and inheritable sets.
a. this is done so that you can have different effective priv/cap
sets throughout the life of the process. By raising
and lowering privs in the effective set you give your program
ONLY the privs/caps it needs ONLY when it needs them.
b. this is also done so you can limit the processes ability
to raise effective or inheritable priv/caps after a given
point in the program. By lowering privs/caps in your permitted
set you can never re-raise those privs.
c. this gives you the ability to lower or raise the privs/caps
that you are willing to pass on to child process of the
currently running process. For instance I can have a
process that has ALL privs in its permitted set,
runs with ALL in its effective set, but drops ALL privs
in inheritable set before producing any child processes,
giving them no inheritable privs. This means that
the only way the child process can get privs/caps is to
have them forced on (the intersection of the forced
and allowed sets).
3. provide system calls that set privs on binaries in the filesystem.
-- John Wojtowicz, Secure Systems Engineer jwojtowicz@tcs-sec.com Trusted Computer Solutions wojtowij@erols.com Herndon, VA 20171- 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/