Messages in this thread |  | | Date | Wed, 21 Apr 1999 16:26:21 -0700 (PDT) | | From | Y2K <> | | Subject | Re: inheritable set [was Re: caps in elf headers: use the sticky bit!] |
| |
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/
|  |