[lkml]   [2002]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Filesystem Capabilities in 2.6?
On Mon, 4 Nov 2002, Olaf Dietsche wrote:

> Patrick Finnegan <> 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 <>.
> 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.

Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:30    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean