Re: inheritable set [was Re: caps in elf headers: use the sticky
Y2K (y2k@y2ker.com)
Wed, 21 Apr 1999 16:26:21 -0700 (PDT)
On Wed, 21 Apr 1999, Theodore Y. Ts'o wrote:
> Date: Wed, 21 Apr 1999 13:39:09 -0700 (PDT)
> From: Y2K <y2k@y2ker.com>
> > No, because "more" wouldn't have any capabilities in its "inheritable"
> > set, so it would NOT inherit any capabilities which its parents had.
> Thats not very compatible, right now if the parent has the caps they flow
> to their children. Actually for linux2.2.6 it appears that if ruid=0 or
> euid=0 all caps are raised else all caps are droped upon exec.
> Sometimes, to be secure, you have to break compatibility. Period.
How is it insecure for a process to agree to allow a cap to be inheritied
especially if it can be further filtered out by the executible file
itself? For root processes you *can* get the compatible behavior of having
caps inherite in a understandible way without api changes in the execs.
for non-root cap-enhanced processes you can inherite caps to your
children; however they must explicitly allow those caps to again be
inheritied.
Right now if root is running everything all caps get inheritied.
In the future a new smart app can fine-tune what gets inheritied.
A dumb semi-legacy root cap-enhanced process will leak only a subset of
all caps iff it is set in compatiblity mode. a dumb non-root cap-enhanced
process will leak nothing.
+ if (!issecure(SECURE_NOROOT)&¤t->euid)
+ cap_clear(current->cap_inheritable);
Will cause non-root to clear their pI upon exec. This forces someone who
has already strayed from legacy behavior to deal with a potential
incompatibility, but allows rooters to behave in a more compatible way.
Also note the SECURE_NOROOT thing, probably should be:
if (issecure(SECURE_NOROOT)||current->euid)
We can cause the behavior to be more secure.
I am hashing around ideas to make securebits potentialy a per process
thing that can't override a global default.
I might also play with adding new SECURE_foo types.
> Sure, using capabilities will be an option, but people who turn it on
> will have to expect different behaviours in order to be fully secure.
I think that my model can support good compatible behavior for legacy apps
and provide enough room for new-apps to take advantage of the new
environment.
Might it be possible for you to offer more criticism than
"Sometimes, to be secure, you have to break compatibility." ?
What is exactly is the flaw(s)?
> Someone who is used to running as root all the time will certainly
> experience compatibility problems when they first start running as a
> non-privileged user 100% of the time. This is a similar transition.
Myself I log in as root every once in a while so I don't forget my passwd.
Runs with so little intervention, that I can tend to put too much time
inbetween my needing to log in as root.
I think that is uninteresting I'm more concerned about daemons and suids
etc.
Anyway thanks I'll update my patch to fix the pI droping better.
-
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/