Messages in this thread | | | Date | Mon, 4 Nov 2002 11:53:56 -0500 (EST) | From | Patrick Finnegan <> | Subject | Re: Filesystem Capabilities in 2.6? |
| |
On Mon, 4 Nov 2002, Olaf Dietsche wrote:
> Patrick Finnegan <pat@purdueriots.com> writes: > > > I see no one has responded to this yet, so I'll ask again. > > > > Does anyone have any comments about my idea outlined below? > [... capabilities in elf executables ...] > > Take a look at <http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html>. > Maybe this is what you had in mind?
Similar, but not exactly the same:
1) Capabilities should be enabled explicitly not dropped explicitly - it's a 'more secure' way to do it.
2) Capabilities shouldn't be preserved across an execve except for once, as needed by wrapper scripts/binaries. This way even if someone figures out how to exploit the code to do an exec, they're left with no caps at all. If desired, a new binfmt "cap_wrap" could be created that can be used as a capabilities wrapper for executables, which the kernel looks at to determine 1) what caps to use and 2) what binary to run. The wrapper will need to be suid root in order to gain caps still.
3) Defining a new ELF header seems to me like it could (potentially) break backward/forward compatibility. My method preserves compatibility, with the only difference being if the app really gets capabilities or if it gets SUID root instead. If this really isn't a problem, you can take the works 'ELF Symbol' and change them to 'ELF Header' and make the idea still work the same in other aspects.
4) If the app has capabilities associated with it, no userspace code is run as uid 0, the kernel can avoid even changing uid during the execve syscall. It's just treated as a caps flag unless the kernel determines that the file has no capabilities, and then can run it as suid root.
Pat -- Purdue Universtiy ITAP/RCS Information Technology at Purdue Research Computing and Storage http://www-rcd.cc.purdue.edu
http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |